Résumé

  • TCP keepalive demande si un pair silencieux répond encore au niveau transport ; il ne prouve pas la santé de son application.
  • Le mécanisme resta facultatif, configurable et désactivé par défaut parce que le silence d’une connexion possède plusieurs causes possibles.
  • Une réponse manquante ne prouve pas la mort, et les mémoires intermédiaires, le user timeout et l’énergie interdisent un intervalle universel.

La fiabilité avait besoin d’un octet

Le RFC 793 donne à TCP des preuves précises lorsque des données circulent : numéro de séquence, acquittement, minuterie et retransmission. Mais une connexion inactive n’a ni nouvel octet à confirmer ni ancien octet non acquitté dont l’expiration révélerait le chemin.

Deux hôtes vivants et volontairement silencieux ressemblent alors à un hôte tombé, une route disparue ou un pare-feu ayant oublié son état. Ce n’est pas une défaillance de la livraison fiable ; aucune livraison n’est tentée, donc aucune preuve nouvelle n’existe.

Une question envoyée derrière la frontière

Le RFC 1122 fixa en 1989 le comportement de keepalive tout en rappelant qu’il n’était pas unanimement accepté. La sonde habituelle utilise SEG.SEQ = SND.NXT-1, le numéro précédant le prochain octet nouveau.

Le destinataire devrait considérer ce segment comme extérieur à sa frontière courante et répondre par un ACK indiquant ce qu’il attend encore. La sonde ne fait normalement avancer aucune donnée. Une variante à un octet « poubelle » subsiste uniquement pour des implémentations erronées.

L’ACK montre qu’un TCP et un chemin de retour ont répondu à cet instant. Il ne démontre ni l’activité du processus, ni la disponibilité d’une base de données, ni la validité d’une session métier.

Désactivé par défaut, parce que la conséquence ne l’était pas

La norme autorisa l’implémentation sans l’imposer. Si keepalive existe, l’application doit pouvoir l’activer connexion par connexion, et l’état initial reste désactivé. L’intervalle doit être configurable et valoir au moins deux heures par défaut.

Deux heures ne transforment pas un pair en mort à la seconde 7 200. Cette valeur empêche le transport d’inventer trop vite la politique de l’application. Une session interactive, un pool SQL, une adjacence de routage et un capteur endormi ne paient pas le même prix pour une fermeture erronée, une détection tardive ou un paquet supplémentaire.

Le RFC 9293 conserve ces frontières dans la spécification moderne. L’usage répandu n’a pas donné au noyau un mandat automatique sur la signification du silence.

L’ACK absent n’est pas une déposition

TCP ne garantit pas la retransmission indépendante d’un ACK sans données. La sonde peut se perdre ; sa réponse aussi. Une congestion passagère peut retarder les deux. Il est donc interdit de tuer la connexion après une seule absence.

Fermer est pourtant une action forte. L’application peut déclencher un basculement, libérer un verrou, recommencer une tâche ou déclarer un incident. Plusieurs sondes manquées rendent la panne plus probable, mais le seuil reste une décision locale : conserver l’incertitude coûte désormais plus cher que l’abandonner.

User timeout mesure une autre attente

Le user timeout concerne des données déjà envoyées qui restent sans acquittement. Le RFC 5482 permit de communiquer une préférence à ce sujet. Sa question porte sur la durée acceptable d’un travail en souffrance, non sur le droit d’interroger une connexion vide.

Certaines piles appliquaient à keepalive une politique d’abandon capable de détruire une connexion qui aurait survécu à une panne transitoire. RFC 5482 exige donc, lorsque les deux mécanismes sont combinés selon ce contrat, que la minuterie keepalive soit supérieure au user timeout adopté.

Une sonde, un octet en attente et une fermeture ne doivent pas être confondus dans une seule horloge.

Le NAT ajouta sa mémoire privée

Les extrémités ne furent plus les seules à mémoriser la connexion. Un NAT peut supprimer sa correspondance pendant que les deux TCP conservent un état parfaitement valide. Le prochain paquet rencontre alors un chemin qui a oublié le contrat.

Le RFC 5382 imposa à un NAT conforme, incapable de déterminer autrement l’activité, de ne pas expirer une connexion établie avant deux heures et quatre minutes. Les quatre minutes supplémentaires couvrent le trafic en vol autour de la sonde par défaut.

Cette règle borne l’intermédiaire ; elle ne prouve pas que tous les équipements la respectent. Raccourcir l’intervalle pour garder une table NAT vivante signifie que les extrémités paient en trafic pour empêcher une boîte privée de les oublier.

La batterie révéla la facture opposée

Sur un objet contraint, une sonde peut réveiller la radio et prolonger une période coûteuse. Le RFC 9006 expose le conflit : deux heures peuvent être trop longues pour certains middleboxes ; des messages plus fréquents épuisent l’énergie.

Il n’existe donc pas de constante neutre. L’application connaît la valeur d’une reconnexion, l’opérateur la durée des états du chemin, le terminal son budget électrique. Parfois, la meilleure connexion persistante est celle que l’on accepte de reconstruire.

Un cœur qui ne sait pas si le service pense

Le mot heartbeat promet trop. Le noyau distant peut acquitter alors que le processus est bloqué. Un proxy peut répondre tandis que l’amont est indisponible. Une application saine peut aussi dormir exprès.

Un heartbeat applicatif pose une question plus riche et plus chère : le service peut-il traiter une requête et produire une réponse correcte ? Il ne faut pas empiler les deux mécanismes sans attribuer à chacun une panne précise.

Keepalive n’est pas non plus une sonde de fenêtre zéro. Cette dernière protège la réouverture d’une capacité explicitement fermée ; keepalive interroge une connexion autrement inactive. Des paquets voisins peuvent porter des autorités différentes.

Le silence conserva la présomption d’innocence

Le choix historique essentiel fut de ne pas faire du silence une culpabilité automatique. Un ACK prouve une réponse TCP récente, pas une application saine. Son absence produit de l’incertitude, pas un décès.

L’application qui supporte la perte conserve donc la décision. TCP offre la question ; il n’acquiert pas le pouvoir d’expliquer pourquoi aucune réponse n’est venue.

Sources et limites

RFC 793, RFC 1122, RFC 5382, RFC 5482, RFC 9006 et RFC 9293 établissent les contrats successifs. Ils ne démontrent ni les défauts de chaque système ni la santé d’un service réel.