Ir al contenido 
Muestro cómo Adaptación del ancho de banda en servidores y control de tráfico en Linux para controlar los flujos de paquetes de forma que se reduzcan notablemente la latencia, el jitter y las interrupciones. Utilizo colas priorizadas, límites y reglas de QoS para proteger los flujos críticos para la empresa, como VoIP, API o solicitudes de tiendas, de las cargas de fondo y las copias de seguridad.
Puntos centrales
Las siguientes afirmaciones clave me ayudan a controlar los anchos de banda y el tráfico en los servidores Linux de forma selectiva y a planificarlos permanentemente.
- Priorización Los flujos de tiempo crítico reducen la latencia y las fluctuaciones.
- Límites de tarifa y el estrangulamiento evitan las ráfagas y los atascos del búfer.
- HTB/SFQ distribuir equitativamente el ancho de banda y mantener constantes las clases.
- Filtro QoS control por IP, puerto, protocolo o etiquetas.
- Monitoreo a través de P95 y las alertas detectan los cuellos de botella en una fase temprana.
Construyo estos puntos paso a paso, mido los efectos continuamente y adapto las clases y las tarifas a la utilización real.
Qué significa realmente la conformación del ancho de banda
Al dar forma, regulo el Flujo de parcelas de forma activa en lugar de sólo reactiva. Mantengo las tarifas constantes, doy prioridad al tráfico en tiempo real e interactivo y suavizo las ráfagas de datos irregulares. Para ello, limito la velocidad del tráfico saliente y estrangulo los flujos de datos entrantes. Esta separación crea responsabilidades claras en cada dirección y evita que se llenen los búferes. En los entornos de alojamiento, establezco límites superiores definidos para cada cliente o aplicación, de modo que un pico de carga no ralentice todo el sistema.
Control del tráfico en Linux: herramientas y conceptos
En Linux controlo el tráfico con la herramienta tc y las disciplinas de colas del núcleo (qdisc). Los bloques de construcción típicos son qdisc raíz, clases y filtros que definen la asignación de paquetes a prioridades y límites. Suelo empezar con HTB como controlador jerárquico para las tasas garantizadas y máximas. También utilizo SFQ para una distribución justa dentro de una clase. Limito el ancho de banda al 90-95% de la velocidad físicamente posible para conservar el margen de ráfagas y evitar picos de latencia.
Conformación de entrada (Ingress): IFB en lugar de Policer
Para el tráfico entrante, no forma directamente en la interfaz física, pero el uso de un IFB-device (Bloque Funcional Intermedio). Reflejo los paquetes entrantes en el IFB y los trato allí como tráfico saliente - incluyendo jerarquía HTB, equidad y límites. Esto es más fino que un policer puro, que sólo descarta hard y a menudo aumenta el jitter.
modprobe ifb numifbs=1
ip link add ifb0 type ifb
ip link set dev ifb0 up
# Activar ingress en PHY y redirigir a IFB
tc qdisc add dev eth0 handle ffff: ingress
tc filter add dev eth0 parent ffff: protocol ip u32 match u32 0 0 \
action mirred egress redirect dev ifb0
# Shaping en el IFB como con egress
tc qdisc add dev ifb0 root handle 2: htb default 20
tc class add dev ifb0 parent 2: classid 2:10 htb rate 40mbit ceil 60mbit
tc class add dev ifb0 parent 2: classid 2:20 htb rate 20mbit ceil 40mbit
tc qdisc add dev ifb0 parent 2:10 handle 210: fq_codel
tc qdisc add dev ifb0 parent 2:20 handle 220: sfq
Con IFB, controlo los picos de descarga, por ejemplo cuando los trabajos de copia de seguridad o réplica entrantes saturan el ancho de banda. En la práctica, utilizo IFB en interfaces con velocidades muy asimétricas (por ejemplo, 1G/200M) o cuando las ráfagas entrantes ponen en peligro la interactividad.
Comparación entre HTB, TBF y SFQ
Para elegir bien qdisc Me fijo en los objetivos de la aplicación: Garantías, comportamiento en ráfagas y equidad. HTB ofrece clases jerárquicas con tarifas fijas y máximas, TBF limita estrictamente por token bucket, SFQ distribuye las oportunidades mediante flujos. En combinación, forman un marco resistente en la práctica: HTB limita y garantiza, SFQ evita el dominio de conexiones individuales, TBF domestica las ráfagas obstinadas. En la tabla siguiente se resumen las características básicas para escenarios de servidor típicos. Esto me permite decidir más rápidamente qué disciplina tiene sentido en cada momento.
| qdisc/Feature | Propósito | Puntos fuertes | Uso típico |
|---|---|---|---|
| HTB | Jerarquía y control de la tasa | Tipo garantizado, límite superior, herencia | Clientes, clases de servicio, perfiles QoS |
| TBF | Estricto Tapas | Simple, muy determinista | Límite de enlaces ascendentes, límites de aplicaciones |
| SFQ | Equidad por caudal | Gastos generales reducidos, buena distribución | Descargas, P2P, muchas sesiones |
| FQ_CoDel | AQM contra el bufferbloat | Baja latencia, codificación de colas | Enrutadores de borde, enlaces de latencia crítica |
Para accesos con RTTs significativamente fluctuantes, utilizo FQ_CoDel o -dependiendo del kernel- CAKE como todoterreno. En la práctica de servidor, sin embargo, me quedo con HTB+SFQ/FQ_CoDel porque puedo combinar garantías, préstamos y distribución justa limpiamente en una jerarquía.
Práctica: normas tc para servidores típicos
Empiezo con un simple HTB-estructurar y luego asignar utilizando un filtro. Un qdisc raíz con clase por defecto atrapa los paquetes no clasificados, las clases priorizadas reciben tarifas garantizadas. Luego refino los filtros: HTTP/S a la clase A, replicación de base de datos a la clase B, copias de seguridad a la clase C. De este modo, las peticiones de la tienda se mantienen rápidas, mientras que las copias de seguridad utilizan las sobrantes. Para los conceptos básicos y el vocabulario, le remito a esta introducción a Gestión del ancho de banda, que hace tangible el procedimiento.
tc qdisc add dev eth0 root handle 1: htb default 20
tc class add dev eth0 parent 1: classid 1:10 htb rate 50mbit ceil 70mbit
tc class add dev eth0 parent 1: classid 1:20 htb rate 20mbit ceil 50mbit
tc class add dev eth0 parent 1: classid 1:30 htb rate 10mbit ceil 30mbit
tc qdisc add dev eth0 parent 1:10 handle 110: sfq
tc qdisc add dev eth0 parent 1:20 handle 120: sfq
tc qdisc add dev eth0 parent 1:30 handle 130: sfq
tc filter add dev eth0 protocol ip parent 1:0 prio 1 u32 match ip dport 443 0xffff flowid 1:10
tc filter add dev eth0 protocol ip parent 1:0 prio 2 u32 match ip dport 3306 0xffff flowid 1:20
tc filter add dev eth0 protocol ip parent 1:0 prio 3 u32 match ip sport 22 0xffff flowid 1:30
Clasificación con DSCP y marcas (compatible con IPv4/IPv6)
Para garantizar que los filtros funcionan independientemente de la versión de IP y NAT, marco los paquetes antes de tiempo y luego los asigno mediante fwmark en las clases. Esto me ahorra complejas coincidencias u32 y mantiene las reglas simplificadas. También utilizo DSCP para la semántica de extremo a extremo, por ejemplo para VoIP o interactividad.
# Ejemplo con nftables: Priorizar TLS, acelerar copias de seguridad
nft add table inet mangle
nft add chain inet mangle prerouting { type filter hook prerouting priority -150; }
nft add rule inet mangle prerouting tcp dport 443 meta mark set 10
nft add rule inet mangle prerouting tcp dport 22 meta mark set 30
nft add rule inet mangle prerouting tcp dport 873 meta mark set 40 # rsync/Backups
# Mapeo en clases HTB (funciona para IPv4/IPv6 igualmente)
tc filter add dev eth0 parent 1:0 prio 1 handle 10 fw flowid 1:10
tc filter add dev eth0 parent 1:0 prio 2 handle 30 fw flowid 1:30
tc filter add dev eth0 parent 1:0 prio 3 handle 40 fw flowid 1:20
Importante: Establezco DSCP/marcadores en la medida de lo posible. en el borde (entrada de la máquina o delante de ella) para que las decisiones posteriores puedan tomarse rápidamente y el tc tenga menos trabajo bajo carga.
Estrategias de calidad de servicio para el alojamiento: equidad y límites
En configuraciones multiarrendatario aseguro Equidad mediante garantías fijas por cliente y límites por aplicación. Marco los paquetes mediante DSCP o según los puertos y los asigno a las clases adecuadas. Se permite que las descargas y copias de seguridad llenen la capacidad, mientras que se da prioridad a las sesiones interactivas. De este modo, los servicios relevantes para los SLA siguen teniendo prioridad sin excluir a otros inquilinos. Resumo los escenarios prácticos y la lógica de priorización en esta visión general Priorización del tráfico que encaja bien con las reglas de la tc.
Persistencia y automatización
Mis políticas de QoS sobreviven a reinicios y reinicios de interfaz. Almaceno los comandos tc como un script idempotente y lo integro en systemd o netplan/networkd. Para dispositivos con nombres dinámicos (por ejemplo, veth/tap), utilizo reglas udev o plantillas systemd.
# /usr/local/sbin/tc-setup.sh (build idempotent)
# /bin/sh
tc qdisc replace dev eth0 root handle 1: htb default 20
# ... más clases/filtros aquí
# systemd unit: /etc/systemd/system/tc-setup.service
[Unidad]
Descripción=Traffic Control Setup
After=red-online.target
Wants=network-online.target
[Servicio]
Tipo=disparo individual
ExecStart=/usr/local/sbin/tc-setup.sh
RemainAfterExit=sí
[Instalar]
WantedBy=multi-user.target
Introduzco los cambios de forma controlada: primero en la fase de ensayo y luego durante un tiempo limitado en el sistema de producción (tc sustituir en lugar de añada), acompañado de métricas y un botón de retroceso.
Supervisión, P95 y resolución de problemas sin frustraciones
Mido los efectos continuamente en lugar de centrarme en Intuición abandonar. Las latencias P95, la longitud de las colas y las pérdidas de paquetes muestran si las reglas son eficaces o demasiado estrictas. Herramientas como iftop, vnStat y Netdata hacen visibles los picos de carga, los logs de tc e iptables muestran la asignación. Si se produce jitter, reduzco ligeramente los valores de ceil y compruebo CoDel/FQ_CoDel como medida de AQM. En caso de cuellos de botella, ajusto los pesos de clase paso a paso y mantengo ventanas de medición después de cada cambio.
Metodología de ensayo: simulación de carga y verificación
Simulo escenarios realistas: un flujo continuo (iperf3), interacciones cortas (pequeñas peticiones HTTP) y ráfagas periódicas (backup/rsync) en paralelo. A continuación compruebo si los flujos interactivos mantienen una latencia consistentemente baja y si las ráfagas se suavizan limpiamente.
# Prueba en sentido contrario (descarga/ingreso)
iperf3 -c -R -t 60
# Leer estadísticas de shaping
tc -s qdisc show dev eth0
tc -s class show dev eth0
# Comprueba la distribución de jitter/RTT
ping -i 0.2 -c 100 | awk '/time=/{print $7}'Si las clases necesitan préstamos permanentemente, aumento ligeramente las tasas garantizadas. Si se acumulan caídas en las colas de AQM, compruebo el tamaño de los búferes y si los límites están fijados de forma demasiado agresiva.
Ajuste del rendimiento: cobertura 90-95 %, suavizado de ráfagas, MTU
Limito la tasa de salida a 90-95% de la velocidad del enlace para evitar la saturación del búfer y permitir que AQM surta efecto. Suavizo las ráfagas con parámetros de token bucket (velocidad, ráfaga/latencia) para que los picos de corta duración no llenen colas enteras. Compruebo la MTU para reducir la fragmentación y evitar problemas de MTU de ruta. Para cargas de trabajo muy fluctuantes, establezco valores de ceil generosos pero tasas garantizadas conservadoras. Esta configuración mantiene rápido el tráfico prioritario mientras los procesos en segundo plano siguen ejecutándose de forma neutra.
Descarga de hardware, ajuste de colas múltiples e IRQ
Para la conformación precisa en enlaces rápidos, conozco la interacción con las descargas de NIC. TSO/GSO/GRO aceleran, pero a velocidades de destino muy bajas pueden empeorar el grano fino. Para enlaces sensibles, desactivo TSO/GSO como prueba y mido la latencia/ganancia de CPU en función de ello. En las NIC de cola múltiple utilizo un mq-Distribuyo la carga de la CPU con RPS/XPS e IRQ pinning para que el trabajo de QoS no pase hambre en una CPU.
# Prueba selectiva de las descargas (prudente en producción)
ethtool -K eth0 tso off gso off gro off
# Disposición de colas múltiples
tc qdisc add dev eth0 root handle 1: mq
tc qdisc add dev eth0 parent 1:1 handle 10: htb default 20
tc qdisc add dev eth0 parent 1:2 handle 20: htb default 20
# ... continuar por cola y establecer clases/filtros como de costumbre
Con txqueuelen, tamaños de búfer de anillo y afinidad IRQ, sigo recortando la latencia. El objetivo es conseguir una ruta de cola estable y corta que no se vuelque bajo carga.
Seguridad y segmentación: conformación con cortafuegos y VLAN
Combino QoS con Segmentación, para que las redes críticas conserven sus propias capacidades. Configuro mis propias colas para cada VLAN o interfaz, los cortafuegos marcan los paquetes en cuanto entran en el servidor. Esto significa que el tc tiene que tomar menos decisiones bajo carga porque los paquetes se clasifican desde el principio. Las copias de seguridad de la VLAN de almacenamiento permanecen en su ruta, mientras que el frontend HTTP no pasa hambre. La separación también acorta los análisis de errores porque los flujos pueden asignarse con mayor claridad.
Virtualización y contenedores: dónde me formo
En configuraciones KVM/virtio prefiero formar Bordeen la interfaz de puente (br0), en el enlace ascendente físico (eth0) o específicamente por huésped en su interfaz vnet. Me gusta implementar garantías por inquilino en vnetX, límites globales en el enlace ascendente. En Kubernetes, el tc es practicable en los peers veth o en los uplinks de los nodos; asigno marcadores desde el principio a través de CNI/iptables/nftables para que la asignación siga siendo determinista. Para SR-IOV o DPDK, me aseguro de que las rutas de datos todavía pasan a través de tc en absoluto - de lo contrario formulo de antemano o uso limitadores de velocidad propios de NIC.
Costes y ventajas: Eficiencia en lugar de actualizaciones de hardware
Con Modelado Aprovecho mejor las líneas existentes y a menudo me ahorro costosas actualizaciones. Menos pérdida de paquetes y menor latencia mejoran directamente la experiencia del usuario. En entornos de alojamiento, esto compensa doblemente porque los límites justos evitan escaladas entre clientes. En la práctica, veo que las tarifas estables aumentan el rendimiento al reducirse las retransmisiones. Estos efectos se reflejan finalmente en unos SLA más claros y menos casos de asistencia.
Errores frecuentes y comprobaciones rápidas
- Unidades inadecuadas: Compruebo si
mbitykbitse escriben correctamente y la ráfaga/latencia coincide con la MTU. - Inversión de prioridades: Demasiadas clases de alta prioridad sin un límite real conducen a la inanición de los predeterminados. Me atengo estrictamente a los límites superiores.
- NAT/IPv6 pasado por alto: Los filtros de puertos no funcionan como se pretende después de NAT/IPv6. Marco temprano (fwmark) y luego mapa en clases.
- Ceil menos de tasa: Un error tipográfico común que bloquea el préstamo. Valido cada clase con
tc -s clase. - Ingress sólo polarizado: Hard dropping crea jitter. Con IFB forma más fina y justa.
- Las descargas distorsionan las mediciones: Yo documento el estado de descarga de cada prueba y comparo manzanas con manzanas.
Perspectivas de futuro: Reserva asistida por IA y políticas adaptativas
Utilizo tendencias como Predicciones basándose en la carga histórica para adaptar dinámicamente las clases poco antes de las horas punta. Los modelos de aprendizaje reservan ancho de banda para VoIP o fases de pago antes de que crezcan las colas. En redes híbridas entre la nube y on-prem, utilizo topes temporales y presupuestos de ráfagas que cambian las políticas según un calendario. Esto reduce las intervenciones operativas y mantiene la previsibilidad de los servicios incluso durante eventos especiales. Aglutino conocimientos más profundos sobre escalado y límites aquí: Gestión del tráfico y límites de alojamiento.
Resumen y lista de control
Primero establecí un Jerarquía con HTB, emito garantías y mantengo Ceil ligeramente por debajo de la velocidad de enlace. A continuación, clasifico según servicios, protocolos o DSCP y compruebo los valores de latencia, jitter y P95. Utilizo SFQ o FQ_CoDel para garantizar una distribución equitativa y colas cortas. La supervisión acompaña cada cambio para que pueda decidir sobre los efectos en lugar de adivinar. Esto significa que la conformación del ancho de banda no es un acto puntual, sino un bucle de control ajustado que mantiene el tráfico del servidor seguro y predecible.
