El algoritmo de Nagle es un medio para mejorar la eficiencia de las redes TCP / IP al reducir la cantidad de paquetes que deben enviarse a través de la red. Fue definido por John Nagle mientras trabajaba para Ford Aerospace . Fue publicado en 1984 como una Solicitud de Comentarios (RFC) con el título Control de Congestión en Internetworks IP / TCP en RFC 896 .
El RFC describe lo que llamó el "problema de los paquetes pequeños", donde una aplicación emite repetidamente datos en pequeños fragmentos, con frecuencia de solo 1 byte de tamaño. Dado que los paquetes TCP tienen un encabezado de 40 bytes (20 bytes para TCP, 20 bytes para IPv4 ), esto da como resultado un paquete de 41 bytes para 1 byte de información útil, una sobrecarga enorme. Esta situación ocurre a menudo en sesiones Telnet , donde la mayoría de las pulsaciones de teclas generan un solo byte de datos que se transmite inmediatamente. Peor aún, en enlaces lentos, muchos de estos paquetes pueden estar en tránsito al mismo tiempo, lo que podría provocar un colapso de la congestión .
El algoritmo de Nagle funciona combinando una serie de pequeños mensajes salientes y enviándolos todos a la vez. Específicamente, siempre que haya un paquete enviado para el que el remitente no haya recibido acuse de recibo, el remitente debe seguir almacenando en búfer su salida hasta que tenga el valor de salida de un paquete completo, permitiendo así que la salida se envíe de una vez.
Algoritmo
El RFC define el algoritmo como
inhibir el envío de nuevos segmentos TCP cuando llegan nuevos datos salientes del usuario si cualquier dato transmitido previamente en la conexión permanece sin acuse de recibo.
Donde MSS es el tamaño máximo de segmento , el segmento más grande que se puede enviar en esta conexión y el tamaño de la ventana es la ventana actualmente aceptable de datos no reconocidos, esto se puede escribir en pseudocódigo como [ cita requerida ]
si hay nuevos datos para enviar, entonces si el tamaño de la ventana ≥ MSS y los datos disponibles son ≥ MSS, entonces enviar segmento MSS completo ahora de lo contrario, si todavía hay datos no confirmados en la tubería , poner en cola los datos en el búfer hasta que se reciba un acuse demás enviar datos inmediatamente terminar si terminar si terminar si
Interacción con ACK retrasado
Este algoritmo interactúa mal con los reconocimientos retardados de TCP (ACK retardado), una característica introducida en TCP aproximadamente al mismo tiempo a principios de la década de 1980, pero por un grupo diferente. Con ambos algoritmos habilitados, las aplicaciones que realizan dos escrituras sucesivas en una conexión TCP, seguidas de una lectura que no se completará hasta que los datos de la segunda escritura hayan llegado al destino, experimentan un retraso constante de hasta 500 milisegundos, el " Retraso ACK ". Se recomienda deshabilitar cualquiera de los dos, aunque tradicionalmente es más fácil deshabilitar Nagle, ya que dicho interruptor ya existe para aplicaciones en tiempo real.
Una solución recomendada por Nagle es evitar que el algoritmo envíe paquetes prematuros almacenando en búfer las escrituras de la aplicación y luego vaciando el búfer: [1]
La solución a nivel de usuario es evitar secuencias de escritura-escritura-lectura en sockets. Escribir-leer-escribir-leer está bien. Escribir-escribir-escribir está bien. Pero escribir-escribir-leer es un asesino. Entonces, si puede, almacene sus pequeñas escrituras en TCP y envíelas todas a la vez. El uso del paquete de E / S estándar de UNIX y el vaciado de la escritura antes de cada lectura suele funcionar.
Nagle considera que los ACK retrasados son una "mala idea", ya que la capa de aplicación no suele responder dentro de la ventana de tiempo. [2] Para casos de uso típicos, recomienda deshabilitar el "ACK retrasado" en lugar de su algoritmo, ya que los ACK "rápidos" no generan tanta sobrecarga como muchos paquetes pequeños. [3]
Deshabilitar Nagle o ACK retrasado
Las implementaciones de TCP generalmente proporcionan a las aplicaciones una interfaz para deshabilitar el algoritmo de Nagle. A esto se le suele llamar TCP_NODELAY
opción. En Microsoft Windows, el TcpNoDelay
conmutador de registro decide el valor predeterminado. TCP_NODELAY
está presente desde la pila TCP / IP en 4.2BSD de 1983, una pila con muchos descendientes. [4]
La interfaz para deshabilitar el ACK retrasado no es coherente entre los sistemas. La TCP_QUICKACK
bandera está disponible en Linux desde 2001 (2.4.4) y potencialmente en Windows, donde está la interfaz oficial SIO_TCP_SET_ACK_FREQUENCY
. [5] La configuración TcpAckFrequency
en 1 en el registro de Windows desactiva el ACK retrasado de forma predeterminada. [6]
Efecto negativo en escrituras más grandes
El algoritmo de Nagle se aplica a escrituras de datos de cualquier tamaño. Si los datos en una sola escritura abarcan 2 n paquetes, donde hay 2 n -1 segmentos TCP de tamaño completo seguidos de un segmento TCP parcial, el algoritmo de Nagle original retendría el último paquete, esperando que se envíen más datos (a llenar el paquete), o el ACK del paquete anterior (que indica que todos los paquetes anteriores han abandonado la red). [7]
En cualquier protocolo de aplicación de solicitud-respuesta de parada y espera sin canalización donde los datos de la solicitud pueden ser más grandes que un paquete, esto puede imponer artificialmente una latencia de unos cientos de milisegundos entre el solicitante y el respondedor. Originalmente, esto no se consideró un problema, ya que cualquier protocolo de parada y espera sin canalización probablemente no esté diseñado para lograr un alto rendimiento en primer lugar, por lo que unos pocos cientos de milisegundos de retraso adicional deberían hacer poca diferencia. Un refinamiento posterior al algoritmo de Nagle, llamado Modificación de Minshall, [8] resolvió este problema con protocolos de parada y espera que envían un mensaje y luego esperan un acuse de recibo antes de enviar el siguiente, eliminando el incentivo para que desactiven el algoritmo de Nagle (aunque dichos protocolos seguirán estando limitados por su diseño a un intercambio de mensajes por tiempo de ida y vuelta de la red).
En general, dado que el algoritmo de Nagle es solo una defensa contra las aplicaciones descuidadas, deshabilitar el algoritmo de Nagle no beneficiará a las aplicaciones escritas más cuidadosamente que se ocupan del almacenamiento en búfer. La desactivación del algoritmo de Nagle permitirá que la aplicación tenga muchos paquetes pequeños en vuelo en la red a la vez, en lugar de una cantidad menor de paquetes grandes, lo que puede aumentar la carga en la red y puede o no beneficiar el rendimiento de la aplicación.
Interacciones con sistemas en tiempo real
Las aplicaciones que esperan respuestas en tiempo real y baja latencia pueden reaccionar mal con el algoritmo de Nagle. Las aplicaciones como los videojuegos multijugador en red o el movimiento del mouse en un sistema operativo controlado remotamente esperan que las acciones se envíen de inmediato, mientras que el algoritmo retrasa intencionalmente la transmisión, aumentando la eficiencia del ancho de banda a expensas de la latencia . Por esta razón, las aplicaciones con transmisiones sensibles al tiempo de bajo ancho de banda suelen utilizar TCP_NODELAY
para evitar el retardo de ACK retardado por Nagle. [9]
Otra opción es usar UDP en su lugar.
Implementación de sistemas operativos
La mayoría de los sistemas operativos modernos implementan los algoritmos de Nagle. En AIX [10] y Linux y Windows [11] está habilitado de forma predeterminada y se puede inhabilitar por socket utilizando la TCP_NODELAY
opción.
Referencias
- ^ John Nagle (19 de enero de 2006), Boosting Socket Performance on Linux , Slashdot
- ^ Nagle, John. "Suspiro. Si estás haciendo transferencias de archivos masivas, nunca te encuentras con ese problema. (Responde 9048947)" . Noticias de hackers . Consultado el 9 de mayo de 2018 .
- ^ Nagle, John. "Ese temporizador de retardo ACK fijo de 200ms fue un error horrible. ¿Por qué 200ms? Tiempo de reacción humano. (Respuesta 9050645)" . Noticias de hackers . Consultado el 9 de mayo de 2018 .
- ^ Manual de interfaces del kernel de FreeBSD -
- ^ "sockets - C ++ Desactivar Ack retrasado en Windows" . Desbordamiento de pila .
- ^ "Nueva entrada de registro para controlar el comportamiento de reconocimiento de TCP (ACK) en Windows XP y en Windows Server 2003" .
- ^ "Problemas de rendimiento de TCP causados por la interacción entre el algoritmo de Nagle y el ACK retrasado" . Stuartcheshire.org . Consultado el 14 de noviembre de 2012 .
- ^ Una modificación propuesta al algoritmo de Nagle . Proyecto de identificación-minshall-nagle.
- ^ Error 17868: algunas aplicaciones Java son lentas en las conexiones X remotas .
- ^ "Centro de conocimiento de IBM" . www.ibm.com .
- ^ "¿Cómo se puede desactivar el algoritmo de Nagle en Linux?" . Desbordamiento de pila .
- Larry L. Peterson , Bruce S. Davie (2007). Redes de computadoras: un enfoque de sistemas (4 ed.). Morgan Kaufmann. pag. 402–403. ISBN 978-0-12-374013-7.Mantenimiento de CS1: utiliza el parámetro de autores ( enlace )
enlaces externos
- Nagle se retrasa en el algoritmo de Nagle
- Algoritmo de Nagle
- Problemas de rendimiento de TCP causados por la interacción entre el algoritmo de Nagle y el ACK retrasado
- Problemas de diseño: envío de pequeños segmentos de datos a través de TCP con Winsock