Résumé

  • Le Silly Window Syndrome était une boucle stable : chaque petite avancée de fenêtre déclenchait un petit envoi qui consommait immédiatement l'espace annoncé.
  • Le remède fut partagé : le destinataire retarde l'annonce d'une capacité marginale, tandis que l'émetteur peut attendre une occasion d'envoi réellement utile.
  • L'algorithme de Nagle vise une autre origine des petits segments, les écritures minuscules de l'application, et complète donc l'évitement du SWS.

Une protection devenue fabrique de paquets

La fenêtre de réception indique la quantité de données supplémentaires que le destinataire accepte. Elle fixe une limite, mais ne commande pas à l'émetteur d'exploiter chaque octet dès qu'il apparaît.

Supposons un tampon plein. L'application consomme un octet ; le destinataire peut annoncer un octet de place. L'émetteur le remplit, le tampon redevient plein, puis l'application libère l'octet suivant. Les deux machines respectent le protocole, mais paient en en-têtes, acquittements, interruptions et ordonnancement pour presque aucun contenu.

RFC 813 a nommé cette cadence stable « Silly Window Syndrome ». La découverte dépassait la performance : deux décisions locales correctes pouvaient former un système inefficace. La comptabilité des octets restait parfaite alors que leur unité d'échange devenait absurde.

Le destinataire a cessé de publier chaque amélioration

Le destinataire connaît son propre tampon. Il peut donc garder fixe le bord droit de la fenêtre annoncée lorsque l'application ne libère qu'un faible espace. La capacité non annoncée s'accumule, puis devient une ouverture plus grande lorsque son utilisation peut amortir le travail d'un segment.

Cette attente ne falsifie rien. Elle ne retire pas une autorisation déjà donnée et ne nie pas l'espace disponible. Elle distingue seulement une mesure exacte d'une invitation prête à être utilisée. RFC 1122 et la spécification TCP moderne décrivent ce mécanisme côté réception et un seuil pratique lié au tampon et à la taille maximale effective des segments.

L'émetteur a cessé de confondre plafond et ordre

Tous les correspondants ne retiendront pas leurs petites annonces. L'émetteur possède donc sa propre décision. La fenêtre interdit de dépasser un plafond ; elle n'oblige pas à expédier immédiatement jusqu'à ce plafond.

L'évitement du SWS côté émission attend notamment qu'un segment complet puisse partir, qu'un envoi poussé puisse être correctement terminé, qu'une part significative de la plus grande fenêtre observée soit utilisable, ou qu'un délai de sauvegarde impose finalement le progrès. L'émetteur estime la mémoire distante à partir de ce qu'il a vu ; le délai l'empêche de transformer une mauvaise estimation en blocage permanent.

RFC 9293 conserve des sections distinctes pour les algorithmes de l'émetteur et du destinataire. Ce découpage est essentiel : chacun gouverne une décision qu'il peut observer sans administrer la mémoire de l'autre.

Nagle traitait un autre filet

Une fenêtre large n'empêche pas une application de remettre ses données caractère par caractère. RFC 896 a décrit le coût de ces petits paquets : un octet de charge utile pouvait alors voyager avec environ quarante octets d'en-têtes TCP/IP.

La règle adaptative de Nagle laisse les nouvelles petites écritures s'accumuler tant qu'un petit segment n'est pas acquitté. Un acquittement ou un volume suffisant libère l'envoi suivant. Elle suit ainsi le retour réel de la connexion au lieu d'imposer un délai fixe.

Les deux remèdes n'observent pas le même signal. Nagle répond aux données que l'application fournit par petits morceaux ; le SWS côté émission répond à la fenêtre que le pair ouvre par petits morceaux. Une application sensible à la latence peut désactiver Nagle sans faire disparaître le problème des fenêtres minuscules.

La retenue devait rester révocable

Attendre peut économiser le réseau, mais attendre sans limite crée une nouvelle panne. Le délai de sauvegarde préserve donc une voie vers le progrès. La conception distribue une autorité étroite : le destinataire choisit quand sa mémoire devient une offre, l'émetteur choisit quand une offre mérite un segment, et l'application assume son choix de latence.

Sources et limites

Le mécanisme est documenté par RFC 793, RFC 813, RFC 896, RFC 1122 et RFC 9293. Ces textes établissent la conception, pas la fréquence actuelle du syndrome dans chaque système. Le SWS ne doit pas être confondu avec la fenêtre de congestion ou la perte de paquets.