El uso continuo de la opción TCP_NODELAY

La importancia de configurar TCP_NODELAY

• Al depurar problemas de latencia en sistemas distribuidos, lo primero que hay que revisar es si la opción TCP_NODELAY está activada
• Muchos desarrolladores de sistemas distribuidos han resuelto rápidamente problemas de latencia simplemente activando esta opción de socket
• Esto sugiere que el comportamiento predeterminado podría estar equivocado o que todo el concepto podría estar obsoleto

Antecedentes y problemas del algoritmo de Nagle

• El algoritmo de Nagle, propuesto por primera vez en 1984 en el RFC896 de John Nagle, tenía como objetivo obtener un mejor rendimiento de la red amortizando mejor el costo de los encabezados TCP
• El algoritmo de Nagle funciona suprimiendo el envío de nuevos segmentos TCP si todavía no se ha recibido el acuse de recibo de los datos enviados anteriormente
• Sin embargo, esto causa problemas al interactuar con delayed ACK
  • El algoritmo de Nagle bloquea el envío de más datos hasta que se recibe un ACK, mientras que delayed ACK retrasa el ACK hasta que haya una respuesta lista
  • Esto es bueno para llenar paquetes, pero no para aplicaciones en pipeline sensibles a la latencia

La necesidad del algoritmo de Nagle en sistemas modernos

• Los servidores modernos pueden realizar una enorme cantidad de trabajo en unos pocos cientos de microsegundos, por lo que retrasar la transmisión de datos incluso por un solo RTT puede no ofrecer una ventaja clara
• La mayoría de las bases de datos distribuidas y sistemas no envían paquetes de un solo byte
  • Esto se debe a que hay más datos por transmitir y a la sobrecarga de protocolos como TLS, además de la sobrecarga de codificación y serialización
• Sigue siendo importante no enviar mensajes pequeños, pero esto ya se está manejando de forma efectiva en la capa de aplicación

Opinión sobre el uso de TCP_NODELAY

• Al construir sistemas distribuidos sensibles a la latencia, se puede activar TCP_NODELAY sin preocupación alguna, es decir, desactivar el algoritmo de Nagle
• En los sistemas modernos, considerando el tráfico, la mezcla de aplicaciones y el rendimiento del hardware, puede que el algoritmo de Nagle ya no sea necesario
  • Es decir, TCP_NODELAY debería ser el valor predeterminado
  • Esto podría hacer más lento cierto código que escribe byte por byte, pero si la eficiencia importa, esa aplicación de todos modos debería corregirse

La opinión de GN⁺

• El problema de la interacción entre el algoritmo de Nagle y delayed ACK es un buen ejemplo de lo difícil que es diseñar protocolos. Los diseñadores de sistemas reconocerán esta situación en la que dos funciones razonables generan un comportamiento no intencional.

• Optimizar el envío de mensajes pequeños en la capa de aplicación es una tendencia general. Es importante minimizar la sobrecarga innecesaria mediante una codificación y serialización eficientes.

• Si el objetivo del algoritmo de Nagle era optimizar el ancho de banda de la red, hoy en día minimizar la latencia es un requisito más importante. En situaciones donde la capacidad de respuesta de la aplicación impacta directamente la experiencia del usuario, debe evitarse cualquier retraso innecesario.

• Aun así, hacer de TCP_NODELAY el valor predeterminado puede no ser ideal en todos los casos. En entornos con ancho de banda limitado, o en sistemas donde la eficiencia de transmisión es mucho más importante que la latencia, puede ser necesario usar el algoritmo de Nagle de forma selectiva.

• Al diseñar protocolos de red, es importante equilibrar distintos requisitos. Cambiar el comportamiento predeterminado de un protocolo de propósito general requiere cautela, pero también parece necesaria la flexibilidad para elegir las opciones adecuadas según las necesidades de la aplicación.

[GN⁺]

Opinión de Hacker News

Resumen:

• El algoritmo de Nagle fue un intento de hacer escrituras por lotes, y hay casos en los que las escrituras por lotes son mejores sin importar el hardware, la red, la aplicación o el caso de uso
• Hoy en día, gran parte de la computación utiliza escrituras por lotes, y los nuevos protocolos de alto nivel como QUIC también realizan agrupación de escrituras, trasladando al espacio de usuario la gestión independiente de conexiones y errores de TCP
• Cuando la red se satura, el algoritmo de Nagle volverá a aparecer más profundamente en el código de la aplicación en forma de ajustes tipo QUIC
• El algoritmo de Nagle también es útil cuando la saturación se produce por paquetes por segundo (PPS) debido a paquetes pequeños
• El algoritmo de Nagle no funciona bien para algunas cargas de trabajo, por lo que es mejor que los ingenieros deban configurarlo explícitamente al crear sockets
• Es posible desactivar el ACK diferido usando la opción de socket TCP_QUICKACK o /proc/sys/net/ipv4/tcp_delack_min y /proc/sys/net/ipv4/tcp_ato_min
• En un mundo con ancho de banda limitado, enviar paquetes TCP por cada byte desperdicia ancho de banda, por lo que el algoritmo de Nagle es necesario
• Todavía no existe una buena forma de habilitar TCP_NODELAY cuando no se tiene acceso al código fuente de la aplicación
• Los lenguajes modernos como Go habilitan TCP_NODELAY de forma predeterminada, por lo que este problema no ocurre
• Si existiera una forma de que la aplicación le indicara a la pila TCP que se trata de un shell interactivo, se podría dejar TCP_NODELAY desactivado de forma predeterminada y activarlo solo para esa aplicación, reduciendo así la sobrecarga