Header Ads

Cache Híbrido en Squid Proxy

16:39 , ,
Squid se define como un "caching proxy"; de hecho su nombre real es squid-cache, por tanto todo gira en torno a la "cache" (sin tilde, para los puristas de la RAE, porque es un anglicismo técnico ampliamente aceptado en informática).
Este proxy permite configurar múltiples directorios para la cache de manera simultánea, aprovechando las ventajas de diferentes sistemas de almacenamiento. En este post exploraremos dos configuraciones optimizadas que combinan Rock (rápido, optimizado para SSD) y UFS (tradicional, para objetos grandes) para maximizar el rendimiento de tu proxy.
¿Por qué usar cache híbrido?
La estrategia de cache híbrido aprovecha lo mejor de dos mundos:
  • Rock: Extremadamente rápido para objetos pequeños y medianos (imágenes, CSS, JS, HTML)
  • UFS: Eficiente para objetos grandes (videos, descargas, ISOs, actualizaciones)
Esta separación permite que Squid sirva contenido frecuente desde Rock a velocidades SSD, mientras almacena archivos grandes en UFS sin desperdiciar espacio en cache rápido.
Requisitos Mínimos
Hardware
  • RAM mínima: 8 GB (4 GB para Squid + 4 GB para sistema operativo)
  • Espacio en disco: Mínimo 150 GB libres
    • 100 GB para cache Rock
    • 50 GB para cache UFS
  • CPU: 2+ cores recomendados
  • Tipo de disco: SSD recomendado (HDD funciona pero más lento)
Software
  • Ubuntu 20.04+ / Debian 11+
  • Squid 5.0 o superior
  • Usuario proxy creado por el paquete de Squid
Red
  • Servidor dedicado o con recursos compartidos controlados
  • Ancho de banda adecuado para el número de usuarios

Configuración 1: Servidor Compartido (4 GB RAM para Squid)

Ideal para servidores que ejecutan múltiples servicios (Apache, UniFi Controller, DHCP, bases de datos, etc.)
Configuración en /etc/squid/squid.conf: 
# ==================================================================
# MEMORIA Y CACHE
# ==================================================================
cache_mem 4096 MB
maximum_object_size_in_memory 8192 KB      # 8 MB
memory_replacement_policy heap LFUDA
cache_replacement_policy heap LFUDA
maximum_object_size 131072 KB              # 128 MB

# ==================================================================
# DIRECTORIOS DE CACHE
# ==================================================================
# Rock: objetos pequeños/medianos (≤ 5 MB)
cache_dir rock /var/spool/squid/rock 102400 max-size=5242880

# UFS: objetos grandes (5 MB - 128 MB)
cache_dir ufs /var/spool/squid/ufs 50000 16 256 min-size=5242881

# ==================================================================
# OPTIMIZACIONES
# ==================================================================
ipcache_size 2048
fqdncache_size 4096
memory_pools_limit 32 MB
max_filedescriptors 32768
Script de instalación: 
#!/bin/bash

# Crear directorios de cache
mkdir -p /var/spool/squid/{rock,ufs} 2>/dev/null
chown -R proxy:proxy /var/spool/squid
chmod -R 700 /var/spool/squid

# Inicializar caches
squid -z

# Habilitar e iniciar servicio
systemctl enable squid 2>/dev/null
systemctl start squid

echo "Squid cache híbrido configurado correctamente"

Configuración 2: Servidor Dedicado (16 GB RAM para Squid)

Ideal para servidores dedicados exclusivamente a proxy o con recursos abundantes.
Configuración en /etc/squid/squid.conf: 
# ==================================================================
# MEMORIA Y CACHE
# ==================================================================
cache_mem 16384 MB                         # 16 GB
maximum_object_size_in_memory 8192 KB      # 8 MB
memory_replacement_policy heap LFUDA
cache_replacement_policy heap LFUDA
maximum_object_size 262144 KB              # 256 MB

