Quand dois-je utiliser TCP_NODELAY et quand TCP_CORK ?

Question

J'ai compris que les deux désactivaient l'algorithme de Nagle.

Quand devrais-je/ne devrais-je pas utiliser chacun d'entre eux ?

Answer 1

Tout d'abord, les deux ne désactivent pas l'algorithme de Nagle.

L'algorithme de Nagle permet de réduire le nombre de petits paquets de réseau dans le fil. L'algorithme est le suivant : si les données sont plus petites qu'une limite (généralement MSS), on attend de recevoir l'ACK pour les paquets précédemment envoyés et pendant ce temps, on accumule les données de l'utilisateur. Puis envoyer les données accumulées.

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)

Cela aidera dans les applications comme telnet. Cependant, l'attente de l'ACK peut augmenter la latence lors de l'envoi de données en continu. De plus, si le récepteur met en œuvre la "politique d'ACK retardé", cela provoquera une situation de blocage temporaire. Dans de tels cas, la désactivation de l'algorithme de Nagle est une meilleure option.

TCP_NODELAY est donc utilisé pour désactiver l'algorithme de Nagle.

TCP_CORK accumule agressivement les données. Si TCP_CORK est activé dans une socket, il n'enverra pas de données jusqu'à ce que le tampon se remplisse jusqu'à une limite fixe. Similaire à l'algorithme de Nagle, il accumule également les données de l'utilisateur mais jusqu'à ce que le tampon se remplisse jusqu'à une limite fixe et non jusqu'à la réception de l'ACK. Cela sera utile pour envoyer plusieurs blocs de données. Mais vous devez être plus prudent lorsque vous utilisez TCP_CORK.

Jusqu'au noyau 2.6, ces deux options sont mutuellement exclusives. Mais dans les noyaux ultérieurs, elles peuvent exister ensemble. Dans ce cas, la préférence sera donnée à TCP_CORK.

Réf :

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

Answer 2

TCP_NODELAY

Utilisé pour désactiver l'algorithme de Nagle pour améliorer les réseaux TCP/IP et diminuer le nombre de paquets en attendant qu'un accusé de réception des données précédemment envoyées soit reçu pour envoyer les paquets accumulés.

//From the tcp(7) manual :

TCP_CORK (ou TCP_NOPUSH dans FreeBSD)

Si cette option est définie, ne pas envoyer de trames partielles. Toutes les trames partielles en file d'attente sont envoyées lorsque l'option est à nouveau désactivée. Ceci est utile pour préparer les en-têtes avant d'appeler sendfile(2) ou pour optimiser le débit. Tel qu'il est actuellement mis en œuvre, il y a un ** plafond de 200 millisecondes** sur le temps pendant lequel la sortie est bouchée par TCP_CORK . Si ce plafond est atteint, les données en attente sont automatiquement transmises. . Cette option peut être combinée avec TCP_NODELAY seulement depuis Linux 2.5.71. Cette option ne doit pas être utilisée dans du code destiné à être portable.

Answer 3

C'est une optimisation, donc comme toute optimisation :

1. Ne l'utilisez pas
2. Attendez jusqu'à ce que les performances deviennent un problème, puis après avoir déterminé que la latence des sockets est définitivement la cause du problème, et que les tests prouvent que cela va définitivement résoudre le problème, ET que c'est la manière la plus simple de le résoudre, faites-le.

En gros, le but est d'éviter d'avoir à envoyer plusieurs trames là où une seule trame peut être utilisée, avec sendfile() et ses amis.

Ainsi, par exemple, dans un serveur web, vous envoyez les en-têtes suivis du contenu du fichier, les en-têtes seront assemblés en mémoire, le fichier sera ensuite envoyé directement par le noyau. TCP_CORK vous permet d'envoyer les en-têtes et le début du fichier dans une seule trame, même avec TCP_NODELAY, qui autrement provoquerait l'envoi immédiat du premier morceau.

Answer 4

TCP_CORK est l'opposé de TCP_NODELAY. Le premier force le délai d'accumulation des paquets ; le second le désactive.