El control de congestión TCP determina cómo se gestionan las conexiones cuando cambian carga de red ajustar la velocidad de datos y cómo se comportan los algoritmos en configuraciones de alojamiento reales. En esta comparación, muestro los efectos concretos sobre el rendimiento, el retraso y la equidad para Alojamiento web, streaming y cargas de trabajo en la nube.
Puntos centrales
Para que puedas leer el artículo de forma específica, resumiré brevemente los aspectos más importantes y luego lo pondré todo en contexto. Distingo claramente entre los métodos basados en pérdidas y los basados en modelos, ya que ambas familias reaccionan de forma muy diferente. Explico por qué cwnd, RTT y Pacing sobre el rendimiento y Equidad Decidir. Clasifico los resultados de las mediciones para que no tomes decisiones basadas en corazonadas. Concluyo con recomendaciones pragmáticas para el alojamiento, los contenedores y la globalización. Usuarios.
- AIMD controla cwnd y reacciona ante las pérdidas
- CUBIC Ofrece un rendimiento constante con RTT elevados.
- BBR utiliza modelos, reduce las colas y la latencia
- BIC Anota en redes con drops
- Hybla Acelera las líneas largas (satélite)
Lo que controla el control de congestión: cwnd, RTT, señales de pérdida
Empezaré por los conceptos básicos, ya que influyen en todas las decisiones posteriores. La ventana de congestión (cwnd) limita la cantidad de bytes que se transmiten sin confirmación, y AIMD aumenta gradualmente cwnd hasta que se producen pérdidas. RTT determina la rapidez con la que se reciben las confirmaciones y la agresividad con la que puede crecer un algoritmo. Las señales de pérdida solían provenir de tiempos de espera y ACK triples duplicados, pero hoy en día también se tienen en cuenta la profundidad de la cola, el RTT mínimo y el ancho de banda del cuello de botella medido. Quien comprende cwnd, RTT e interpretación de pérdidas, evalúa la influencia en el rendimiento, el retraso y Jitter Mejor inmediatamente.
Retrospectiva: Reno, NewReno y Las Vegas en la vida cotidiana
Reno utiliza Slow Start al principio y luego pasa a incrementos lineales, pero reduce drásticamente el tamaño de la ventana después de las pérdidas. NewReno repara varias pérdidas por ventana de manera más eficiente, lo que ayuda notablemente, especialmente con tasas de error moderadas. Vegas mide el rendimiento esperado frente al real a través del RTT y frena pronto para evitar pérdidas. Esta precaución mantiene las colas pequeñas, pero cuesta rendimiento cuando los flujos basados en pérdidas envían de forma paralela más agresiva. Si ve tiempos de espera inexplicables o ACK duplicados, primero debería Analizar pérdidas de paquetes y luego el algoritmo para Topología Seleccionar el adecuado.
High-BW-RTT: comparación entre BIC y CUBIC
BIC se acerca de forma binaria al cwnd más alto sin pérdidas y mantiene la tasa sorprendentemente constante incluso con errores leves. En laboratorios con baja latencia y tasas de caída de alrededor de 10^-4, BIC proporcionó valores de rendimiento superiores a 8 Gbit/s, mientras que los algoritmos clásicos fluctuaban. CUBIC sustituyó a BIC como estándar porque controla su cwnd mediante una función temporal cúbica, lo que le permite aprovechar mejor los RTT largos. Tras un evento de pérdida, la curva crece primero de forma moderada, luego se acelera notablemente y vuelve a moderarse cerca de la última tasa máxima. En redes con trayectos largos, con CUBIC suelo alcanzar una mayor utilización con una buena Planificabilidad las latencias.
Basado en modelos: BBR, pacing y bufferbloat
BBR utiliza un modelo basado en el RTT mínimo y el ancho de banda de cuello de botella medido, establece cwnd en aproximadamente el doble del producto del ancho de banda y el retraso, y distribuye los paquetes de manera uniforme. Esta estrategia evita las colas desbordadas y mantiene los retrasos cortos, incluso cuando se producen pérdidas leves. En configuraciones con calidad de radio variable o rutas mixtas, el rendimiento útil se mantiene alto porque BBR no reacciona de forma refleja a cada caída. La versión 1 se considera muy rápida, pero puede competir con CUBIC en buffers pequeños y mostrar una distribución algo injusta. Yo combino BBR en Alojamiento BBR CUBIC Paisajes para flujos primarios y ejecutar CUBIC como alternativa compatible.
Satélite y radio: Hybla, Westwood y PCC
Hybla compensa las desventajas de los RTT elevados escalando cwnd como si se tratara de un RTT de referencia corto. De este modo, las distancias largas, como las satelitales, alcanzan mucho más rápido velocidades útiles y se mantienen estables. Westwood estima el ancho de banda disponible a partir de las tasas de ACK y reduce cwnd con menos dureza tras las pérdidas, lo que ayuda en redes inalámbricas con errores aleatorios. PCC va un paso más allá y optimiza un valor de utilidad mediante experimentos cortos, lo que le permite alcanzar combinaciones de goodput y latencia elevadas. En redes heterogéneas con Movilidad Pruebo Hybla y Westwood antes de aplicar reglas de QoS complejas.
Comparación de rendimiento: valores medidos y equidad
Las comparaciones muestran perfiles claramente diferentes cuando varían la latencia y las tasas de error. Con un RTT bajo, BIC suele dominar la carrera por el rendimiento puro, mientras que CUBIC ofrece una combinación fiable de velocidad y comportamiento a lo largo del tiempo. Con RTT muy largos, CUBIC supera claramente a Reno y NewReno, ya que traduce mejor los tiempos de espera en crecimiento. BBR mantiene las colas vacías y ofrece retrasos constantemente bajos, pero genera más retransmisiones dependiendo del tamaño del búfer. Para flujos paralelos, CUBIC suele mostrar una distribución justa, mientras que BIC tiende a mantener la línea cerca de la Capacidad.
| Algoritmo | Principio | Fuerza | debilidad | Recomendado para |
|---|---|---|---|---|
| Reno / NewReno | Basado en pérdidas, AIMD | Comportamiento sencillo | Lento con un RTT alto | Pilas heredadas, Solución de problemas |
| Las Vegas | Basado en RTT | Prevención temprana de atascos | Menor rendimiento | Latencia constante |
| BIC | Búsqueda binaria | Alto rendimiento en las entregas | Agresivo con los demás | RTT bajo, tasas de error |
| CUBIC | Función temporal cúbica | Buena equidad | Dispersión en Drops | Largos caminos, centros de datos |
| BBR | Basado en modelos, pacing | Baja latencia | Injusto en pequeños amortiguadores | Alojamiento, usuarios globales |
| Hybla | Compensación RTT | Rápida puesta en marcha | Caso especial | Satélite, Marítimo |
Guía práctica: selección según latencia, pérdida y destino
Empiezo cada decisión con objetivos claros: baja latencia, máximo rendimiento o equilibrio para muchos flujos. Cuando los tamaños de búfer están muy limitados y los requisitos de latencia son sensibles, primero recurro a BBR. Cuando predominan las rutas largas y coexisten varios hosts, no hay otra opción que CUBIC. En redes con patrones de caída fácilmente observables, BIC sigue ofreciendo velocidades impresionantes, siempre que la equidad sea secundaria. Para satélites y costes de ruta RTT muy elevados, Hybla elimina las desventajas típicas de la aceleración y garantiza una rápida carga útil.
Linux, Windows y contenedores: activación y ajuste
En Linux, compruebo el algoritmo activo con sysctl net.ipv4.tcp_congestion_control y lo implemento específicamente con sysctl net.ipv4.tcp_congestion_control=bbr. Para CUBIC, tengo en cuenta los valores predeterminados del kernel, pero ajusto net.core.default_qdisc y los parámetros de ritmo cuando alivio las colas del host. En contenedores, transfiero la configuración al host, ya que los espacios de nombres no aíslan todas las colas. En Windows, a partir de las versiones actuales, BBR se puede activar en las ediciones adecuadas, mientras que los sistemas más antiguos siguen utilizando CUBIC o Compound. Sin un sistema sólido y ColaCon cada ajuste, todos los algoritmos pierden notablemente su eficacia.
Perspectiva del alojamiento web: equidad multitasa y rendimiento efectivo
En los clústeres de alojamiento, lo que cuenta es la suma de muchos flujos simultáneos, no el mejor valor de una sola transferencia. CUBIC mantiene las conexiones predecibles y suele distribuir la capacidad de forma equitativa, lo que favorece los escenarios multitenant densos. BBR reduce las colas y mantiene bajos los tiempos de respuesta para las API y los sitios web dinámicos. Si se tiene en cuenta la sobrecarga del protocolo, se debe probar el transporte con versiones HTTP; mi punto de partida es HTTP/3 frente a HTTP/2 en combinación con el método CC seleccionado. Para los usuarios globales, prefiero picos de latencia bajos, ya que el tiempo de respuesta influye directamente en la percepción. Velocidad marca.
QUIC y BBR: influencia más allá de TCP
QUIC incorpora su propio control de congestión basado en UDP y utiliza principios similares a los de BBR, como el control de velocidad y la observación de RTT. En las pilas modernas, el rendimiento se está desplazando gradualmente del TCP a la capa de aplicación. Esto aumenta el grado de libertad, pero requiere mediciones precisas a nivel de ruta, host y aplicación. Para la planificación, recomiendo el Protocolo QUIC reflejar perfiles de carga reales frente a CUBIC/BBR‑TCP. De este modo, puedo detectar rápidamente dónde se forman las colas y cómo puedo eliminar los cuellos de botella mediante el control del ritmo o Modelado suavidad.
AQM, ECN y disciplina de búfer: interacción con los algoritmos
El control de congestión solo despliega todo su potencial cuando se combina con la gestión de colas de los dispositivos de red. El clásico Tail Drop llena los búferes hasta el límite y luego descarta paquetes de forma repentina, lo que provoca picos de latencia y efectos de sincronización. La gestión activa de colas (AQM), como CoDel o FQ-CoDel, marca o descarta paquetes de forma temprana y distribuye la capacidad de forma más equitativa entre los flujos. Esto beneficia a todos los procesos: CUBIC pierde menos cwnd por caídas de ráfagas y BBR mantiene su MarchaEstrategia más estable, ya que las colas no „se desbordan“.
ECN (Explicit Congestion Notification) completa esta imagen. En lugar de descartar paquetes, los routers marcan la congestión con un bit CE; los puntos finales reducen la velocidad sin necesidad de retransmisiones. Los algoritmos basados en pérdidas reaccionan así antes y de forma más suave, mientras que los procedimientos basados en modelos, como BBR, interpretan las señales en el contexto del RTT mínimo. En los centros de datos, DCTCP con ECN consistente permite retrasos de cola muy bajos con una alta utilización. En la WAN, utilizo ECN de forma selectiva: solo cuando las rutas transmiten las marcas de forma consistente y los middleboxes no intervienen. En redes públicas mixtas, sigue siendo necesario configurar AQM correctamente, en lugar de simplemente aumentar el búfer.
Ráfagas, descargas y ritmo del host
Muchas caídas de rendimiento se deben a ráfagas de transmisión en el host. Las descargas grandes (TSO/GSO) agrupan segmentos en tramas muy grandes; sin Marcha Estos paquetes se descargan en picos cortos y llenan las colas del conmutador. Por lo tanto, en Linux configuro sch_fq o FQ-CoDel como default_qdisc y utilizo las tasas de ritmo especificadas por el algoritmo CC. BBR se beneficia especialmente de ello, pero CUBIC también se vuelve más estable. Los búferes de anillo NIC demasiado grandes y un txqueuel demasiado alto alargan las colas en el host; yo elijo valores moderados y observo con tc -s qdisc si se producen drops o marcas ECN.
En el lado receptor, GRO/LRO influyen en la latencia de los flujos pequeños. Para cargas de trabajo con gran volumen de API, vale la pena probar o reducir estas descargas en función de la NIC y el kernel, para que los ACK se procesen más rápidamente. En configuraciones de contenedores, compruebo los pares veth y los host-Qdiscs: la cola reside en la interfaz del host, no en el espacio de nombres. Quienes utilicen cgroups para la gestión del ancho de banda deben establecer límites coherentes con CC y AQM, ya que, de lo contrario, se producirán interferencias impredecibles entre los flujos.
Perfiles de carga de trabajo: flujos cortos, elefantes y streaming
No todas las aplicaciones requieren el mismo control de congestión. Los flujos „mice“ (pequeñas transferencias) predominan en las API web y las páginas dinámicas. En este caso, lo que importa es la rapidez con la que la conexión entra en la fase de uso y lo bajas que se mantienen las latencias de cola. BBR mantiene las colas planas y favorece los flujos de corta duración, mientras que CUBIC proporciona valores medios sólidos con una distribución justa de la capacidad. El tamaño inicial de la ventana (initcwnd) y los ajustes de Delayed-ACK influyen en los primeros RTT: los valores predeterminados conservadores protegen contra los picos, pero no deben ralentizar demasiado los primeros kilobytes.
„Los flujos “Elephant» (copias de seguridad, replicación, descargas de gran tamaño) requieren una carga estable durante largos periodos de tiempo. CUBIC se adapta de forma sólida a diferentes RTT y se comparte de forma equitativa con flujos paralelos. BIC ofrece velocidades máximas en redes controladas con patrones de caída conocidos, pero presenta desventajas en caso de coexistencia. Para la transmisión en directo y la interacción en tiempo real (VoIP, juegos), evito sistemáticamente las colas estáticas: BBR sigue siendo la primera opción, siempre que los búferes sean pequeños y AQM sea eficaz. Las interacciones Nagle (TCP_NODELAY) y el procesamiento por lotes de aplicaciones influyen: quien genere muchas escrituras pequeñas debería desactivar Nagle de forma selectiva y dejar el ritmo a la granularidad fina.
Metodología de medición: pruebas realistas y métricas significativas
Las buenas decisiones requieren mediciones reproducibles. Combino la carga sintética con condiciones de ruta reales: emulación controlada de RTT, fluctuación y pérdida (por ejemplo, en enlaces de prueba) más ubicaciones de destino reales. Mido el ancho de banda como goodput y lo correlaciono con los patrones de RTT, las retransmisiones y las proporciones fuera de orden. Las latencias P50/P95/P99 dicen más que los valores medios, especialmente en lo que respecta a los tiempos de respuesta de la API y la interactividad. Para TCP, examino las curvas cwnd y pacing_rate y compruebo las estadísticas Qdisc del lado del host, así como la saturación de la CPU, para poder asignar correctamente los cuellos de botella.
Las pruebas individuales pueden ser engañosas: los flujos paralelos por host y el tráfico cruzado crean situaciones de competencia realistas. La hora del día, las rutas de peering y las condiciones de radio varían; repito las mediciones en series temporales y compruebo la sensibilidad a pequeñas tasas de caída. Para QUIC, comparo cargas de trabajo idénticas con TCP, de modo que los niveles de aplicación y transporte se evalúen por separado. Solo cuando las mediciones se mantienen estables sin interferencias, me comprometo a tomar una decisión en la producción.
Errores frecuentes y soluciones rápidas
El aumento constante del RTT bajo carga, junto con una caída simultánea del goodput, indica Bufferbloat Activar AQM, ajustar el ritmo del host y, si es necesario, utilizar BBR. Muchas retransmisiones sin patrones de caída claros indican reordenación o compresión ACK; los Qdiscs basados en FQ y un pacing limpio ayudan. Los bloqueos repentinos con ACK ausentes suelen indicar problemas de Path MTU; activo MTU Probing y aplico MSS Clamping en las transiciones relevantes.
La distribución desigual entre flujos se manifiesta cuando algunas conexiones tienen una ventaja permanente: CUBIC mejora la equidad RTT en comparación con los algoritmos Loss más antiguos, BBR necesita una disciplina de búfer limpia; en el caso de búferes pequeños, un ajuste más preciso del ritmo o un retorno a CUBIC pueden garantizar la coexistencia. En entornos de contenedores se crean colas „ocultas“ en los extremos veth: sin límites Qdisc y cgroup coordinados, los atascos se desplazan al host, lejos de la aplicación.
Directrices operativas: decisiones sobre equipos y plataformas
Incorporo el control de la congestión en los estándares de la plataforma: valores predeterminados uniformes de Qdisc, perfiles CC definidos por clúster y guías para las desviaciones. Para Usuarios Separo las cargas de trabajo según su sensibilidad a la latencia: las API front-end tienen prioridad con BBR y AQM estricto, las transferencias masivas con CUBIC. La telemetría es obligatoria: distribución RTT, goodput, retransmisiones y cuotas ECN como series temporales. El equipo implementa los cambios mediante experimentos porcentuales y compara P95/P99, no solo valores medios. De este modo, las decisiones de CC son repetibles y comprensibles, y no se basan en corazonadas.
Lista de verificación para la decisión
Primero compruebo los intervalos RTT y las tasas de error, ya que son los que dominan el comportamiento. A continuación, decido si la prioridad es la latencia o el rendimiento y realizo pruebas específicas con respecto a esta métrica. En el siguiente paso, mido la equidad con flujos paralelos para evitar sorpresas durante el funcionamiento. A continuación, compruebo los tamaños de los búferes, los procedimientos AQM y los ajustes de ritmo en el host y en las puertas de enlace. Por último, valido bajo carga si la elección con usuarios reales y Rutas lleva.
Balance corto
Reno y NewReno ofrecen un comportamiento de referencia claro, pero parecen ralentizarse en rutas largas. CUBIC es el estándar en casi todos los alojamientos Linux, ya que aprovecha bien los RTT largos y se comporta de forma justa. BIC convence en redes con caídas notables, cuando la utilización máxima es más importante que la vecindad. BBR permite latencias bajas y tiempos de respuesta constantes, pero requiere atención a los búferes y la coexistencia. Quien compare claramente los objetivos, las características de la ruta y las colas del host, establecerá el control de congestión como un verdadero Palanca para la experiencia del usuario y los costes.