# ==================================================================
# DIRECTORIOS DE CACHE
# ==================================================================
# Rock: objetos pequeños/medianos (≤ 5 MB)
cache_dir rock /var/spool/squid/rock 102400 max-size=5242880

# UFS: objetos grandes (5 MB - 256 MB)
cache_dir ufs /var/spool/squid/ufs 50000 16 256 min-size=5242881

# ==================================================================
# OPTIMIZACIONES
# ==================================================================
ipcache_size 4096
fqdncache_size 8192
memory_pools_limit 64 MB
max_filedescriptors 65536
Script de instalación: 
#!/bin/bash

# Crear directorios de cache
mkdir -p /var/spool/squid/{rock,ufs} 2>/dev/null
chown -R proxy:proxy /var/spool/squid
chmod -R 700 /var/spool/squid

# Inicializar caches
squid -z

# Habilitar e iniciar servicio
systemctl enable squid 2>/dev/null
systemctl start squid

echo "Squid cache híbrido de alto rendimiento configurado"

Parámetros Explicados

cache_mem
Memoria RAM dedicada para cachear objetos en memoria. No es el total de RAM que Squid usará (habrá overhead adicional).
maximum_object_size_in_memory
Tamaño máximo de un objeto individual para almacenarse en RAM. Objetos mayores van directo a disco.
maximum_object_size
Tamaño máximo global de objetos a cachear. Objetos mayores no se cachean.
cache_dir rock
  • 102400: ~100 GB de espacio
  • max-size=5242880: Objetos hasta 5 MB (5,242,880 bytes)
cache_dir ufs
  • 50000: ~50 GB de espacio
  • 16: Subdirectorios de primer nivel (00-0F en hexadecimal)
  • 256: Subdirectorios de segundo nivel
  • min-size=5242881: Solo objetos mayores a 5 MB
Algoritmo LFUDA
Least Frequently Used with Dynamic Aging - mantiene objetos frecuentemente accedidos, ideal para proxies con patrones de uso repetitivos.

Verificación de Funcionamiento

1. Verificar estructura de directorios 
# Verificar que existan ambos directorios
ls -ld /var/spool/squid/rock /var/spool/squid/ufs

# UFS debe tener subdirectorios 00-0F
ls /var/spool/squid/ufs/
Salida esperada: 
drwx------ 2 proxy proxy 4096 feb 9 12:57 rock
drwx------ 18 proxy proxy 4096 feb 9 12:57 ufs

00  01  02  03  04  05  06  07  08  09  0A  0B  0C  0D  0E  0F
2. Verificar que Squid reconoce ambas capas de cache
Funcionamiento del cache híbrido en un entorno en producción Ubuntu 24.04 
squidclient -p 3128 mgr:storedir
Salida esperada: 
Store Directory #0 (rock): /var/spool/squid/rock
FS Block Size 1024 Bytes
Maximum Size: 104857600 KB
Current Size: 83920.00 KB 0.08%

Store Directory #1 (ufs): /var/spool/squid/ufs
FS Block Size 4096 Bytes
First level subdirectories: 16
Second level subdirectories: 256
Maximum Size: 51200000 KB
Current Size: 32736.00 KB
Nota:
Squid usa procesos "disk kids" separados. Ejemplo: 
kid1 (squid-1): Worker principal + UFS
kid2 (squid-disk-2): Gestor de Rock
kid3 (squid-coord-3): Coordinador
3. Verificar espacio usado 
sudo du -sh /var/spool/squid/rock /var/spool/squid/ufs
Ejemplo de salida: 
1.4G    /var/spool/squid/rock
49M     /var/spool/squid/ufs
4. Verificar uso de RAM real 
ps aux | grep '[s]quid' | awk '{sum+=$6} END {print "RAM Real: " sum/1024 " MB"}'
Nota importante: El comando systemctl status squid | grep Memory puede mostrar valores altos (40+ GB) que representan memoria virtual, no RAM física real. Usa el comando ps anterior para ver el consumo real.
5. Monitorear en tiempo real 
# Ver crecimiento de ambos caches
watch -n 30 "sudo du -sh /var/spool/squid/rock /var/spool/squid/ufs"
6. Script completo de verificación 
#!/bin/bash

