Résumé

  • La sonde de fenêtre nulle oblige le récepteur à répéter un changement d’état qui aurait pu se perdre dans un simple accusé de réception.
  • TCP préserve ainsi la possibilité de reprendre l’échange, tandis que le système et l’application gardent la décision de libérer les ressources ou d’abandonner.

Le piège tient dans un message qui ne transporte aucune donnée. Une application cesse de lire ; son tampon se remplit ; le TCP récepteur annonce une fenêtre de réception nulle. L’émetteur respecte cette limite et suspend l’envoi normal. Lorsque l’application recommence à consommer les données, le récepteur expédie un accusé de réception avec une fenêtre rouverte. Mais si ce paquet disparaît, aucune retransmission automatique de cet accusé de réception pur n’est garantie. Le récepteur pense avoir rendu du crédit. L’émetteur croit toujours que le crédit est nul.

Les deux côtés peuvent attendre sans que la connexion soit, au sens du protocole, rompue.

La réponse de TCP consiste à provoquer une nouvelle observation. Même quand la fenêtre annoncée vaut zéro, l’émetteur transmet ou retransmet périodiquement une petite quantité afin de susciter une réponse. Le récepteur doit alors renvoyer son prochain numéro de séquence attendu ainsi que la valeur actuelle de sa fenêtre. Si celle-ci s’est rouverte, l’information revient enfin à l’émetteur. Si elle reste fermée, l’émetteur reçoit au moins un état frais plutôt que de transformer le silence en certitude.

Cette logique figure dès RFC 793. La spécification de 1981 exigeait qu’un TCP émetteur retransmette régulièrement malgré une fenêtre nulle et qu’un récepteur dans cet état accuse réception d’un segment entrant en indiquant encore sa fenêtre. Le texte donnait à cette répétition une fonction précise : garantir que la réouverture soit signalée de manière fiable. La recommandation de temporisation appartenait à la première formulation ; l’idée durable était de rendre répétable une annonce de contrôle de flux qui, prise isolément, pouvait se perdre.

RFC 1122 a resserré la règle en 1989. La prise en charge des sondes de fenêtre nulle y devient obligatoire. Le document expose sans détour le scénario de blocage : les segments ACK sans données ne sont pas transmis de façon fiable par TCP ; sans sonde, la perte de celui qui agrandit la fenêtre peut suspendre la connexion pour toujours. Il recommande une première sonde après une période égale au délai de retransmission, puis un espacement exponentiellement croissant entre les sondes suivantes.

Le choix de cet ordre est révélateur. La première tentative évite de prolonger inutilement un blocage dû à un seul ACK perdu. L’espacement progressif empêche en même temps une pause longue de provoquer un flux soutenu de sollicitations. La sonde n’accorde aucun octet supplémentaire à l’émetteur et ne contourne pas le contrôle du récepteur. Elle demande seulement au récepteur de redire où en est ce contrôle.

RFC 1122 précise aussi qu’une fenêtre offerte peut rester fermée indéfiniment. Tant que le récepteur répond aux sondes, l’émetteur doit pouvoir maintenir la connexion, sous réserve de la politique de délai de l’application. L’exemple historique est celui d’un démon d’impression arrêté parce que l’imprimante manque de papier. Il serait prématuré pour TCP de conclure à une panne définitive : la cause se situe hors du transport et peut disparaître sans qu’une nouvelle connexion soit nécessaire.

Cette situation du côté émetteur a pris le nom de « persist condition ». RFC 6429 est revenu sur elle en 2011 pour lever une ambiguïté opérationnelle. Préserver une connexion valide ne signifie pas que le protocole exige de conserver sans limite toute mémoire associée. Un pair peut annoncer une fenêtre nulle, continuer à répondre aux sondes et immobiliser des données en file d’envoi. Multiplié sur un serveur chargé, ce comportement peut épuiser les ressources utiles aux connexions légitimes.

La clarification ne remplace pas le mode persist par une expiration universelle. Elle confirme que le système d’exploitation ou l’application peut fermer une connexion ou récupérer ses ressources selon sa propre politique. TCP assure la continuité de son état tant qu’on choisit de conserver la connexion ; il n’usurpe pas la décision économique ou applicative de continuer à attendre.

RFC 9293 conserve cette architecture dans la spécification TCP consolidée. La sonde de fenêtre nulle reste obligatoire. Le récepteur doit répondre en donnant le prochain numéro attendu et sa fenêtre courante. L’émetteur devrait lancer la première sonde après un délai de retransmission et allonger exponentiellement les intervalles suivants. La considération relative aux ressources demeure explicite : la patience du protocole s’exerce à l’intérieur des limites que le système responsable de ces ressources peut fixer.

Le mode persist ne détecte donc pas qu’une application est saine. Il ne prouve pas non plus l’identité du pair et ne promet pas une reprise. Il répare une asymétrie de connaissance : une transition de fenêtre que seul le récepteur connaît redevient observable par l’émetteur.