Définir TCP_QUICKACK et TCP_NODELAY

Utilisez TCP_QUICKACK, pas TCP_NODELAY

L'activation de TCP_NODELAY a des effets similaires, mais peut aggraver le débit pour les petites écritures. Si vous écrivez une boucle qui n'envoie que quelques octets (dans le pire des cas, un octet) à une socket avec "write()", et que l'algorithme de Nagle est désactivé avec TCP_NODELAY, chaque écriture devient un paquet IP. Cela augmente le trafic d'un facteur 40, avec des en-têtes IP et TCP pour chaque charge utile. La prévention Tinygram ne vous permettra pas d'envoyer un deuxième paquet si vous en avez un en vol, à moins que vous n'ayez suffisamment de données pour remplir le paquet de taille maximale. Il accumule les octets pendant un aller-retour, puis envoie tout dans la file d'attente. C'est presque toujours ce que vous voulez. Si vous avez défini TCP_NODELAY, vous devez être beaucoup plus conscient des problèmes de mise en mémoire tampon et de vidage. Rien de tout cela n'a d'importance pour les transferts unidirectionnels en masse, qui sont la plupart du temps HTTP aujourd'hui. (Je n'ai jamais examiné l'impact de cela sur la poignée de main SSL, où cela pourrait avoir de l'importance.) Version courte :définissez TCP_QUICKACK. Si vous trouvez un cas où cela aggrave les choses, faites-le moi savoir. John Nagle

https://news.ycombinator.com/item?id=10608356

Il n'y a pas de relation directe entre ces deux options, elles sont juste à des fins différentes.

TCP_NODELAY est destiné à désactiver/activer la mise en mémoire tampon des segments afin que les données puissent être envoyées à l'homologue aussi rapidement que possible, il est donc généralement utilisé pour améliorer l'utilisation du réseau. TCP_QUICKACK est utilisé pour envoyer des accusés de réception le plus tôt possible que retardé sous certains échanges de niveau de protocole, et ce n'est pas stable/permanent, les transactions TCP ultérieures (qui peuvent se produire sous le capot) peuvent ignorer cette option en fonction du traitement réel au niveau du protocole ou de tout désaccord réel entre le paramètre utilisateur et le comportement de la pile.

REMARQUE TCP_NODELAY est portable tant que TCP_QUICKACK n'est pas (fonctionne uniquement sous Linux 2.4.4+).

TCP_QUICKACK et TCP_NODELAY affecter différentes opérations dans TCP. Le tcp(7) La page de manuel décrit quelles options de socket pour TCP interfèrent les unes avec les autres, par ex. TCP_CORK et TCP_NODELAY .

Réponse courte

• Pour désactiver l'algorithme de mise en mémoire tampon de Nagle, utilisez l'option de socket TCP_NODELAY.
• Pour désactiver les accusés de réception différés, utilisez l'option de socket TCP_QUICKACK.

Détails

• Algorithme de Nagle

  • L'algorithme de Nagle, du nom de son créateur John Nagle, est un mécanisme permettant d'améliorer l'efficacité de TCP en réduisant le nombre de petits paquets envoyés sur le réseau.
  • L'objectif était d'empêcher un nœud de transmettre de nombreux petits paquets si l'application fournit des données au socket assez lentement.
  • Si un processus provoque la transmission de nombreux petits paquets, il peut créer une congestion excessive du réseau. Cela est particulièrement vrai si la charge utile d'un paquet est inférieure aux données d'en-tête TCP.

• ACK retardé

  • L'accusé de réception différé TCP ou l'accusé de réception différé est une autre technique utilisée par certaines implémentations de TCP dans le but d'améliorer les performances du réseau et de réduire la congestion.
  • Delayed ACK a été inventé pour réduire le nombre d'ACK requis pour reconnaître les segments et réduire la surcharge du protocole.
  • Delayed ACK signifie que TCP ne reconnaît pas immédiatement chaque segment TCP reçu. Plusieurs réponses ACK peuvent être combinées en une seule réponse, ce qui réduit la surcharge du protocole.

• L'algorithme de Nagle et l'ACK retardé ne fonctionnent pas bien ensemble dans un réseau TCP/IP

  • Delayed ACK essaie d'envoyer plus de données par segment s'il le peut. Mais une partie de l'algorithme de Nagle dépend d'un ACK pour envoyer des données.
  • L'algorithme de Nagle et les ACK retardés créent ensemble un problème car les ACK retardés attendent pour envoyer l'ACK tandis que Nagle attend pour recevoir l'ACK

• Comment puis-je résoudre les problèmes causés par l'algorithme de Nagle et les accusés de réception retardés ?

  • Activez TCP_NODELAY pour désactiver l'algorithme de Nagle via les options de socket globales sur les serveurs
  • Ajustez les profils des serveurs proxy et des équilibreurs de charge :cela est particulièrement pertinent si vous exécutez des applications ou des environnements qui n'ont qu'occasionnellement un trafic hautement interactif et des protocoles bavards. En activant et désactivant dynamiquement l'algorithme de Nagle et TCP_NODELAY au niveau de l'équilibreur de charge, vous pouvez maintenir un fonctionnement optimal même des mélanges de trafic très hétérogènes.
  • Réduisez le délai d'accusé de réception différé sur vos serveurs et équilibreurs de charge. Parfois, ce type d'optimisation est géré dans le logiciel, au niveau de l'application, mais lorsque ce n'est pas le cas, vous pouvez toujours gérer dynamiquement le minuteur ACK au niveau du serveur ou de l'équilibreur de charge.
  • Pendant que vous apportez ces modifications, surveillez attentivement le trafic de votre réseau et observez l'impact de chaque modification sur la congestion.

Pour plus de détails, veuillez vous référer à ceci