L’usage systématique de l’option TCP_NODELAY

Importance du paramétrage de TCP_NODELAY

• Lors du débogage de problèmes de latence dans les systèmes distribués, la première chose à vérifier est si l’option TCP_NODELAY est activée
• De nombreux développeurs de systèmes distribués ont déjà résolu rapidement des problèmes de latence en activant cette simple option de socket
• Cela suggère que le comportement par défaut est peut-être inadapté ou que le concept dans son ensemble est devenu obsolète

Contexte et limites de l’algorithme de Nagle

• Proposé pour la première fois en 1984 dans la RFC896 de John Nagle, l’algorithme de Nagle visait à mieux amortir le coût des en-têtes TCP afin d’obtenir un meilleur débit sur le réseau
• L’algorithme de Nagle fonctionne en bloquant l’envoi de nouveaux segments TCP tant que l’accusé de réception des données précédemment envoyées n’a pas été reçu
• Cependant, cela pose problème lorsqu’il interagit avec les delayed ACK
  • L’algorithme de Nagle bloque l’envoi de données supplémentaires jusqu’à la réception d’un ACK, tandis que les delayed ACK retardent cet ACK jusqu’à ce qu’une réponse soit prête
  • C’est utile pour remplir les paquets, mais beaucoup moins pour les applications en pipeline sensibles à la latence

L’utilité de l’algorithme de Nagle dans les systèmes modernes

• Les serveurs modernes peuvent effectuer une quantité énorme de travail en quelques centaines de microsecondes ; retarder une transmission de données ne serait-ce que d’un seul RTT n’apporte donc pas forcément d’avantage clair
• La plupart des bases de données distribuées et des systèmes modernes n’envoient pas de paquets d’un seul octet
  • Cela s’explique par la quantité de données à transmettre, ainsi que par l’overhead de protocoles comme TLS, sans compter l’overhead d’encodage et de sérialisation
• Éviter l’envoi de petits messages reste important, mais cela est aujourd’hui géré efficacement au niveau de la couche applicative

Avis sur l’usage de TCP_NODELAY

• Lorsqu’on construit un système distribué sensible à la latence, on peut activer TCP_NODELAY (désactiver l’algorithme de Nagle) sans trop d’inquiétude
• Dans les systèmes modernes, compte tenu du trafic, du mix applicatif et des performances matérielles, l’algorithme de Nagle n’est peut-être plus nécessaire
  • Autrement dit, TCP_NODELAY devrait être la valeur par défaut
  • Cela peut ralentir certains codes qui écrivent « tous les octets », mais si l’efficacité est importante, il faudra de toute façon corriger ces applications

L’avis de GN⁺

• Le problème d’interaction entre l’algorithme de Nagle et les delayed ACK est un bon exemple de la difficulté de concevoir des protocoles. Les concepteurs de systèmes connaissent bien ces situations où deux mécanismes raisonnables produisent ensemble un comportement inattendu.

• L’optimisation de l’envoi de petits messages au niveau applicatif est une tendance générale. Il est important de minimiser l’overhead inutile grâce à un encodage et une sérialisation efficaces.

• Si l’objectif initial de l’algorithme de Nagle était d’optimiser la bande passante réseau, la priorité actuelle est davantage à la réduction de la latence. Dans les contextes où la réactivité d’une application a un impact direct sur l’expérience utilisateur, il faut éviter les délais inutiles.

• Cela dit, faire de TCP_NODELAY le comportement par défaut n’est pas forcément idéal dans tous les cas. Dans des environnements à bande passante limitée, ou dans des systèmes où l’efficacité de transmission compte bien plus que la latence, il peut être pertinent d’utiliser l’algorithme de Nagle de manière sélective.

• Lors de la conception de protocoles réseau, il est important de trouver un équilibre entre des exigences variées. Modifier le comportement par défaut d’un protocole générique demande de la prudence, mais il semble également nécessaire de conserver la flexibilité permettant de choisir les options adaptées aux besoins de l’application.

[GN⁺]

Commentaire Hacker News

Résumé :

• L’algorithme de Nagle cherchait à regrouper les écritures, et selon le matériel, le réseau, l’application et le cas d’usage, les écritures groupées peuvent être préférables
• Une grande partie de l’informatique actuelle utilise des écritures groupées, et de nouveaux protocoles de plus haut niveau comme QUIC effectuent eux aussi ce regroupement, en déplaçant la gestion indépendante des connexions et des erreurs de TCP vers l’espace utilisateur
• Lorsque le réseau devient saturé, l’algorithme de Nagle réapparaîtra plus en profondeur dans le code applicatif sous la forme d’ajustements de QUIC
• L’algorithme de Nagle est également utile lorsque les paquets par seconde (PPS) sont saturés à cause de petits paquets
• Comme l’algorithme de Nagle ne fonctionne pas bien pour certaines charges de travail, il est préférable que les ingénieurs soient obligés de le définir explicitement lors de la création d’un socket
• Il est possible de désactiver les ACK différés avec l’option de socket TCP_QUICKACK ou via /proc/sys/net/ipv4/tcp_delack_min et /proc/sys/net/ipv4/tcp_ato_min
• Dans un monde où la bande passante est limitée, envoyer des paquets TCP pour chaque octet gaspille la bande passante, d’où la nécessité de l’algorithme de Nagle
• Il n’existe toujours pas de bonne méthode pour activer TCP_NODELAY lorsqu’on n’a pas accès au code source de l’application
• Les langages modernes comme Go activent TCP_NODELAY par défaut, ce qui évite ce problème
• S’il existait un moyen pour une application d’indiquer à la pile TCP qu’elle est un shell interactif, on pourrait laisser TCP_NODELAY désactivé par défaut et ne l’activer que pour cette application, ce qui réduirait la surcharge