Résumé

  • L’ACK cumulatif garantit une suite complète d’octets. Si le premier segment manque, son numéro reste immobile même lorsque le récepteur conserve tout ce qui suit.
  • SACK ajoute, après négociation, les bornes des blocs reçus hors ordre. Le champ d’acquittement ordinaire ne change pas et l’émetteur reste maître des retransmissions.
  • Le signal est partiel et révocable. L’émetteur garde ses données jusqu’à l’ACK cumulatif, respecte la fenêtre de congestion et sait revenir au mécanisme de base.

Ce que le nombre 5000 ne pouvait pas dire

Un récepteur attend l’octet 5000. Le premier segment se perd ; les sept suivants arrivent et forment pourtant une plage continue de 5500 à 9000. L’ACK ordinaire répond toujours 5000. Il dit exactement : « je ne peux pas encore certifier un flux sans trou jusqu’à 9000 ».

Cette prudence protège la sémantique du flux, mais elle informe mal l’émetteur. Sept ACK identiques ne révèlent pas si un seul segment ou tout le reste a disparu. Retransmettre tout le vol gaspille la liaison ; découvrir chaque manque après un nouveau aller-retour pénalise surtout les chemins longs.

La RFC 793 avait choisi un engagement simple. Chaque octet porte un numéro, et l’acquittement X couvre tout ce qui précède X. Le destinataire peut recevoir des octets plus élevés, mais il ne déplace pas le bord gauche tant que la lacune subsiste. Cette règle reste la preuve qui autorise finalement l’émetteur à libérer sa copie.

Une bonne idée restée sans déploiement commun

La RFC 1072 proposa dès 1988 deux options. SACK-Permitted, placée dans le SYN, annonçait la capacité. Après l’ouverture, une option SACK pouvait décrire des blocs non contigus reçus et mis en attente. Le champ cumulatif conservait son sens.

Ce premier format ne devint pas un usage Internet commun. La RFC 2018 mentionne un désaccord sur sa combinaison avec l’extension de fenêtre. L’épisode rappelle qu’un texte publié n’est pas un déploiement : il faut encore des implémentations compatibles, des essais et une raison opérationnelle d’activer l’option.

En 1996, la nouvelle spécification reprit la négociation dans le SYN mais simplifia le rapport. Chaque bloc porte deux numéros de séquence complets sur 32 bits : le premier octet reçu et le numéro qui suit immédiatement le dernier. Dans notre exemple, l’ACK reste à 5000 et SACK peut annoncer [5500, 9000). L’un garantit la continuité ; l’autre montre l’île au-delà du trou.

Une carte volontairement incomplète

L’espace d’options TCP ne dépasse pas 40 octets. Deux octets décrivent le type et la longueur de SACK, puis chaque bloc en consomme huit. Quatre blocs tiennent sans autre option ; avec les horodatages, il n’en reste généralement que trois. Une file très fragmentée ne rentre donc jamais entièrement dans un seul paquet.

Le récepteur commence par le bloc modifié par le segment le plus récent, puis répète des blocs déjà signalés. Cette redondance compense la perte possible des ACK sur le chemin retour. L’émetteur assemble au fil du temps un tableau plus riche que n’importe quel message isolé.

Le protocole partage ainsi le minimum utile. Il ne publie ni la mémoire complète du récepteur, ni son algorithme de file, ni un journal éternel. Deux bornes suffisent pour que des implémentations différentes parlent d’un même intervalle d’octets.

Un avis n’est pas une quittance

La RFC 2018 qualifie SACK d’indicatif. Le récepteur peut abandonner plus tard des données qu’il avait déclarées présentes : c’est le reneging. L’émetteur peut éviter ces plages pendant une récupération ordinaire, mais il ne doit pas supprimer sa copie avant que l’ACK cumulatif ne les couvre.

Après expiration du temporisateur, il doit envisager que l’information sélective ne soit plus valable et repartir du bord gauche. Ce repli conservateur distingue l’observation révisable de l’engagement final. Une indication améliore le choix ; elle n’efface pas la responsabilité de pouvoir recommencer.

L’émetteur tient donc la file de retransmission. Il fusionne les blocs, repère les trous probables et choisit le prochain segment autorisé. La RFC 6675 formalisera plus tard un « tableau de score » côté émetteur, une estimation des octets encore dans le réseau et un algorithme de récupération prudent.

Voir la perte ne crée pas de bande passante

SACK ne remplace pas la maîtrise de congestion. La RFC 2018 impose de préserver les règles existantes : un seul ACK hors ordre ne suffit pas à déclencher une réparation, l’émetteur limite ce qu’il envoie pendant la récupération et réduit sa fenêtre lorsque les signaux de congestion l’exigent.

La différence avec l’histoire de l’effondrement de 1986 est nette. La fenêtre de congestion décide du volume admissible. SACK aide à choisir quels octets méritent ce volume. Une carte plus exacte du dommage n’agrandit pas la capacité partagée.

D-SACK ajouta en 2000 la possibilité de signaler un doublon. L’émetteur peut alors soupçonner un réordonnancement, un ACK perdu, une réplication ou un temporisateur trop précoce. La RFC 2883 ne dicte pourtant pas une réaction unique et note que le destinataire n’est pas nécessairement digne de confiance. Elle transmet un fait allégué, pas un ordre.

Sources et limites de la preuve

La base cumulative vient de la RFC 793. La première proposition est la RFC 1072, puis la RFC 2018 fixe le format révisé. La RFC 2883 définit D-SACK, la RFC 5681 borne la congestion, la RFC 6247 documente le statut historique de l’ancien texte et la RFC 6675 décrit une récupération conservatrice.

Ces sources prouvent les mécanismes et leur filiation, non une date mondiale d’activation ni un gain identique sur tous les chemins. Un bloc SACK ne localise pas la panne, n’en prouve pas la cause et n’authentifie pas celui qui le produit.