Résumé

  • Le temporisateur de retransmission indique quand réessayer ; le USER TIMEOUT indique quand abandonner la connexion.
  • RFC 5482 transporte une préférence du pair, mais les limites locales et le paramètre CHANGEABLE conservent la décision finale à l’hôte local.

Deux horloges, deux décisions

Lorsqu’un segment TCP reste sans acquittement utile, le temporisateur de retransmission peut expirer et provoquer l’envoi d’une nouvelle copie. Cette expiration relance le temporisateur ; elle ne signifie pas que l’application acceptera d’attendre indéfiniment.

Le USER TIMEOUT répond à une autre question : combien de temps des données transmises peuvent-elles rester sans livraison réussie ? RFC 793 définissait déjà cette limite locale. RFC 9293 distingue explicitement les événements. L’expiration du temporisateur de retransmission renvoie le premier segment en attente et réinitialise le temporisateur. L’expiration du USER TIMEOUT vide les files, signale l’abandon, supprime le TCB et fait passer la connexion à CLOSED.

Les deux horloges peuvent donc diverger. Une nouvelle retransmission peut encore être possible alors que la politique de persistance a atteint sa limite. Le RTO adapte le rythme des essais aux observations de délai et de perte ; le USER TIMEOUT fixe la durée pendant laquelle l’état, la mémoire et l’incertitude applicative restent acceptables.

Ce paramètre ne remplace pas non plus un délai d’attente de requête applicative. Une application peut abandonner une opération tout en gardant la connexion, ou demander que la connexion elle-même disparaisse lorsque les données en attente ne peuvent plus être livrées.

Une préférence exprimée en secondes ou en minutes

À l’origine, le délai était local : un endpoint ne connaissait pas la durée pendant laquelle l’autre souhaitait conserver une connexion perturbée. RFC 5482 a défini l’option TCP User Timeout afin de rendre cette préférence visible.

L’option est de type 28 et comporte quatre octets. Un bit de granularité choisit les secondes ou les minutes ; les quinze bits restants codent l’intervalle suggéré. Elle peut ainsi exprimer des valeurs allant d’une seconde à plus de neuf heures, ou d’une minute à plus de vingt-deux jours.

Cette valeur conseille le pair ; elle ne lui commande pas d’abandonner. L’état abstrait comprend USER_TIMEOUT, ADV_UTO, ENABLED et CHANGEABLE. ENABLED est désactivé par défaut et contrôle l’envoi et le traitement de l’option. CHANGEABLE indique si une suggestion reçue peut modifier le délai local.

Si l’application a fixé un délai et que CHANGEABLE vaut faux, le pair ne peut pas le remplacer. TCP peut toutefois notifier l’application de la valeur reçue. L’information traverse la connexion, mais l’autorité ne change pas de côté.

Les bornes protègent les ressources

RFC 5482 impose des limites locales haute et basse. Une valeur trop courte peut interrompre une connexion simplement ralentie ou traversant un chemin dégradé. Une valeur trop longue conserve tampons et état, et peut faciliter l’épuisement des ressources. L’authentification et les limites par pair font partie des mesures envisageables.

L’absence de l’option ne permet pas de conclure que le pair n’a aucun USER TIMEOUT : une implémentation peut l’ignorer et l’espace d’options TCP peut être déjà occupé. De même, un pare-feu peut supprimer son état avant l’échéance des endpoints. Une capture montre une suggestion à un point donné, pas son adoption ni la durée de vie d’un équipement intermédiaire.

Si les keepalives sont actifs, leur temporisateur doit être supérieur au USER_TIMEOUT adopté. Ils ne répondent pas à la même question : les keepalives testent une connexion inactive, tandis que le USER TIMEOUT borne la persistance de données non livrées.

Le changement historique est donc mesuré : RFC 5482 expose une politique locale sous forme de préférence bornée. Il coordonne les attentes sans transformer le pair en détenteur de la décision d’abandon.

Sources