echo "═══════════════════════════════════════════════════"
echo "  VERIFICACIÓN DE CACHES SQUID"
echo "═══════════════════════════════════════════════════"
echo ""

echo "1. Configuración activa:"
grep "cache_dir" /etc/squid/squid.conf | grep -v "^#"
echo ""

echo "2. Espacio usado:"
sudo du -sh /var/spool/squid/rock /var/spool/squid/ufs
echo ""

echo "3. RAM real usada:"
ps aux | grep '[s]quid' | awk '{sum+=$6} END {print "Total: " sum/1024 " MB"}'
echo ""

echo "4. Store directories reconocidos:"
squidclient -p 3128 mgr:storedir | grep -E "Store Directory|Maximum Size|Current Size"
echo ""

echo "═══════════════════════════════════════════════════"

Interpretación de Resultados

Distribución esperada de objetos
  • Rock tendrá MÁS objetos (miles o millones): contenido web típico (HTML, CSS, JS, imágenes)
  • UFS tendrá MENOS objetos (decenas o cientos): videos, descargas grandes, actualizaciones
Ejemplo real: 
Rock:  1,699 objetos →  82 MB usado
UFS:      57 objetos →  32 MB usado
RAM:   2,203 objetos → 112 MB usado
Crecimiento normal
Con uso regular, después de días/semanas:
Configuración 4GB:
  • Rock: 50-80 GB, millones de objetos
  • UFS: 10-30 GB, cientos/miles de objetos
  • RAM: 2-3 GB en uso real
Configuración 16GB:
  • Rock: 80-100 GB, millones de objetos
  • UFS: 30-50 GB, miles de objetos
  • RAM: 8-12 GB en uso real

Solución de Problemas Comunes

Error: "WARNING: disk-cache maximum object size..."
Causa: maximum_object_size mayor que cache_mem
Solución: Asegúrate de que:
  • cache_mem esté en MB
  • maximum_object_size esté en KB
  • Ejemplo: cache_mem 4096 MB y maximum_object_size 131072 KB
Solo aparece un cache_dir en logs
Verificar: 
# Ver configuración
grep "cache_dir" /etc/squid/squid.conf | grep -v "^#"

