Résumé

  • Après un premier segment ordonné, le récepteur peut retenir brièvement son ACK afin de confirmer deux segments à la fois ou de joindre la confirmation à une réponse.
  • Le deuxième segment, l’expiration du minuteur et les indices de perte mettent fin à l’attente ; l’absence d’ACK n’est jamais laissée sans borne.

Le point décisif est souvent invisible dans une capture courte : les octets sont déjà acceptés et RCV.NXT a avancé. Seule leur confirmation reste en attente. Si un deuxième segment complet arrive, un ACK cumulatif couvre les deux ; sinon, le minuteur libère le premier. Le protocole retarde donc la publication d’un fait, non le fait lui-même.

RFC 1122 a codifié ce choix en 1989. Il recommande l’ACK différé pour économiser du travail aux hôtes et du trafic au réseau, tout en imposant un délai inférieur à 0,5 seconde et en recommandant au moins un ACK tous les deux segments complets. Son exemple de terminal interactif montre un autre bénéfice : ACK, mise à jour de fenêtre et caractère renvoyé peuvent partager un seul segment.

RFC 5681 précise la frontière. La cadence « un sur deux » est un SHOULD, tandis que l’attente du deuxième segment ne doit jamais dépasser 500 ms. Compter seulement 2*RMSS peut toutefois produire un stretch ACK lorsque le chemin oblige l’émetteur à utiliser des segments plus petits que le MSS annoncé. Confirmer au moins un segment sur deux, quelle que soit sa taille, évite ce décalage.

Une brèche dans l’espace de séquence change immédiatement la priorité. Un segment reçu au-delà d’un trou devrait déclencher un ACK dupliqué ; celui qui comble tout ou partie du trou devrait aussi être confirmé sans attendre. L’ACK devient alors une preuve nécessaire à la récupération, pas seulement un coût à regrouper.

RFC 2525 a inscrit le stretch ACK parmi les défauts d’implémentation connus. Espacer excessivement les ACK peut ralentir la progression de la fenêtre de congestion ou rendre les émissions plus groupées, car leur arrivée participe à l’horloge de contrôle de l’émetteur.