Le problème, c’est toujours TCP_NODELAY

• Lors du débogage des problèmes de latence dans les systèmes distribués, la première chose à vérifier est toujours le paramètre TCP_NODELAY
• L’algorithme de Nagle est une approche proposée en 1984 dans la RFC896, conçue pour réduire la surcharge des en-têtes TCP lors de l’envoi de petits paquets
• Cependant, lorsqu’il est combiné au mécanisme de delayed ACK, l’envoi des données est retardé jusqu’à la réception de l’ACK, ce qui dégrade les performances des applications sensibles à la latence
• Dans les environnements modernes de datacenter, le RTT est très court et la plupart des systèmes envoient déjà de gros messages, si bien que les bénéfices de l’algorithme de Nagle ont presque disparu
• Par conséquent, dans les systèmes distribués modernes, TCP_NODELAY devrait être activé par défaut, et l’algorithme de Nagle n’est plus vraiment nécessaire

---

Contexte de l’algorithme de Nagle

• En 1984, la RFC896 de John Nagle a été proposée pour résoudre le problème d’une surcharge de 4000 % avec 40 octets d’en-tête pour 1 octet de données, typique des petits envois comme la saisie au clavier
  • À l’époque, le problème venait du fait que de petits paquets étaient envoyés à chaque caractère tapé, ce qui réduisait l’efficacité réseau
  • La solution consistait à interdire l’envoi d’un nouveau segment tant que les données précédentes n’avaient pas été acquittées
• Cette approche était efficace dans les conditions réseau de l’époque, mais elle est inadaptée aux systèmes modernes où la latence est cruciale

Interaction entre l’algorithme de Nagle et le delayed ACK

• Le delayed ACK (RFC813, RFC1122) est un mécanisme où le récepteur n’envoie pas immédiatement un ACK, mais le retarde jusqu’à ce qu’il ait des données de réponse ou qu’un timer expire
• L’algorithme de Nagle suspend l’envoi en attendant un ACK, tandis que le delayed ACK retarde cet ACK, ce qui crée une situation de blocage où les deux côtés s’attendent mutuellement
• John Nagle lui-même a qualifié cette combinaison de « combinaison horrible », soulignant que ces deux mécanismes ont été introduits indépendamment mais provoquent de la latence lorsqu’ils sont utilisés ensemble

Les problèmes dans l’environnement moderne

• Dans un datacenter, le RTT est d’environ 500 μs, et même dans une même région on reste à quelques millisecondes seulement
• Dans un tel contexte, retarder l’envoi d’un RTT complet entraîne une perte de performance
• De plus, les systèmes distribués modernes envoient déjà des messages suffisamment volumineux en raison de TLS, de la sérialisation et de la surcharge des protocoles, si bien que le problème des paquets d’un seul octet a quasiment disparu
• L’optimisation des petits messages est désormais traitée au niveau applicatif

Pourquoi TCP_NODELAY est nécessaire

• Dans les systèmes distribués sensibles à la latence, il est recommandé d’activer TCP_NODELAY afin de désactiver l’algorithme de Nagle
  • Ce n’est ni « inefficace » ni un « mauvais réglage », mais un choix adapté aux caractéristiques du matériel moderne et du trafic actuel
• L’auteur soutient que TCP_NODELAY devrait être la valeur par défaut
  • Certains codes qui « envoient à chaque appel à write() » peuvent devenir plus lents, mais ce type de code devrait être corrigé à la racine

Autres options liées

• L’option TCP_QUICKACK réduit le délai des ACK, mais les problèmes de portabilité et le comportement incohérent en font une solution non fondamentale
• Le vrai problème est que le noyau conserve les données plus longtemps que le moment voulu par l’application, alors qu’elles devraient être envoyées immédiatement lors de l’appel à write()

Conclusion

• L’algorithme de Nagle a été une excellente invention pour améliorer l’efficacité réseau par le passé, mais
  dans les réseaux rapides modernes et les environnements de systèmes distribués, il est devenu une fonctionnalité d’un autre âge qui ajoute de la latence
• Par conséquent, activer systématiquement TCP_NODELAY est présenté comme un principe de base de la conception des systèmes modernes