Résumé

  • Une fenêtre de réception nulle est une instruction valable : le récepteur n’accepte momentanément aucun nouvel octet. Elle ne prouve ni une panne du pair ni une congestion du chemin.
  • Un ACK pur annonçant la réouverture peut se perdre sans être retransmis. TCP envoie donc une sonde bornée, puis espace les suivantes de façon exponentielle, afin d’obtenir une fenêtre actuelle.
  • Tant que le récepteur répond, TCP doit préserver la connexion. L’application et le système d’exploitation conservent toutefois le pouvoir explicite de libérer leurs ressources et d’interrompre l’attente.

Le blocage ne supposait aucune faute

Le récepteur remplit son tampon parce que le programme local ne consomme plus les données. Il annonce zéro. Le serveur cesse correctement d’envoyer. Lorsque le programme lit enfin quelques octets, TCP retourne un ACK portant une fenêtre positive. Si cet ACK disparaît, le serveur ne possède toujours que l’ancienne interdiction et le récepteur peut croire avoir déjà annoncé la reprise.

RFC 1122 rappelle la cause : un ACK sans données n’est pas transmis de façon fiable comme les données. Une notification de fenêtre nulle peut donc être parfaitement respectée, sa levée parfaitement émise, et la connexion rester bloquée. La fiabilité devait aussi protéger la modification du droit d’envoyer.

Zéro décrivait une capacité, pas un état de santé

RFC 813 distingue la fenêtre offerte par le récepteur et la fenêtre utilisable calculée par l’émetteur après déduction des octets déjà en vol. Cette valeur est un instrument de contrôle de flux. Elle répond à la question « combien puis-je accepter maintenant ? », non à « pourquoi mon application ne lit-elle pas ? ».

L’exemple historique de l’imprimante sans papier est volontairement ordinaire. L’hôte peut répondre, le réseau peut fonctionner et l’application peut attendre une intervention humaine légitime. Fermer la connexion parce que la fenêtre demeure nulle transformerait une politique locale inconnue en verdict de panne.

La fenêtre de réception n’est pas davantage la fenêtre de congestion. La première protège les buffers du pair ; la seconde limite la pression exercée sur le chemin. Un chemin calme peut mener à un récepteur saturé, et un récepteur disponible peut être atteint par un réseau congestionné.

Une exception minuscule rendit la permission récupérable

RFC 793 posa le mécanisme. RFC 9293 exige toujours la sonde de fenêtre nulle : l’émetteur envoie au moins un octet nouveau s’il en possède, ou retransmet, malgré une fenêtre nulle. Le récepteur répond avec le prochain numéro attendu et sa fenêtre actuelle.

La sonde ne donne pas le droit d’écouler la file. Elle pose une question exceptionnelle à laquelle le récepteur doit répondre. Une réponse nulle confirme la pause ; une réponse positive remplace la notification de réouverture perdue.

La première sonde devrait arriver après un délai de retransmission. Les suivantes devraient employer un recul exponentiel. Ce rythme réduit le temps perdu après un ACK isolé tout en évitant de harceler une application réellement suspendue. Aucune durée maximale universelle ne peut exprimer toutes les attentes légitimes.

Un zéro confirmé et un silence ne disaient pas la même chose

RFC 1122 autorise le récepteur à conserver indéfiniment une fenêtre offerte nulle. Tant qu’il accuse réception des sondes, le TCP émetteur doit laisser la connexion ouverte.

Une réponse prouve seulement qu’un TCP distant et un chemin de retour ont produit un rapport actuel. Elle ne prouve pas que le programme avance ni que le coût local reste raisonnable. Mais elle vaut davantage qu’une absence : le pair se manifeste et maintient son interdiction. Confondre les deux observations détruirait l’information acquise par la sonde.

Persister ne signifiait pas céder ses buffers

La formulation « indéfiniment » fut parfois interprétée comme l’interdiction de récupérer des ressources. RFC 6429 clarifia la frontière. Le transport ne doit pas fermer de sa propre initiative uniquement à cause du persist ; une application ou un système d’exploitation peut néanmoins demander l’abandon, et TCP doit obéir.

La menace inverse est concrète. Des clients peuvent demander de grandes réponses, cesser de les lire, annoncer zéro et confirmer chaque sonde. Le serveur conserve alors données en attente et blocs de connexion jusqu’à épuiser mémoire et capacité pour les utilisateurs légitimes.

Un délai caché et identique pour tous ne sait pas distinguer l’imprimante fidèle du client hostile. Le service qui connaît le contrat, le locataire, la taille de file et la date limite doit décider. TCP protège la cohérence commune ; la politique locale protège les ressources locales.

Rouvrir par miettes pouvait aussi immobiliser le système

RFC 813 décrivit le Silly Window Syndrome : de petits mouvements réguliers de fenêtre entraînent de petits segments, davantage d’ACK, du travail CPU et des retransmissions. Ses chiffres de terrain montrent la gravité possible, non une mesure universelle.

Le récepteur peut retenir une faible augmentation jusqu’à disposer d’un espace utile. L’émetteur peut refuser d’exploiter chaque minuscule avancée. RFC 9293 exige ces deux disciplines et distingue leur rôle de l’algorithme de Nagle, qui traite les petites écritures applicatives.

Les règles se complètent. Il faut éviter d’annoncer chaque octet libéré, mais garantir qu’une réouverture significative ne disparaîtra pas. La performance vient autant de la taille de l’autorisation que de sa livraison fiable.

La division durable des pouvoirs

De RFC 793 à RFC 9293, le résultat historique n’est pas un chiffre de minuterie. Le récepteur contrôle sa capacité présente. Le TCP émetteur maintient un moyen parcimonieux de découvrir sa réouverture. L’application et le système décident du temps et de la mémoire qu’ils sont prêts à engager.

TCP apprit ainsi à persister à zéro sans promettre une attente gratuite. Rendre une permission récupérable ne transforme pas celui qui la délivre en propriétaire des ressources de l’autre extrémité.

Sources et limites

Le dossier fermé comprend RFC 793, RFC 813, RFC 1122, RFC 6429 et RFC 9293. Il n’établit ni les temporisations de chaque système actuel, ni la fréquence des attaques, ni l’état d’une application particulière.