Hace pocos días, Marc Brooker, un ingeniero de AWS, critico y abordó los problemas con los cuales siempre ha tenido que lidiar en el tema eficiencia en las transferencias de mensajes pequeños cuando se utiliza el algoritmo Nagle.

Y es que menciona que hoy en día en los sistemas distribuidos, la latencia es un factor crítico que puede impactar significativamente en el rendimiento y la experiencia del usuario y una de las soluciones clave es la configuración de parámetros como TCP_NODELAY.

Marc menciona que a pesar de que «los problemas de latencia que se solucionaron rápidamente al habilitar esta opción de socket simple» TCP_NODELAY, esta no se encuentra habilitada, ya que la opción predeterminada en la pila TCP/IP es el algoritmo de Nagle.

El algoritmo de Nagle, formulado en el RFC896 por John Nagle en 1984, tuvo como objetivo abordar la eficiencia en la transmisión de datos en redes TCP. Este permite agregar mensajes pequeños para reducir el tráfico, suspendiendo el envío de nuevos segmentos TCP hasta que se reciba la confirmación de recepción de los datos enviados anteriormente. Por ejemplo, sin aplicar agregación, al enviar 1 byte se envían 40 bytes adicionales con encabezados de paquetes TCP e IP. En las condiciones modernas, el uso del algoritmo Nagle provoca un aumento notable de los retrasos, lo cual es inaceptable para aplicaciones interactivas y distribuidas.

Una de las complejidades que surgieron con la implementación del algoritmo de Nagle fue su interacción con los ACK retardados. Mientras Nagle buscaba optimizar el tamaño de los paquetes enviados, los ACKs retardados retrasaban el envío de confirmaciones de paquetes recibidos. Esta combinación puede generar problemas de latencia en aplicaciones sensibles a este factor.

Además de ello, Marc ha citado tres razones principales para utilizar TCP_NODELAY como predeterminada, en lugar de Nagle, el cual suguiere sea deshabilitado:

1. Incompatibilidad con la optimización «ACK retrasado»: El algoritmo de Nagle entra en conflicto con la estrategia de «ACK retrasado», donde la respuesta ACK no se envía inmediatamente sino después de recibir los datos de la respuesta. El problema radica en que, en el algoritmo de Nagle, la llegada de un paquete ACK es una señal para enviar datos agregados. Si el paquete ACK no se recibe, el envío se realiza cuando se agota el tiempo de espera. Esto crea un ciclo el paquete ACK como señal no funciona porque el otro lado no recibe los datos debido a su acumulación en el lado del remitente, y el remitente no los envía antes del tiempo de espera al no recibir el paquete ACK.
2. Antigüedad del RFC del algoritmo de Nagle: El RFC para el algoritmo de Nagle se adoptó en 1984 y no está diseñado para las redes y servidores modernos de alta velocidad en los centros de datos, lo que genera problemas de capacidad de respuesta. En las redes modernas, el retraso entre el envío de una solicitud y la recepción de una respuesta (RTT) es muy corto, lo que permite a los servidores modernos realizar una enorme cantidad de trabajo durante estos breves intervalos de tiempo.
3. Cambios en el patrón de envío de datos: Las aplicaciones distribuidas modernas ya no envían bytes individuales de datos, y la agregación de datos pequeños generalmente se implementa en el nivel de la aplicación. Incluso si el tamaño de la carga útil es mínimo, el tamaño real de la información enviada aumenta significativamente después de aplicar la serialización, el uso de APIs JSON y el envío mediante cifrado TLS. Por lo tanto, el ahorro de 40 bytes se vuelve menos relevante en comparación con el rendimiento y la capacidad de respuesta mejorados al deshabilitar el algoritmo de Nagle.

Es por ello que Brooker ha hecho un llamado para deshabilitar el algoritmo Nagle de forma predeterminada. Esto se puede lograr configurando la opción TCP_NODELAY para sockets de red usando la llamada setsockopt, como se ha hecho durante mucho tiempo en proyectos como Node.js y curl.

Finalmente, si estás interesado en poder conocer más al respecto, puedes consultar los detalles en el siguiente enlace.