Résumé

  • Le délai utilisateur de TCP est une limite locale, propre à chaque connexion : lorsque des données émises restent trop longtemps sans accusé de réception, l’extrémité peut abandonner la connexion. Ce délai n’est pas le minuteur de retransmission.
  • La RFC 5482 a créé une option de quatre octets permettant d’annoncer la valeur courante. L’annonce reste un conseil : le correspondant peut l’ignorer, l’encadrer par ses propres limites ou empêcher qu’elle remplace une valeur choisie par l’application.
  • Attendre davantage peut sauver une connexion pendant une coupure, mais immobilise plus longtemps files et état. Attendre moins libère des ressources plus tôt, au risque de confondre retard provisoire et panne durable.

Deux horloges pour un octet sans réponse

Prenons une connexion établie dont un octet n’a pas été acquitté. Le minuteur de retransmission peut expirer, remettre un segment sur le réseau et repartir. Le délai utilisateur répond à une autre question : combien de temps le travail encore en attente mérite-t-il de garder toute la connexion ouverte ?

Dans la RFC 793, l’expiration de ce délai ne provoque pas une nouvelle tentative. TCP vide les files, signale l’abandon, supprime le bloc de contrôle et passe à l’état CLOSED. La RFC 9293 conserve aujourd’hui cette séparation : RETRANSMISSION TIMEOUT renvoie ; USER TIMEOUT met fin à l’état.

La politique existait donc avant l’option. L’interface abstraite de 1981 permettait déjà à l’application de fixer une durée à l’ouverture ou lors d’un envoi. La RFC 1122 a ensuite distingué R1, seuil d’alerte, et R2, seuil de fermeture. Une application doit pouvoir régler R2 pour une connexion particulière ; la recommandation d’au moins cent secondes pour les données n’en fait pas une valeur universelle.

Cette souplesse restait unilatérale. Un hôte mobile pouvait décider de patienter pendant un changement de réseau, tandis que son correspondant supprimait l’état plus tôt. Un serveur chargé pouvait vouloir raccourcir sa patience sans disposer d’un moyen TCP pour expliquer cette contrainte au client.

Quatre octets, sans poignée de main contractuelle

Publiée en 2009, la RFC 5482 attribue à l’option UTO le numéro 28 et une longueur de quatre octets. Un bit G choisit les secondes ou les minutes ; quinze bits transportent la valeur proposée. Zéro est réservé. Le champ exprime une durée, non un nombre de retransmissions ni une estimation du temps aller-retour.

Lorsque l’extension est activée avant l’ouverture, l’option peut apparaître dans SYN et SYN-ACK. Le premier paquet sans SYN devrait aussi la porter. Une mise en œuvre qui ne la connaît pas doit l’ignorer silencieusement. Si un segment contenant UTO se perd, le correspondant manque simplement l’occasion d’adapter sa politique : aucune poignée de main ne garantit la livraison.

Le point décisif tient en une phrase de la spécification : l’échange n’est pas une négociation contraignante. L’émetteur révèle ADV_UTO, la durée qu’il annonce. Le récepteur mémorise REMOTE_UTO, mais conserve USER_TIMEOUT comme décision locale. ENABLED active le mécanisme ; CHANGEABLE détermine si le conseil distant peut modifier cette décision.

Si l’application fixe elle-même USER_TIMEOUT, CHANGEABLE doit devenir faux. Un paquet reçu ne peut donc pas annuler discrètement un choix explicite de l’application. Lorsque l’adaptation est autorisée, la RFC recommande de prendre le maximum des valeurs annoncées, puis de l’enfermer entre une limite basse et une limite haute locales. Les deux extrémités peuvent néanmoins aboutir à des durées différentes et chacune reste libre de fermer.

La survie consomme de l’état

Une durée longue peut traverser une interruption de mobilité, une instabilité de routage ou une période sans connectivité. Mais elle oblige l’hôte à conserver des files et un contexte de connexion. Des clients qui terminent la poignée de main puis proposent des durées très longues peuvent accroître l’exposition d’un serveur à l’épuisement de ressources.

La RFC 5482 exige donc des bornes. La limite basse doit dépasser le RTO courant, faute de quoi un retard ou une perte passagère peut faire fermer la connexion avant même qu’une retransmission ait eu une chance raisonnable d’aboutir. La limite haute peut varier selon l’authentification, le nombre de connexions du pair, la charge ou une situation d’attaque.

Les keep-alives n’accomplissent pas la même tâche. Si les deux fonctions sont actives, leur minuteur doit être supérieur au délai utilisateur adopté, sinon une politique d’abandon propre au keep-alive peut fermer la connexion en premier. Un pare-feu avec état peut lui aussi oublier le flux selon son propre calendrier. UTO ne prouve donc ni la disponibilité du chemin, ni la réception du conseil, ni la persistance des intermédiaires.

L’espace d’options TCP apporte une dernière limite matérielle : quarante octets seulement. D’autres extensions peuvent ne laisser aucune place à UTO. L’absence de l’option n’est donc pas, à elle seule, un refus de patienter.

Ce que la RFC a réellement déplacé

La RFC 5482 n’a pas inventé la possibilité pour une application de choisir sa patience. Elle a rendu cette politique audible par le correspondant, tout en préservant l’autorité locale. C’est précisément ce qui la distingue de Window Scale, qui fixe l’interprétation d’un champ après la poignée de main, de PAWS, qui rejette une ancienne signification de l’espace de séquence, et de SACK, qui décrit des blocs déjà reçus.

Le paquet de RFC ne mesure pas le déploiement actuel, ne dresse pas la liste des systèmes d’exploitation compatibles et ne donne pas les valeurs par défaut des applications. Il établit une histoire plus nette : TCP a appris à communiquer une limite d’attente sans la transformer en obligation réciproque.

Sources