Résumé

  • La règle de Nagle permet un premier envoi court lorsqu’aucune donnée antérieure ne reste en attente, puis retient les petites écritures jusqu’à la réception d’un accusé de réception ou à la formation d’un segment complet.
  • Elle est distincte des accusés de réception différés, de l’évitement du Silly Window Syndrome et du contrôle de congestion ; l’application doit aussi pouvoir la désactiver pour une connexion donnée.

Au début de TCP, une application pouvait produire un caractère à la fois. RFC 896, publié en janvier 1984, a décrit le coût de cette pratique : un octet utile pouvait voyager avec quarante octets d’en-têtes TCP et IP. Sur des réseaux hétérogènes et des liaisons fortement chargées, la multiplication des petits paquets pouvait consommer une capacité précieuse dans les passerelles, accroître la congestion et favoriser les pertes.

Les temporisateurs d’agrégation de 200 à 500 millisecondes ne constituaient pas une réponse stable. Un délai convenable sur un réseau local pouvait agréger trop peu de données sur un trajet à long aller-retour ; un délai adapté à ce dernier pouvait rendre l’interaction locale lente. RFC 896 a donc proposé de faire dépendre la permission d’envoyer de l’état d’accusé de réception plutôt que d’une durée fixe.

Le test exposé plus tard dans RFC 1122 est précis : lorsque SND.NXT > SND.UNA, des données transmises restent sans accusé de réception. L’émetteur met alors en tampon les nouvelles données utilisateur, indépendamment du bit PSH, jusqu’à ce que les données en attente soient acquittées ou que suffisamment de données soient réunies pour envoyer un segment complet de taille Eff.snd.MSS. Un segment complet constitue donc une condition de libération indépendante. Si la connexion est inactive et qu’aucune donnée n’est en vol, la première petite écriture peut partir immédiatement.

RFC 1122 recommande l’implémentation de Nagle, tout en imposant que l’application puisse désactiver l’algorithme pour une connexion individuelle. RFC 9293 reprend cette limite normative et rappelle que l’envoi reste soumis au slow start. Cette règle de mise en paquets n’accorde donc aucune permission générale de transmettre sans tenir compte de la congestion.

Elle ne définit pas non plus le moment où le récepteur accuse réception. RFC 9293 distingue Nagle de l’évitement du Silly Window Syndrome et signale que Nagle peut mal interagir avec les accusés de réception différés. Deux mécanismes raisonnables localement peuvent ainsi ajouter un délai à leur frontière, sans que l’un devienne l’autre.

Sources