¿Cuándo debería usar TCP_NODELAY y cuándo TCP_CORK?

Question

Entendí que ambos desactivan el algoritmo de Nagle.

¿Cuándo debo/no debo usar cada uno de ellos?

Answer 1

Primero de todos, ninguno de los dos desactiva el algoritmo de Nagle.

El algoritmo de Nagle es para reducir el número de paquetes de red pequeños en el cable. El algoritmo es: si los datos son más pequeños que un límite (generalmente MSS), espere hasta recibir ACK para los paquetes enviados anteriormente y, mientras tanto, acumule datos del usuario. Luego envíe los datos acumulados.

if [ data > MSS ] 
    send(data) 
else 
    wait until ACK for previously sent data and accumulate data in send buffer (data) 
    And after receiving the ACK send(data) 

Esto ayudará en aplicaciones como telnet. Sin embargo, esperar el ACK puede aumentar la latencia al enviar datos de transmisión. Además, si el receptor implementa la 'política de ACK retrasada', causará una situación de interbloqueo temporal. En tales casos, deshabilitar el algoritmo de Nagle es una mejor opción.

Entonces TCP_NODELAY se usa para deshabilitar el algoritmo de Nagle.

TCP_CORK acumula datos agresivamente. Si TCP_CORK está habilitado en un socket, no enviará datos hasta que el buffer se llene hasta un límite fijo. De forma similar al algoritmo de Nagle, también acumula datos del usuario, pero hasta que el búfer se llena hasta un límite fijo no hasta recibir ACK. Esto será útil al enviar múltiples bloques de datos. Pero debe tener más cuidado al usar TCP_CORK.

Hasta 2.6 kernel, ambas opciones son mutuamente excluyentes. Pero en kernel posterior, ambos pueden existir juntos. En tal caso, a TCP_CORK se le dará más preferencia.

Ref:

• http://baus.net/on-tcp_cork/
• http://ccr.sigcomm.org/archive/2001/jan01/ccr-200101-mogul.pdf

Answer 2

Es una optimización, así como cualquier optimización:

1. No lo utilice
2. Esperar hasta que el rendimiento se convierte en un problema, a continuación, habiendo determinado que la latencia de socket es sin duda la causa de ella, y la prueba demuestra que esto definitivamente lo arreglará, Y esta es la manera más fácil de solucionarlo, hazlo.

Básicamente, el objetivo es evitar tener que enviar varios fotogramas en los que se puede usar un único fotograma, con sendfile() y sus amigos.

Así, por ejemplo, en un servidor web, envía los encabezados seguidos de los contenidos del archivo, los encabezados se ensamblarán en la memoria, el archivo será enviado directamente por el kernel. TCP_CORK le permite enviar los encabezados y el comienzo del archivo en un solo cuadro, incluso con TCP_NODELAY, que de lo contrario causaría que el primer fragmento se envíe inmediatamente.

Answer 3

TCP_CORK es lo contrario de TCP_NODELAY. La antigua fuerza demora de acumulación de paquetes; el último lo deshabilita.

Answer 4

TCP_NODELAY

utilizado para desactivar el algoritmo de Nagle para mejorar las redes TCP/IP y disminuir el número de paquetes esperando hasta se recibe un acuse de recibo de los datos enviados para enviar el paquetes acumulados.

// Desde el TCP (7) Manual:

TCP_CORK (o TCP_NOPUSH en FreeBSD)

Si se establece, no envían tramas parciales. Todos los fotogramas parciales en cola se envían cuando la opción se borra nuevamente. Esto es útil para anteponer los encabezados antes de llamar a sendfile (2), o para la optimización del rendimiento. Tal como se implementa actualmente, hay un límite de 200 milisegundos en el tiempo para el cual TCP_CORK cierra la salida. Si se alcanza este límite máximo, los datos en cola se transmiten automáticamente. Esta opción se puede combinar con TCP_NODELAY solo desde Linux 2.5.71. Esta opción no debe usarse en código destinado a ser portátil.