# Reinicializar
sudo systemctl stop squid
sudo rm -rf /var/spool/squid/{rock,ufs}/*
sudo squid -z
sudo systemctl start squid
Uso excesivo de RAM (systemd muestra 40+ GB)
No es un problema real. Systemd muestra memoria virtual. Verificar RAM real: 
ps aux | grep '[s]quid' | awk '{sum+=$6} END {print sum/1024 " MB"}'
Si el resultado es <2 GB para configuración de 4GB o <10 GB para 16GB, está funcionando correctamente.
FATAL: assertion failed: Controller.cc
En ocasiones, estas configuraciones fallan, porque Rock puede tener millones de entradas indexadas pero solo una cantidad ínfima objetos válidos. Esto sucede cuando los objetos expiran pero sus índices quedan, o hay corrupción por apagados incorrectos o el cache nunca se limpia adecuadamente. También puede aparecer este mensaje: Rebuilding storage in /var/spool/squid/ufs (dirty log). Misma causa; corrupción del store UFS (y adicional Squid 6.x tiene un bug conocido con transients + rebuild). La solución a esto es limpiar las caches (squid -z) y ajustar los parámetros y monitorear la cache de Squid para eventuales problemas e ir ajustando dichos valores a su entorno:
# Ver uso de memoria en tiempo real
watch -n 2 'systemctl status squid | grep -E "Memory|CPU"'

# Ver objetos en cache
sudo squidclient -p 3128 mgr:storedir

# Ver info general
sudo squidclient -p 3128 mgr:info

# Monitorear Squid"
sudo journalctl -u squid -f

# Verificar memoria compartida vs real. Ejemplo:
cat /proc/$(pgrep -o squid)/status | grep -i "rss\|shared"
VmRSS:	  417596 kB
RssAnon:	    6776 kB
RssFile:	   16484 kB
RssShmem:	  394336 kB
# real
ps aux | grep '[s]quid' | awk '{sum+=$6} END {print "RSS total aparente: " sum/1024 " MB"}'
RSS total aparente: 761.672 MB
Workers
Los workers son procesos de Squid que trabajan en paralelo para atender peticiones de usuarios. La recomendación general es esta:
Carga baja/media (< 1000 usuarios concurrentes):
bashworkers 2
Carga alta (1000-5000 usuarios):
bashworkers 3
Carga muy alta (> 5000 usuarios):
bashworkers 4  # Máximo recomendado para 6 CPUs
⚠️ Importante sobre workers:
  • Cada worker adicional consume más memoria compartida (mapeos)
  • NO pongas más de 4 workers con 6 CPUs (deja CPUs para el SO)
  • Con workers 2 + coordinador + disker = 4 procesos squid (perfecto para 6 CPUs)
  • Si no está seguro, no lo especifique en su archivo de configuración y Squid funcionará en modo single-process
Ventajas de desactivar workers:
  • ✅ Más simple: Un solo proceso, más fácil de debuggear
  • ✅ Menos overhead: No hay coordinación entre procesos
  • ✅ Memoria más clara: No hay confusión con memoria compartida
  • ✅ Suficiente para + 500 usuarios: Un proceso bien optimizado maneja bastante
Desventajas:
  • ⚠️ Menos throughput: No aprovecha múltiples CPUs
  • ⚠️ Cuello de botella: En redes grandes un solo proceso se satura
  • ⚠️ No escala tan bien: Para alto tráfico necesitas workers

Consideraciones de Rendimiento

Ventajas del cache híbrido
  • ✅ Velocidad: Rock sirve contenido frecuente a velocidad SSD
  • ✅ Eficiencia: UFS maneja archivos grandes sin desperdiciar espacio rápido
  • ✅ Escalabilidad: Fácil agregar más espacio a cualquier cache
  • ✅ Flexibilidad: Cada cache puede estar en discos diferentes
Cuándo usar cada configuración
Configuración 4GB si:
  • Servidor con múltiples servicios
  • RAM limitada (8-32 GB total)
  • 50-200 usuarios concurrentes
  • Presupuesto ajustado
Configuración 16GB si:
  • Servidor dedicado a proxy
  • RAM abundante (64+ GB)
  • 200-1000+ usuarios
  • Máximo rendimiento requerido

Conclusión

La configuración híbrida Rock + UFS ofrece el mejor balance entre velocidad y capacidad para Squid. Con la configuración adecuada según tus recursos, puedes lograr:
  • Hit rates del 30-60% en redes típicas
  • Reducción significativa de ancho de banda
  • Tiempos de respuesta más rápidos
  • Mejor experiencia de usuario

Limitaciones

Recuerde que estas configuraciones tienen límites. Siempre estará presente el fantasma del error FATAL: assertion failed: Controller.cc por tanto deberá monitorear regularmente a Squid y el uso de cache para ajustar los parámetros según los patrones de uso de tu red.
Si usa Squid 6x y tiene un SSD, y este error se vuelve frecuente y su Squid se detiene sin previo aviso, hay dos opciones: O actualizar a la versión más reciente o desactivar una de las dos caches (preferentemente desactivar UFS y dejar Rock que es la más estable). A continuación cada caso:
# Constantes independientes de RAM y disco
maximum_object_size 262144 KB
maximum_object_size_in_memory 512 KB

# Tamaño de la cache, asumiento que tiene un SSD mínimo de 500 GB con ~45–50 % libre
cache_dir rock /var/spool/squid/rock 200000 max-size=268435456 slot-size=32768

# Variable según RAM
cache_mem 8192 MB   # 64 GB
cache_mem 4096 MB   # 32 GB
cache_mem 2048 MB   # 16 GB

# Y finalmente:
sudo squid -k shutdown # o sudo service squid stop o sudo systemctl stop squid
sleep 5
# Nota: es mejor mantener las carpetas de cache individuales dentro de la ruta /var/spool/squid y en squid.conf
sudo rm -rf /var/spool/squid/rock/*
sudo squid -z
sudo systemctl start squid
Tenga cuidado con estos parámetros, ya que puede salir el siguiente error:
ERROR: /var/spool/squid/rock/rock exception: check failed: pending->writeRequest->len <= Ipc::Mem::PageSize() exception location: IpcIoFile.cc(381) push current master transaction: master11991
Causa: cuando sube demasiado el slot-size. Ejemplo: slot-size=65536. Significa 64 KB y esto puede romper en varias builds, ya que, en Squid 6.x, slot-size no puede ser arbitrariamente grande. Por tanto los valores anteriores son conservadores y evitan este error.
Un slot-size=32768 es el punto óptimo entre:
  • Fragmentación
  • IPC límite
  • Estabilidad
Por otro lado, aunque la configuración híbrida Rock + UFS está técnicamente optimizada, es importante entender una limitación fundamental de Squid actualmente: el 95%+ del tráfico web es HTTPS, lo cual significa que está encriptado de extremo a extremo.
¿Qué significa esto para tu cache?
Cuando Squid maneja tráfico HTTPS sin SSL-Bump (interceptación SSL), solo actúa como un "túnel" ( TCP_TUNNEL) que pasa el tráfico encriptado sin poder:
  • ❌ Ver el contenido de las peticiones
  • ❌ Cachear los objetos descargados
  • ❌ Aplicar refresh_patterns
  • ❌ Comprimir o optimizar contenido
Ejemplo real de logs sin SSL-Bump: 
# Análisis de 1000 peticiones en un proxy de producción:
sudo tail -1000 /var/log/squid/access.log | awk '{print $4}' | sort | uniq -c | sort -rn

480 TCP_TUNNEL/200           48.0% ← HTTPS exitoso (NO cacheable sin SSL-Bump)
174 TCP_DENIED/403           17.4% ← Bloqueado por tus ACLs
167 TCP_TUNNEL/503           16.7% ← HTTPS fallido
82  TCP_MISS_ABORTED/503      8.2% ← Conexiones abortadas
25  NONE_NONE/000             2.5% ← Peticiones malformadas
18  TCP_CF_MISS_ABORTED/503   1.8% ← Collapsed forwarding abortado
17  TCP_MEM_HIT/200           1.7% ← ✅ HIT desde RAM
17  NONE_NONE/400             1.7% ← Peticiones inválidas
6   TCP_MISS/304              0.6% ← No modificado
5   TCP_MISS/200              0.5% ← Descargado (no en cache)
4   TCP_INM_HIT/304           0.4% ← ✅ HIT validado
3   TCP_HIT/200               0.3% ← ✅ HIT desde disco
1   TCP_REFRESH_UNMODIFIED    0.1% ← ✅ HIT refrescado
1   TCP_IMS_HIT/304           0.1% ← ✅ HIT if-modified-since
De 1000 peticiones:
# Tráfico NO cacheable (85%):
480 + 167 = 647 HTTPS (64.7%) ← No se puede cachear sin SSL-Bump
174 bloqueados (17.4%)
82 + 18 abortados (10.0%)
# Tráfico potencialmente cacheable (15%):
17 + 6 + 5 = 28 HTTP real
26 HITs de 28 HTTP = 92.9% hit rate en HTTP ✅
Dominios más frecuentes (todos HTTPS): 
102 topapps-func.pinsightmedia.com:443   ← Puerto 443 = HTTPS
47  web.whatsapp.com:443                 ← Puerto 443 = HTTPS  
40  tlu.dl.delivery.mp.microsoft.com     ← Windows Update
27  ctldl.windowsupdate.com              ← Windows Update
23  web.whatsapp.com:5222                ← XMPP encriptado
Comandos usados: 
#!/bin/bash

LINES=2000

echo "════════════════════════════════════════════════════════"
echo "  ANÁLISIS DE DOMINIOS - Últimas $LINES peticiones"
echo "════════════════════════════════════════════════════════"
echo ""

echo "▶ TOP 20 DOMINIOS MÁS USADOS:"
sudo tail -$LINES /var/log/squid/access.log | awk '{print $7}' | cut -d'/' -f3 | cut -d':' -f1 | sort | uniq -c | sort -rn | head -20
echo ""

echo "▶ TOP 15 DOMINIOS HTTPS (no cacheables):"
sudo tail -$LINES /var/log/squid/access.log | grep "TCP_TUNNEL" | awk '{print $7}' | cut -d'/' -f3 | cut -d':' -f1 | sort | uniq -c | sort -rn | head -15
echo ""

echo "▶ TOP 10 DOMINIOS CON CACHE HITS:"
sudo tail -$LINES /var/log/squid/access.log | grep -E "HIT" | awk '{print $7}' | cut -d'/' -f3 | cut -d':' -f1 | sort | uniq -c | sort -rn | head -10
echo ""

echo "▶ TOP 10 DOMINIOS BLOQUEADOS:"
sudo tail -$LINES /var/log/squid/access.log | grep "DENIED" | awk '{print $7}' | cut -d'/' -f3 | cut -d':' -f1 | sort | uniq -c | sort -rn | head -10
echo ""

echo "════════════════════════════════════════════════════════"
Se puede cachear sin SSL-Bump?
Aunque el panorama es limitado, todavía hay contenido valioso que cachear:
  • ✅ Actualizaciones de Windows/Linux: Muchas aún usan HTTP o están permitidas para cache
  • ✅ Repositorios APT/YUM: Paquetes .deb, .rpm
  • ✅ CDNs específicos: Algunos servicios siguen usando HTTP
  • ✅ Contenido corporativo interno: Si controlas el servidor, puedes usar HTTP
Hit rates realistas a la fecha:
  • Sin SSL-Bump: 5-15% hit rate (principalmente actualizaciones de SO)
  • Con SSL-Bump: 30-60% hit rate (requiere certificados en clientes)
¿Vale la pena el cache híbrido entonces?
SÍ, especialmente para:
  • ✅ Redes corporativas con muchos equipos Windows/Linux descargando actualizaciones
  • ✅ Instituciones educativas con laboratorios que se actualizan frecuentemente
  • ✅ Control y logs de acceso web (aunque no se cachee HTTPS, sí se registra)
  • ✅ Filtrado de contenido por dominio/IP (ACLs siguen funcionando)
  • ✅ Ahorro de ancho de banda en el 5-15% del tráfico cacheado (que puede ser considerable)
Alternativa: SSL-Bump (Interceptación HTTPS)
Para cachear tráfico HTTPS, necesitas configurar SSL-Bump, que requiere:
  • Generar un certificado CA propio
  • Instalar el certificado en TODOS los dispositivos de la red
  • Configuración compleja en Squid (ssl_bump, sslcrtd)
  • Consideraciones legales/privacidad (interceptas tráfico encriptado)
⚠️ SSL-Bump NO se recomienda a menos que:
  • Sea un ambiente corporativo totalmente controlado
  • Tengas autorización legal para interceptar tráfico
  • Puedas distribuir certificados a todos los dispositivos
  • Aceptes la complejidad técnica adicional
Conclusión sobre HTTPS:
El cache híbrido Rock + UFS sigue siendo la configuración óptima técnicamente, pero las expectativas de hit rate deben ser realistas. En redes típicas sin SSL-Bump, esperar entre 5-15% de hit rate, principalmente de actualizaciones de sistemas operativos y aplicaciones. Esto sigue representando un ahorro significativo de ancho de banda, especialmente en redes con muchos dispositivos.

Post a Comment

Con la tecnología de Blogger.