Ir al contenido 
La función «TCP Small Queues» limita, por cada flujo TCP, los bytes pendientes en la ruta de transmisión de Linux, lo que reduce así Latencia reduciendo de forma selectiva el «bufferbloat». Voy a explicar cómo funciona este mecanismo en el redes en Linux Stack muestra cómo establecer límites razonables y qué interacciones se producen con el ritmo (pacing), los QDiscs y el control de congestión.
Puntos centrales
- Límite de caudal: TSQ limita el número de bytes pendientes por cada socket TCP.
- Menos «bufferbloat»: Las colas más cortas reducen el RTT.
- Contrapresión: Las aplicaciones escriben más lentamente cuando se alcanza el límite.
- Equidad: Ningún flujo por sí solo ocupa colas completas.
- Adaptativo Control: El límite depende de la tasa y del tamaño del segmento.
Cómo funciona TCP Small Queues
TSQ entra en acción en el punto en el que los segmentos TCP se... QDisc y al controlador. Cuando escribo datos en un socket, el núcleo comprueba, antes de cada operación de puesta en cola, los bytes ya asignados para ese flujo. Si el flujo alcanza el límite, la lógica marca el socket como limitado y detiene cualquier nueva operación de puesta en cola. Solo cuando la tarjeta de red libera memoria del búfer, el socket puede volver a enviar y yo puedo volver a introducir datos en la pila. Esta restricción estricta mantiene la Colas es breve y hace que los tiempos de respuesta sean más predecibles.
Por qué las colas largas aumentan el tiempo de respuesta
Crear colas de controladores y QDisc de gran tamaño Bufferbloat, sobre todo con TSO/GSO y grandes volúmenes de tráfico de salida. Una descarga pesada puede saturar las colas de salida, mientras que los flujos interactivos, como SSH, las llamadas a la API o el VoIP, quedan relegados a un segundo plano. La cola sobrecargada acaba dominando la RTT en lugar del tiempo real de enlace. El control de congestión reacciona con lentitud porque los acks llegan tarde y toma decisiones menos acertadas sobre el cwnd. El TSQ limita los bytes almacenados en el búfer por flujo, para que los paquetes pequeños y urgentes lleguen rápidamente a la línea.
Una mirada bajo el capó: lo que cuenta en el núcleo
En el fondo, el núcleo no cuenta „paquetes“, sino bytes; más concretamente: los bytes de memoria que el socket ya ha puesto en cola. Lo que cuenta es lo que la pila contiene en estructuras skbuff, incluyendo truesize que se ha asignado y que la NIC aún no ha procesado. TSQ vincula a ello un Acelerar/Desacelerar‑Ruta: Si un socket alcanza el crédito, la pila activa un indicador de limitación y no vuelve a llamar hasta que se hayan completado las transmisiones (NAPI/IRQ) write_space() para que la aplicación pueda volver a enviar datos. Esta retroalimentación es más rápida que las señales basadas exclusivamente en pérdidas del control de congestión y actúa antes que el QDisc. Con TSO/GSO, el mecanismo sigue siendo eficaz porque el límite en el antes de utiliza el presupuesto de bytes asignado a la segmentación: las supertramas grandes solo se admiten en el QDisc si hay suficiente crédito disponible, lo que permite contener las ráfagas.
Límites dinámicos y ritmo de entrenamiento
Me beneficio de TSQ porque el límite no se mantiene estático, sino que se ajusta a Tarifa y el tamaño de los segmentos. El objetivo es mantener unos datos de aproximadamente un milisegundo en la ruta de transmisión por flujo, independientemente de si la velocidad es de 100 Mbit, 1 Gbit o 10 Gbit. Con una conexión rápida, el crédito de bytes permitido aumenta; con una conexión lenta, disminuye. En combinación con el TCP-Pacing, los picos de tráfico se mantienen reducidos y los acuses de recibo llegan más rápido. De este modo, consigo una reducción notable de Picos de latencia, sin reducir innecesariamente el rendimiento.
Interacción por socket y entre aplicaciones
El TSQ solo surte efecto si la aplicación también detecta la contrapresión. Por eso tengo en cuenta ajustes como SO_SNDBUF, TCP_NOTSENT_LOWAT y el autocorking. Una ventana de búfer de envío demasiado grande puede empujar muchos bytes a la pila en un breve lapso de tiempo; aunque el TSQ frena el proceso, la aplicación no se da cuenta hasta que send() se bloquea o devuelve el código de error EAGAIN. Con TCP_NOTSENT_LOWAT retraso la parte „no enviada“ en el espacio de usuario y, con ello, completo el TSQ en el lado del núcleo. Autocorking (o explícitamente TCP_CORK/MSG_MORE) ayuda a agrupar pequeñas operaciones de escritura sin generar picos de latencia. Límites de ritmo por socket (por ejemplo, mediante SO_MAX_PACING_RATE) se adaptan a TSQ: la tasa se suaviza en el tiempo y el límite de bytes se restringe en el espacio. Importante: TCP_NODELAY Desactiva Nagle y puede aumentar la interactividad, pero sin TSQ aumenta el riesgo de picos de tráfico; con TSQ tengo ambos aspectos bajo control.
Guía práctica: valores adecuados de TSQ
Establezco el marco general con net.ipv4.tcp_limit_output_bytes (Sysctl). Los valores predeterminados habituales oscilan entre 128 y 262 KB por flujo. Para muchas cargas de trabajo web y de API, elijo valores más bajos para que las respuestas interactivas sigan siendo rápidas. Para las copias de seguridad o la replicación, aumento moderadamente el límite, siempre y cuando el RTT se mantenga estable. Quien quiera profundizar más en el tema de las colas, encontrará conceptos básicos sobre Colas de paquetes en el servidor, que ayudan a clasificar.
| Escenario | Tasa de enlaces | Valor de referencia tcp_limit_output_bytes | Objetivo |
|---|---|---|---|
| API/HTTP muy interactiva | 100 Mbit – 1 Gbit | 64-128 KB | baja RTT, púas cortas |
| Carga mixta: web + descargas | 1–10 Gbit | 128-256 KB | Saldo de Rendimiento y latencia |
| Replicación/Copias de seguridad | 1–10 Gbit | 256–512 KB | caudal a granel constante, aceptable Latencia |
| WAN con un RTT elevado | 10-100 Mbit | 96–192 KB | ráfagas más cortas, más justas Cues |
QDisc y el control de congestión en combinación
El TSQ funciona a la entrada de la QDisc, mientras que algoritmos como fq_codel gestionan la congestión en la línea. Juntos reducen las colas y garantizan una distribución equitativa. Con TCP BBR Además, me beneficio de ello, ya que unas mediciones de RTT más realistas permiten un mejor control del ritmo y de la cwnd. CUBIC también responde de forma más fluida cuando elimino los tiempos de cola excesivos. De este modo, el rendimiento crece de forma orgánica, mientras que la Tiempo de respuesta se mantiene bajo control.
Virtualización y plataformas en la nube
En las máquinas virtuales se acumulan varios niveles de búfer: el QDisc del invitado, las colas de virtio/vhost, el QDisc del host y la tarjeta de red física. Mantengo activo el TSQ en el invitado y elijo allí un límite conservador para que no lleguen grandes ráfagas al host. En el hipervisor, me aseguro de que las cadenas de latencia sean cortas mediante QDiscs equitativos, anillos TX moderados y una asignación limpia de IRQ. SR-IOV puede reducir la latencia, pero traslada la responsabilidad a los invitados: sin TSQ en el invitado, existe el riesgo de que se produzcan colas VF largas. En los contenedores, el TSQ por NetNS Como de costumbre; mediante el control de ritmo de cgroup y los límites de CPU evito que un vecino ruidoso aumente indirectamente la latencia. También es importante prestar atención a la coalescencia y a las descargas en la ruta virtio: una agrupación excesiva alarga los acks, mientras que una demasiado escasa reduce la eficiencia; yo realizo los ajustes en función del objetivo de latencia, sin ser dogmático.
WLAN y sistemas embebidos: cómo abordar correctamente los casos especiales
En las conexiones Wi-Fi, lo que cuenta es la Agregación en la capa MAC. Si dejo muy pocos bytes en la ruta de transmisión, el controlador no puede agrupar tantas tramas, lo que reduce la eficiencia. En este tipo de configuraciones, aumento el límite con cautela y compruebo el grado de agregación. Las plataformas OpenWrt y embebidas se benefician además de rutas optimizadas en los controladores y de un menor número de operaciones atómicas. Pruebo cada ajuste bajo una carga de radio real antes de... Perfil desplegar ampliamente.
Seguimiento y métricas que realmente cuentan
Observo el RTT‑Distribución por socket y presto atención a los valores atípicos, no solo a los valores medios. Con ss, tc y exportadores, leo las longitudes de las colas, las retransmisiones y la tasa de pacing. Los programas eBPF me envían eventos cuando los sockets se limitan y vuelven a quedar libres. El «Time-to-First-Byte» y los percentiles 95 y 99 indican si TSQ está surtiendo efecto. Sin valores de medición, cualquier Optimización un vuelo a ciegas.
Pruebas A/B y de carga con resultados significativos
Mido los efectos TSQ de forma reproducible: primero la línea de base sin cambios, luego barridos de parámetros aislados (por ejemplo, 64, 96, 128, 192 KB). Para cargas de trabajo mixtas, ejecuto flujos paralelos (volúmenes masivos + muchas peticiones cortas) y comparo los percentiles 95 y 99 de las latencias, no solo la mediana. Si interrumpo claramente las ejecuciones de prueba (calentamiento, ventana de medición, enfriamiento), los artefactos siguen siendo detectables. Presto atención a las constantes: mismos patrones de carga útil, ruta y MTU idénticas, frecuencias de CPU idénticas tanto en el servidor como en el cliente. En tramos de WAN simulo el retraso, la fluctuación y la pérdida con tc netem, para comprobar si los límites de TSQ no se alcanzan demasiado pronto cuando el BDP es elevado. Solo cuando los percentiles se estrechan y las retransmisiones y las pérdidas se mantienen estables, incorporo los valores a la producción.
Optimización del hardware y detalles de los controladores
Compruebo la configuración de TSO/GSO, el búfer circular de la tarjeta de red y el control de IRQ, para que TSQ funciona correctamente. Los anillos TX demasiado grandes alargan la cola en el dispositivo; los demasiado pequeños reducen la carga de trabajo. Una agrupación de interrupciones demasiado gruesa retrasa los acks, mientras que una agrupación más fina aumenta la carga de la CPU. Adapto la explicación a la práctica y, para empezar, remito a Coalescencia de interrupciones. El objetivo sigue siendo una Latencia con un rendimiento viable.
NUMA, RSS y afinidad de CPU
Las colas cortas sirven de poco si los paquetes cruzan constantemente los límites de NUMA. Vinculo las colas RX/TX mediante RSS/irqbalance a los núcleos del mismo dominio NUMA en el que se ejecuta la aplicación. Con XPS/RPS controlo qué CPUs se encargan del trabajo de transmisión (TX), evitando así los saltos entre sockets. Un menor número de fallos de caché y menos conflictos de bloqueo ayudan indirectamente a TSQ: las confirmaciones de finalización se reciben más rápido, el socket se „deslimita“ antes y no se producen picos de latencia. Cuando hay un gran número de flujos por host, planifico colas suficientes y evito que varios flujos intensos entren en colisión en el mismo anillo TX.
Paso a paso: comprobar si TSQ está activo
Empiezo echando un vistazo a Sysctl: sysctl net.ipv4.tcp_limit_output_bytes muestra el límite actual. A continuación, consulto ss -tin para cada socket, presto atención a send‑q y rtt, y comparo las fases de carga con y sin ajuste del límite. Con iperf3 genero carga en segundo plano y mido en paralelo los tiempos de respuesta de la API para hacer visibles las prioridades. tc -s qdisc me proporciona las cifras de paquetes y de descartes de la disciplina de salida. Si los percentiles 95 y 99 se mantienen ajustados y la CPU‑Carga en el bastidor: ajusta el límite seleccionado.
Errores comunes y antipatrones
- „Más margen = mayor rendimiento“: esto es cierto en las pruebas de rendimiento sin un objetivo de latencia, pero falla en los servicios interactivos. TSQ sustituye las colas sobredimensionadas por un crédito adaptado a las necesidades de cada flujo.
- „El TSQ reduce el rendimiento“: si se configura correctamente, el TSQ limita los picos de tráfico, no la tasa media. En cargas de trabajo masivas, aumento moderadamente el límite y mido los percentiles en lugar de limitarme solo al pico de Mbit/s.
- „El pacing por sí solo es suficiente“: el suavizado temporal es importante, pero sin un límite de bytes, las tramas GSO de gran tamaño siguen colándose en el QDisc. El TSQ y el pacing se complementan.
- „Un valor para todos“: las cargas de trabajo, los enlaces y las tarjetas de red son diferentes. Trabajo con rangos de valores y los valido por cada entorno.
- „Solo afecta a TCP“: la atención se centra en TCP, pero en el sistema hay otros parámetros de ajuste (por ejemplo, para la carga de UDP). Evito que los protocolos paralelos saturen las mismas colas de forma incontrolada.
Conclusión: control específico de la latencia
TSQ traslada el control de las colas de controladores al Zócalo y, de este modo, reduce los atascos directamente en su origen. Limito los bytes almacenados en el búfer por flujo y, así, garantizo acuses de recibo rápidos, un RTT más bajo y colas distribuidas de forma equitativa. En combinación con fq_codel y un control de congestión moderno, el tiempo de respuesta se mantiene fiable incluso bajo carga. Los casos especiales de WLAN y sistemas embebidos los trato con límites adaptados y pruebas en condiciones reales. Quien supervise los indicadores y ajuste los límites de forma gradual, mantendrá la Latencia consistentemente bajo, sin perder rendimiento innecesario.
