La couche transport : UDP et TCP

Une application envoie des données par une socket, l’interface entre son processus et la couche transport. La couche transport donne l’impression que des processus situés sur des hôtes différents communiquent directement. C’est une communication logique : les données traversent toujours des liaisons et des routeurs, mais l’application utilise sa socket locale.

Suivre les données à travers les couches

Chez l’émetteur, le protocole de transport prend les données applicatives, les découpe au besoin en blocs et ajoute un en-tête de transport. Le segment obtenu est transmis à IP. IP ajoute son propre en-tête et produit un datagramme IP que le réseau transporte. À destination, IP remet le segment au protocole de transport, qui interprète l’en-tête de transport et livre les données à une socket.

La logique du protocole s’exécute dans les hôtes terminaux. Les routeurs ordinaires transfèrent les datagrammes IP ; ils n’effectuent pas les acquittements et les retransmissions TCP pour le compte des applications. Imagine une adresse IP comme l’adresse d’un immeuble et la socket de réception comme le destinataire à l’intérieur. Apporter une lettre à l’immeuble et la remettre à la bonne personne sont deux tâches distinctes.

IP offre un acheminement au mieux entre hôtes. Les datagrammes peuvent être perdus, dupliqués, désordonnés ou altérés. La couche transport étend l’acheminement aux processus et peut ajouter des mécanismes qui corrigent ces défaillances.

Comparer les services

UDP ajoute des ports et une vérification des erreurs à l’acheminement IP. Un segment peut arriver sans échange préalable d’établissement. UDP ne récupère pas un segment perdu et ne retient pas un segment ultérieur en attendant l’arrivée d’un segment précédent.

TCP établit un état de connexion avant le transfert normal des données. Il numérote les octets, vérifie les erreurs, obtient des acquittements et retransmet les données manquantes. L’application réceptrice obtient un flux d’octets fiable et ordonné. Le contrôle de flux protège son tampon ; le contrôle de congestion réagit à la charge du réseau.

La fiabilité ne rend pas le réseau sous-jacent fiable. Si un datagramme IP disparaît, TCP envoie une autre copie des données manquantes. Si des octets ultérieurs arrivent en premier, le récepteur peut les conserver jusqu’à ce que le manque soit comblé. L’application reçoit les données après correction, mais elle peut attendre plus longtemps. Ni TCP ni UDP ne peut promettre un délai de livraison ou réserver de la capacité réseau simplement en fonctionnant sur le service IP au mieux.

Choisir le service à la création de la socket

Une socket de flux sélectionne normalement TCP ; une socket de datagrammes sélectionne UDP. HTTP/1.1 et HTTP/2, le transfert de courriels par SMTP et la connexion à distance par SSH utilisent TCP. Les requêtes DNS ordinaires utilisent couramment UDP. HTTP/3 utilise QUIC sur UDP : QUIC fournit des flux fiables et la sécurité au-dessus du service minimal d’UDP.

Une connexion TCP seule ne garde pas un mot de passe secret. TLS ajoute le chiffrement et l’authentification au-dessus de TCP ; QUIC intègre TLS à sa conception. La fiabilité indique si les octets atteignent l’application correctement et dans l’ordre. La confidentialité indique si un observateur peut les lire.

Un hôte possède souvent de nombreuses sockets ouvertes. Le multiplexage recueille les données sortantes de ces sockets et ajoute des en-têtes de transport. Le démultiplexage sélectionne la socket de réception pour chaque segment reçu.

Lire les informations d’adressage

TCP et UDP transportent tous deux un port source de 16 bits et un port de destination de 16 bits. Les valeurs vont de 0 à 65 535. Le port de destination identifie le service récepteur ; le port source aide le correspondant à adresser sa réponse. L’IANA classe les ports en ports système de 0 à 1023, ports utilisateur de 1024 à 49151 et ports dynamiques de 49152 à 65535.

Les serveurs écoutent sur des ports convenus : SSH utilise le port 22, SMTP le 25, DNS le 53, HTTP le 80 et HTTPS généralement le 443. Les clients obtiennent généralement du système d’exploitation un port éphémère temporaire. Sa plage configurée ne correspond pas nécessairement à la plage dynamique de l’IANA : une plage courante par défaut sous Linux est 32768–60999, tandis que Windows utilise couramment 49152–65535.

À l’arrivée d’un datagramme IP, l’hôte identifie d’abord le protocole de transport. Dans IPv4, la valeur de protocole 6 signifie TCP et 17 signifie UDP ; IPv6 identifie le protocole de la couche supérieure au moyen de sa chaîne d’en-têtes suivants. Le port TCP 53 et le port UDP 53 appartiennent à des espaces de noms de transport différents. Le récepteur utilise ensuite les adresses et les ports pour sélectionner une socket et place les données en attente pour l’application.

UDP : plusieurs clients, une socket de réception

Dans le modèle de base d’un serveur UDP non connecté, la socket de réception est sélectionnée par l’adresse IP de destination et le port de destination. Différents clients peuvent tous envoyer des données à cette même socket.

Un serveur à l’adresse 203.0.113.53 écoute sur le port UDP 53. Les requêtes de 198.51.100.7:51000 et de 192.0.2.44:62011 atteignent cette seule socket serveur. La première réponse va de 203.0.113.53:53 à 198.51.100.7:51000. L’application obtient l’adresse et le port source de chaque requête afin de pouvoir répondre au bon client. Une socket UDP connectée peut aussi restreindre le correspondant dont elle reçoit les données ; aucune négociation UDP n’est ajoutée.

TCP : distinguer les connexions par quatre valeurs

Un serveur TCP possède une socket d’écoute et des sockets de connexion distinctes. Une connexion est identifiée par le quadruplet composé de l’adresse IP source, du port source, de l’adresse IP de destination et du port de destination.

Pour un serveur à l’adresse 203.0.113.10:80, voici des connexions distinctes :

• 198.51.100.7:50312 → 203.0.113.10:80
• 198.51.100.7:50313 → 203.0.113.10:80
• 192.0.2.44:50312 → 203.0.113.10:80

Les deux premières diffèrent par leur port source. La première et la troisième partagent un port source, mais diffèrent par leur adresse source. Les trois utilisent le port serveur 80. Un port serveur distinct par client est inutile, car le quadruplet complet distingue leurs sockets de connexion. Un même processus peut gérer de nombreuses sockets de ce type.

Lorsqu’aucune socket ne correspond

Un SYN envoyé à un port TCP fermé reçoit normalement une réinitialisation, avec le drapeau RST activé. Un segment UDP envoyé à un port sans récepteur déclenche normalement un message ICMP « port inaccessible ». Les pare-feu, le filtrage et les limites appliquées aux réponses peuvent modifier ce qui revient. Lors du sondage d’un port, SYN-ACK indique qu’un service TCP est à l’écoute ; RST indique un refus. Le silence seul ne permet pas de distinguer un filtrage d’une perte ou d’un hôte indisponible.

UDP envoie chaque message indépendamment, sans négociation ni état partagé de numéros de séquence pour une connexion. Son en-tête fixe de 8 octets contient quatre champs de 16 bits chacun : port source, port de destination, longueur et somme de contrôle.

Compter les bons octets

La longueur couvre l’en-tête UDP et ses données. Elle vaut au moins 8 octets. Un message contenant 40 octets de données a une longueur UDP de 48. Avec un en-tête IPv4 de 20 octets et sans options IP, le datagramme IP complet fait 68 octets. L’en-tête IP n’est pas compris dans la longueur UDP.

La somme de contrôle détecte certaines erreurs de bits dans l’en-tête UDP et les données. Elle couvre aussi un pseudo-en-tête construit à partir des informations d’adressage IP, du numéro de protocole et de la longueur UDP. Ces valeurs aident à détecter un segment acheminé avec des informations d’adressage incorrectes. Le pseudo-en-tête sert au calcul ; il n’est pas une partie supplémentaire transmise dans l’en-tête UDP.

Additionner avec report circulaire de retenue

Considère les données du calcul comme des mots de 16 bits. Mets le champ de somme de contrôle à zéro pendant le calcul. Additionne les mots en reportant toute retenue au-delà du bit 16 vers les bits de poids faible. C’est l’addition en complément à un. Inverse enfin les 16 bits de la somme obtenue après report pour obtenir la somme de contrôle. Si le nombre d’octets est impair, ajoute un octet nul pour le calcul uniquement.

Pour trois mots servant d’exemple, utilise l’hexadécimal afin de rendre la retenue visible :

1. Additionne A35C et 69C3 pour obtenir 10D1F. Le 1 initial est une retenue hors des 16 bits.
2. Effectue le report : 0D1F + 1 = 0D20.
3. Ajoute 1234 : 0D20 + 1234 = 1F54.
4. Complémente chaque bit : FFFF − 1F54 = E0AB.

La somme de contrôle est E0AB. Supprimer simplement la retenue initiale donnerait une somme incorrecte. En binaire, la somme finale est 0001 1111 0101 0100 et son complément est 1110 0000 1010 1011.

Vérifier chez le récepteur

Le récepteur répète l’addition avec report sur le pseudo-en-tête et le segment reçu, en incluant cette fois le champ de somme de contrôle. Un segment inchangé donne une suite de uns, FFFF. Ici, 1F54 + E0AB = FFFF. Un résultat contenant un bit nul révèle une erreur. UDP rejette silencieusement un segment dont la somme de contrôle fournie, non nulle, échoue à la vérification ; il n’envoie pas de remplacement et ne répare pas les données.

Une suite de uns signifie que la vérification a réussi, sans exclure toutes les erreurs possibles. Des changements qui se compensent dans différents mots peuvent laisser la somme inchangée. La somme de contrôle détecte les erreurs ; elle ne localise ni ne corrige les bits erronés.

Pourquoi les hôtes terminaux vérifient à nouveau

Une vérification de liaison protège une liaison particulière. Certaines liaisons peuvent en être dépourvues et des altérations peuvent aussi se produire dans les équipements entre les liaisons. Une vérification de bout en bout teste ce qui est arrivé à l’hôte de destination. Cela illustre le principe de bout en bout : une propriété nécessaire sur tout le chemin doit être vérifiée à ses extrémités.

Sur IPv4, un champ de somme de contrôle UDP nul signale que l’émetteur a omis la somme de contrôle. Une somme calculée égale à zéro est transmise sous forme d’une suite de uns pour préserver cette distinction. IPv6 exige normalement une somme de contrôle UDP, avec des exceptions précisément définies pour certains tunnels. TCP utilise aussi une somme de contrôle Internet avec un pseudo-en-tête et exige cette somme.

Le service minimal d’UDP permet à une application de maîtriser ses messages. Il n’y a pas de négociation de transport avant le premier message, pas de file de retransmission UDP et pas de mécanisme UDP qui retienne des données ultérieures derrière un message précédent manquant. L’application décide quoi envoyer et quelles pertes comptent.

Adapter la récupération à l’instant où les données restent utiles

Considère des données audio vocales envoyées par blocs de 20 ms : 50 messages par seconde. Un bloc manquant doit être lu dans 60 ms, mais la détection de la perte et l’obtention d’une autre copie prennent environ 150 ms. Le bloc récupéré arriverait trop tard. Une application vocale peut lire les blocs suivants à temps et masquer le son manquant, par exemple en lissant le passage.

La quantité décisive est le temps restant avant la lecture, et non la durée de 20 ms d’un bloc. Si la récupération peut se terminer avant l’échéance, une retransmission peut être utile. TCP doit livrer les octets dans l’ordre : un octet antérieur manquant peut donc aussi retarder la livraison d’octets ultérieurs déjà reçus. Cette attente est souvent appelée blocage en tête de file au sein du flux.

Un transfert de fichier a une autre priorité : chaque octet doit arriver correctement et l’attente nécessaire à la récupération est acceptable. TCP fournit déjà ce service. Avec UDP, la détection des pertes, la demande de données de remplacement et leur remise dans l’ordre incomberaient à l’application ou à un autre protocole.

Les avantages d’un petit en-tête

L’en-tête UDP fait 8 octets ; celui de TCP en fait au moins 20. Un serveur UDP peut recevoir des messages de nombreux clients sans établir de connexion de transport pour chacun. Il existe néanmoins des tampons de socket et des ressources applicatives : « sans connexion » ne signifie donc pas que l’hôte ne stocke rien.

Les usages courants d’UDP comprennent les requêtes DNS ordinaires sur le port 53, la synchronisation horaire NTP sur le port 123, la gestion SNMP sur le port 161 et l’attribution d’adresses DHCP sur les ports 67 et 68. Les appels et les jeux choisissent souvent UDP pour recevoir les messages à temps. La vidéo à la demande utilise couramment HTTP sur TCP ou QUIC : la règle « la vidéo utilise UDP » est donc trop générale.

QUIC montre tout ce qu’un protocole peut ajouter au-dessus d’UDP : des flux fiables, un contrôle de congestion et la sécurité TLS 1.3. Il a été normalisé en 2021 et utilise couramment le port UDP 443 ; HTTP/3 fonctionne sur QUIC. UDP lui-même n’a pas acquis ces services.

Garder des messages assez petits

UDP préserve les limites des messages. Une opération de réception lit un message, et non un flux d’octets assemblé à partir de plusieurs envois. L’application doit fournir un tampon de lecture assez grand ; un tampon plus petit peut tronquer le message.

Pour IPv4 avec un en-tête IP de 20 octets, la charge utile maximale théorique est de 65 535 − 20 − 8 = 65 507 octets. Un envoi proche de cette limite peut nécessiter une fragmentation IP. Sur un chemin acceptant des datagrammes IPv4 de 1 500 octets, 1 500 − 20 − 8 = 1 472 octets de données tiennent sans fragmentation en l’absence d’options IP. D’autres chemins et en-têtes peuvent réduire cette valeur.

Tenir compte des contrôles absents

UDP n’a pas de contrôle de flux intégré pour protéger un récepteur lent. Si son tampon de socket se remplit, les messages qui arrivent peuvent être rejetés. Il n’a pas non plus de contrôle de congestion intégré. Les applications UDP responsables assurent un contrôle de débit adapté afin de ne pas surcharger un chemin partagé. Certains réseaux filtrent UDP : les applications peuvent donc avoir besoin d’une solution de repli.

Éviter l’établissement et la récupération peut réduire le délai, mais UDP n’augmente pas la capacité d’une liaison et n’empêche pas les pertes IP. Évalue le protocole applicatif dans son ensemble : les mécanismes qu’il ajoute au-dessus d’UDP peuvent compter davantage que la taille de l’en-tête.

Un protocole de transfert fiable de données fournit à l’application réceptrice des données correctes, dans l’ordre et sans doublons, même lorsque le canal sous-jacent altère des paquets. Construis le protocole en te demandant ce qui peut mal se passer à chaque étape. Dans ces protocoles, les données applicatives circulent dans un sens et les retours de contrôle dans l’autre.

Décrire le comportement avec des états

Un automate à états finis mémorise l’état actuel de l’émetteur ou du récepteur. Chaque transition comporte un événement déclencheur et les actions à effectuer. Un état tel que « attente de ACK 0 » indique ce que l’émetteur doit recevoir avant de poursuivre. Dans la notation des automates, Λ indique l’absence d’événement ou d’action ; une flèche entrante en pointillés indique l’état initial.

Avec un canal parfaitement fiable, la version 1.0 n’a besoin que de l’envoi et de la livraison. L’émetteur met les données en paquet, le récepteur les extrait et aucun des deux n’a besoin de retour. L’ajout d’erreurs de bits modifie la conception.

Détecter une erreur et demander une autre copie

La version 2.0 utilise trois mécanismes :

• Une somme de contrôle permet au récepteur de vérifier si un paquet est altéré.
• Un ACK signale une réception correcte ; un NAK signale des données altérées.
• La retransmission envoie une autre copie si nécessaire.

Ensemble, ces mécanismes forment la retransmission automatique sur demande (ARQ). L’émetteur envoie un paquet et attend un retour avant d’envoyer le suivant : c’est le protocole arrêt et attente. Il conserve une copie du paquet en cours, car il peut devoir le renvoyer.

Mais les paquets de retour traversent le même canal non fiable. Un ACK altéré laisse l’émetteur dans l’incertitude : le récepteur a-t-il accepté les données ou faut-il une autre copie ? Le renvoi n’est sûr que si le récepteur peut distinguer une copie de remplacement de nouvelles données applicatives. Une somme de contrôle seule n’identifie pas les doublons ; deux copies valides ont le même contenu valide.

Donner une identité à chaque paquet en attente d’acquittement

La version 2.1 ajoute un numéro de séquence. Avec un seul paquet en attente d’acquittement, un numéro de un bit alternant entre 0, 1, 0, 1 suffit dans ce modèle de canal avec arrêt et attente. Le récepteur mémorise le numéro qu’il attend. Il livre une fois un paquet valide portant ce numéro, puis change le numéro attendu. Un paquet portant le numéro précédent est un doublon : acquitte-le à nouveau, mais ne livre pas ses données une seconde fois.

L’émetteur conserve le numéro en cours pendant les retransmissions. Il ne passe à l’autre numéro qu’après réception de l’ACK correspondant et lisible. Dans cette conception qui ne traite que les erreurs, un retour altéré ou un NAK provoque une retransmission.

Remplacer les NAK par des ACK répétés

La version 2.2 supprime les NAK. Le récepteur répond à un paquet altéré ou dupliqué par un ACK pour le dernier paquet qu’il a accepté. L’ACK doit donc porter un numéro.

Supposons que le paquet 0 contienne « A » et arrive correctement. Le récepteur livre « A » et envoie ACK 0. Le paquet 1 contenant « B » est altéré : le récepteur répète donc ACK 0. L’émetteur attend ACK 1 ; cet acquittement dupliqué lui indique qu’il doit renvoyer le paquet 1. La copie de remplacement valide est livrée sous la forme « B » et acquittée par ACK 1.

Rejeter les données dupliquées et acquitter à nouveau le paquet dupliqué sont deux actions distinctes. Si le récepteur ignorait silencieusement une copie de remplacement dont l’ACK précédent était illisible, l’émetteur ne pourrait jamais savoir que la livraison a réussi. TCP évite lui aussi les NAK, même si sa numérotation des octets et ses règles de retransmission rapide diffèrent de celles de ce protocole simple.

Un retour ne sert à rien s’il n’arrive jamais. Lorsque le canal peut perdre un paquet de données ou un ACK, l’émetteur a besoin d’un moyen de reprendre sans recevoir de message. La version 3.0 ajoute un temporisateur à rebours au protocole du bit alterné.

Gérer l’absence de réponse sans livrer deux fois

L’émetteur démarre le temporisateur chaque fois qu’il envoie le paquet en cours, y compris une copie de remplacement. Un ACK correspondant et intact arrête le temporisateur et autorise l’envoi du paquet suivant. Un ACK altéré ou portant le mauvais numéro est ignoré. Si le temporisateur expire avant, l’émetteur renvoie le même paquet et le redémarre.

Si un paquet de données est perdu, le récepteur n’a rien à acquitter ; l’expiration du délai déclenche l’envoi d’une copie de remplacement. Si un ACK est perdu, le récepteur a déjà livré les données. À l’arrivée de la copie de remplacement, le numéro de séquence permet de reconnaître un doublon. Le récepteur rejette ses données et renvoie l’ACK.

Une expiration prématurée du délai d’attente se produit lorsque le paquet initial ou l’ACK était simplement lent. La copie de remplacement gaspille une transmission, mais la détection des doublons préserve une livraison correcte. Un délai utile doit tenir compte du temps aller-retour attendu et du traitement par le récepteur. Trop court, il provoque des retransmissions inutiles ; trop long, il retarde la récupération après une perte réelle.

Distinguer le temps de transmission du temps d’attente

Soit une longueur de paquet de $L$ bits et un débit de liaison de $R$ bit/s. L’émetteur a besoin de $L\mathrm{/}R$ secondes pour placer un paquet sur la liaison. En négligeant le temps de transmission et de traitement de l’ACK, un cycle d’arrêt et attente dure $RTT+L\mathrm{/}R$. La proportion du temps consacrée à l’envoi est

Pour des paquets de 1 500 octets sur une liaison à 1 Gbit/s, convertis d’abord les octets en bits :

Alors $L\mathrm{/}R=12\mu \text{s}=\mathrm{0,012}\text{ ms}$. Avec un temps aller-retour de 40 ms,

L’émetteur est actif environ 0,03 % du temps. Le débit effectif est d’environ 12 000 bits toutes les 0,040012 s, soit 300 kbit/s. Une liaison très rapide transporte malgré tout peu de trafic utile, car l’émetteur passe presque tout le cycle à attendre.

Transmettre les paquets en pipeline

La transmission en pipeline permet d’avoir plusieurs paquets non acquittés en vol. Si la fenêtre d’émission peut contenir jusqu’à $N$ paquets, le taux d’utilisation idéal devient

Sur la même liaison, 1 000 paquets donnent un taux d’utilisation d’environ 0,30. Pour l’occuper pleinement, il faut au moins $\mathrm{40,012}\mathrm{/}\mathrm{0,012}\approx 3\mathrm{334,33}$ temps de transmission de paquet ; arrondis donc à 3 335 paquets. Un arrondi à l’entier inférieur laisserait un court intervalle d’inactivité avant le premier ACK.

Un pipeline plus grand nécessite assez de numéros de séquence pour distinguer ses paquets et assez d’espace tampon pour conserver les données non acquittées. Selon le protocole, le récepteur peut aussi avoir besoin d’un tampon. Go-Back-N et la répétition sélective résolvent ces questions de conception différemment.

Augmenter uniquement le débit de la liaison raccourcit le temps de transmission, déjà bref. À taille de paquet et temps aller-retour fixes, cela réduit le taux d’utilisation du protocole arrêt et attente. Une quantité plus grande de données en vol permet à l’émetteur d’utiliser la capacité disponible.

Go-Back-N (GBN) autorise jusqu’à $N$ paquets envoyés mais non acquittés. La fenêtre glissante de l’émetteur avance lorsque les acquittements confirment la livraison. Le récepteur reste simple : il n’accepte que le prochain paquet dans l’ordre.

Distinguer les plages de l’émetteur

La variable base identifie le plus ancien paquet non acquitté. nextseqnum identifie le prochain nouveau paquet à envoyer. Avant le rebouclage des numéros de séquence, les plages sont :

• Avant base : déjà acquittés.
• De base à nextseqnum − 1 : envoyés, en attente d’acquittement.
• De nextseqnum à base + N − 1 : disponibles pour de nouvelles données.
• À partir de base + N : bloqués jusqu’à l’avancement de la fenêtre.

Pour base = 10, nextseqnum = 13 et $N=5$, les paquets 10 à 12 sont en attente d’acquittement. Les paquets 13 et 14 peuvent être envoyés. Le paquet 15 ne le peut pas. Une fenêtre limite les données en attente d’acquittement, et non le nombre total de paquets d’un transfert.

Les acquittements cumulatifs font avancer la base

L’ACK GBN $n$ confirme tous les paquets jusqu’à $n$ inclus. Il fait passer base à $n+1$. Un acquittement cumulatif ultérieur peut donc couvrir des ACK antérieurs perdus. Cette convention de numérotation identifie le dernier paquet accepté ; la convention d’acquittement de TCP identifie le prochain octet attendu.

GBN conserve un seul temporisateur pour le plus ancien paquet en attente d’acquittement. L’envoi du premier paquet en attente le démarre. Un ACK qui fait avancer la base le redémarre si des données restent en attente ; l’acquittement de toutes les données l’arrête. Lorsque le temporisateur expire, l’émetteur retransmet chaque paquet envoyé mais toujours non acquitté. Ce nombre peut être inférieur à la fenêtre maximale $N$.

Suivre un paquet manquant

Utilise une fenêtre de quatre et envoie les paquets 0, 1, 2 et 3. Le paquet 2 est perdu. Le récepteur livre 0 et 1 et envoie ACK 0 et ACK 1. Le paquet 3 arrive au-delà du manque : le récepteur le rejette et répète ACK 1.

Les deux premiers ACK libèrent de la place pour les paquets 4 et 5. Ils arrivent eux aussi au-delà du paquet 2 manquant ; ils sont donc tous deux rejetés et reçoivent ACK 1 en réponse. La base de l’émetteur reste à 2. À l’expiration du délai, il retransmet 2, 3, 4 et 5. Ils arrivent cette fois dans l’ordre et peuvent tous être livrés.

Les copies de 3, 4 et 5 étaient intactes la première fois. GBN les renvoie parce que son récepteur a choisi de ne pas mettre en mémoire tampon les paquets reçus dans le désordre. Cela réduit l’état à conserver chez le récepteur, au prix d’un trafic supplémentaire après une perte.

Laisser un numéro de séquence hors de la fenêtre

Un champ de $k$ bits fournit $2^k$ numéros de paquet, réutilisés de façon cyclique. GBN impose

Avec trois bits, les numéros vont de 0 à 7 et la plus grande fenêtre d’émission vaut sept. Si les huit étaient autorisés, le récepteur pourrait accepter 0 à 7 et attendre à nouveau 0. Si tous les ACK étaient perdus, un ancien paquet 0 retransmis paraîtrait alors nouveau. Si seuls les paquets 0 à 6 ont été envoyés, le récepteur attend 7 et peut reconnaître le paquet 0 retransmis comme ancien. Près du rebouclage, le calcul sur la fenêtre suit l’ordre cyclique et non l’ordre numérique ordinaire.

La répétition sélective conserve les paquets reçus correctement même lorsque des paquets antérieurs manquent. Chaque paquet valide reçoit son propre ACK. L’émetteur peut alors remplacer uniquement le paquet dont le temporisateur expire.

Suivre chaque paquet séparément

La fenêtre de l’émetteur commence à send_base, le plus ancien paquet non acquitté, et contient $N$ numéros de séquence autorisés. Chaque paquet en attente d’acquittement possède un temporisateur logique. Un ACK marque le paquet correspondant comme reçu. Un ACK situé au-delà de la base ne fait pas avancer la fenêtre à lui seul : la base reste au premier manque. Une fois ce manque acquitté, la base avance au-delà des éventuels paquets suivants déjà acquittés.

La fenêtre du récepteur commence à rcv_base, le prochain paquet nécessaire à la livraison. Un paquet valide dans la fenêtre est acquitté. Les données reçues dans le désordre sont mises en mémoire tampon. Lorsque le paquet situé à la base arrive, le récepteur le livre ainsi que tous les paquets consécutifs qui le suivent en mémoire tampon, jusqu’au prochain manque.

Un paquet situé dans la fenêtre immédiatement précédente est un ancien doublon. Le récepteur l’acquitte à nouveau sans le livrer. Cette règle est essentielle lorsque l’ACK initial a été perdu : l’émetteur peut encore attendre même si le récepteur a poursuivi.

Récupérer un paquet perdu

Avec $N=4$, supposons que le paquet 2 soit perdu après l’envoi des paquets 0 à 3. Le récepteur livre et acquitte 0 et 1, puis met 3 en mémoire tampon et l’acquitte. Les deux premiers ACK permettent à l’émetteur d’envoyer 4 et 5. Tous deux sont mis en mémoire tampon et acquittés individuellement, mais send_base reste à 2.

Lorsque le temporisateur du paquet 2 expire, seul 2 est renvoyé. Son arrivée permet au récepteur de livrer ensemble 2, 3, 4 et 5 et d’avancer rcv_base à 6. Une fois ACK 2 parvenu à l’émetteur, sa base avance elle aussi à 6, en passant les paquets 3 à 5 dont il possède déjà les ACK.

Pourquoi la fenêtre vaut au plus la moitié de l’espace de numérotation

Le récepteur peut être en avance sur l’émetteur parce que des ACK sont retardés ou perdus. Les nouveaux numéros acceptables ne doivent pas chevaucher ceux qui pourraient encore être retransmis dans d’anciens paquets.

Avec des numéros de deux bits allant de 0 à 3 et une fenêtre de trois, supposons que le récepteur accepte 0, 1 et 2. Sa nouvelle fenêtre est {3, 0, 1}. Si tous les ACK disparaissent, un ancien paquet 0 retransmis entre dans cette fenêtre et paraît nouveau. Le récepteur ne peut pas le distinguer d’un paquet 0 réellement nouveau envoyé après la perte d’un paquet 3.

Pour des fenêtres d’émission et de réception de même taille, la borne sûre est

Une numérotation sur trois bits autorise donc des fenêtres de répétition sélective allant jusqu’à quatre, tandis que GBN en permet sept.

Distinguer une ancienne copie après le rebouclage

Les limites de fenêtre traitent les fenêtres actuelles, mais un réseau réel peut aussi conserver une ancienne copie en transit jusqu’à la réutilisation des numéros. Une durée de vie maximale des paquets limite le temps pendant lequel ces copies peuvent survivre. TCP l’appelle la durée de vie maximale d’un segment (MSL). À haut débit, TCP peut réutiliser rapidement son espace de numéros de séquence de 32 bits ; la protection contre le rebouclage des numéros de séquence (PAWS), fondée sur les horodatages, aide donc à rejeter les données périmées.

Une connexion TCP est un état conservé dans deux hôtes terminaux : des tampons, des compteurs d’octets et d’autres variables créés pendant l’établissement. Elle est point à point, entre deux extrémités, et en duplex intégral, ce qui permet aux deux d’envoyer simultanément. Les routeurs ordinaires transfèrent ses datagrammes IP sans conserver l’état TCP des extrémités.

Les octets n’ont pas de limites de message

TCP préserve l’ordre des octets, mais pas les limites des écritures de l’application. Trois écritures de 100 octets peuvent atteindre l’application en une seule lecture de 300 octets, ou en deux lectures de 50 et 250 octets. Une application qui échange des messages doit assurer leur délimitation, par exemple avec un champ de longueur ou un délimiteur. Une lecture courte ne prouve pas qu’un message complet est arrivé.

Les données écrites par l’application entrent dans un tampon d’émission. TCP choisit les blocs à transmettre et conserve les données non acquittées en vue d’une éventuelle retransmission. Les données entrantes vont dans un tampon de réception jusqu’à ce que l’application réceptrice les lise.

Distinguer la taille des données de celle des en-têtes

La taille maximale de segment (MSS) limite les données applicatives dans un segment. Elle exclut les en-têtes TCP et IP. Pour un chemin acceptant des datagrammes IP de 1 500 octets avec des en-têtes IPv4 de 20 octets et TCP de 20 octets,

Les options prennent davantage de place : l’émetteur doit donc tenir compte des longueurs réelles des en-têtes. Chaque extrémité annonce pendant la négociation la MSS qu’elle peut recevoir ; les limites du chemin peuvent réduire encore ce qui peut être envoyé. Sans option MSS, les valeurs supposées par défaut sont de 536 octets de données pour IPv4 et de 1 220 pour IPv6.

Lire les champs de l’en-tête

L’en-tête minimal comporte cinq mots de 32 bits, soit 20 octets. Un décalage des données de 8 signifie 32 octets, dont 12 octets au-delà de l’en-tête fixe. Le décalage maximal est 15 : 60 octets au total, ce qui autorise jusqu’à 40 octets d’options.

Interpréter les drapeaux et les options

SYN synchronise les numéros de séquence à l’ouverture. FIN ferme un sens d’émission. RST interrompt ou refuse une connexion. ACK rend le champ d’acquittement valide. PSH demande une livraison rapide à l’application ; il ne crée pas de limite de message. URG rend le pointeur de données urgentes valide, bien qu’il soit recommandé aux nouvelles applications d’éviter ce mécanisme. ECE et CWR transportent des signaux de notification explicite de congestion.

Les options courantes comprennent la MSS, la mise à l’échelle de la fenêtre, les horodatages et l’acquittement sélectif (SACK). La mise à l’échelle étend la plage de la fenêtre de réception. Les horodatages aident à mesurer le temps aller-retour et à rejeter les segments périmés. SACK décrit les blocs reçus au-delà d’un manque.

Sans options, TCP et IPv4 ajoutent 40 octets. Un segment plein de 1 460 octets de données occupe un datagramme IP de 1 500 octets, dont environ 97,3 % de données applicatives. Un ACK pur ne contient aucune donnée, mais occupe tout de même ces 40 octets d’en-têtes.

Les numéros de séquence TCP comptent les octets, et non les segments. Le numéro de séquence d’un segment désigne son premier octet de données. Son numéro d’acquittement décrit le sens opposé : le prochain octet que cet émetteur s’attend à recevoir.

Découper un flux en segments

Le SYN utilise un numéro de séquence initial (ISN) de 3 000. Le premier octet de données est donc 3 001. Un fichier de 10 000 octets avec une MSS de 1 460 nécessite six segments de données pleins et un segment plus court :

Chaque numéro de séquence suivant s’obtient en ajoutant la longueur des données du segment précédent. Le dernier octet est 13 000 : la réception correcte de tout le fichier produit donc l’ACK cumulatif 13 001.

Acquitter une suite continue

ACK $n$ confirme tous les octets jusqu’à $n-1$ inclus. Il ne confirme pas l’octet $n$. Si le récepteur possède les octets jusqu’à 4 460, il attend 4 461. Un segment commençant à 5 921 laisse un manque. Un récepteur qui met ce segment en mémoire tampon envoie toujours ACK 4 461, car sa suite continue ne s’est pas allongée.

C’est pourquoi l’acquittement ne peut pas simplement être le plus grand numéro de séquence observé. Des octets ultérieurs montrent que quelque chose est arrivé au-delà du manque ; ils ne le comblent pas. Lorsque la plage manquante arrive, un ACK cumulatif peut avancer au-delà des données déjà en mémoire tampon.

Suivre les deux sens indépendamment

Supposons que le prochain octet d’un client soit 1 000 et celui d’un serveur 5 000. Le client envoie 200 octets de données avec le numéro de séquence 1 000 et le numéro d’acquittement 5 000. La réponse du serveur contient 1 200 octets avec le numéro de séquence 5 000 et le numéro d’acquittement 1 200. Le prochain ACK pur du client porte le numéro de séquence 1 200 et le numéro d’acquittement 6 200.

Le serveur n’a pas déduit son propre numéro de séquence de la longueur de la requête. Chaque sens possède sa propre numérotation. Le transport d’un ACK avec les données sortantes est un acquittement incorporé aux données. Un ACK pur ne consomme aucun numéro de séquence ; SYN et FIN en consomment chacun un, même sans données.

Gérer les valeurs initiales et le rebouclage

Les extrémités choisissent un ISN à l’ouverture d’une connexion. Une horloge et une fonction pseudo-aléatoire à clé des adresses et des ports de la connexion aident à distinguer une nouvelle connexion des anciens segments retardés et rendent les numéros valides difficiles à deviner pour une personne extérieure. Commencer chaque connexion à zéro affaiblirait ces deux protections.

Les champs comportent 32 bits : la numérotation reboucle donc modulo $2^{32}$, soit environ 4,3 milliards d’octets. À 1 Gbit/s, parcourir cet espace prend environ 34 s ; à 10 Gbit/s, environ 3,4 s. PAWS, fondé sur les horodatages, fournit une vérification supplémentaire contre les segments périmés sur les chemins rapides.

Pour un calcul ordinaire loin du rebouclage, le prochain octet après un segment de données est son numéro de séquence augmenté de la longueur de ses données. En présence d’un SYN ou d’un FIN, ajoute le numéro supplémentaire que ce drapeau de contrôle consomme. Applique le calcul séparément à chaque sens.

L’établissement TCP permet aux deux extrémités d’annoncer un numéro de séquence initial et de savoir que le correspondant l’a reçu. La fermeture libère ensuite chaque sens séparément. Ces échanges de contrôle utilisent le même espace de numéros de séquence que les données.

Suivre la négociation en trois temps

1. Le client crée un état de connexion, envoie SYN avec l’ISN 7 000 et entre dans l’état SYN_SENT.
2. Le serveur répond par SYN-ACK, avec le numéro de séquence 21 000 et le numéro d’acquittement 7 001. Il se trouve dans l’état SYN_RCVD en attendant la confirmation.
3. Le client enregistre le numéro du serveur et envoie un ACK avec le numéro de séquence 7 001 et le numéro d’acquittement 21 001. Le client entre dans l’état ESTABLISHED ; le serveur y entre à l’arrivée de cet ACK.

Chaque SYN consomme un numéro. Le troisième segment peut déjà contenir des données applicatives. La négociation ordinaire coûte un aller-retour avant que le client puisse envoyer ces premières données. Un échange de deux messages n’indiquerait pas au serveur que le client a reçu son ISN et pourrait le conduire à accepter un ancien SYN retardé comme une nouvelle demande.

À l’interface des sockets, connect démarre une ouverture active. Un serveur attend les demandes et accept renvoie une nouvelle socket de connexion après l’établissement. La socket d’écoute reste disponible pour d’autres clients.

Fermer chaque sens

Une extrémité envoie FIN lorsqu’elle n’a plus d’octets à envoyer. Le correspondant acquitte ce FIN en avançant son ACK d’un numéro au-delà de celui-ci. Le correspondant peut encore envoyer ses propres octets restants : c’est une demi-fermeture. Son FIN ultérieur ferme l’autre sens et nécessite lui aussi un ACK. La fermeture utilise généralement quatre segments, même si un FIN et un ACK peuvent être combinés.

Pour un client qui ferme en premier, le parcours habituel des états est ESTABLISHED → FIN_WAIT_1 après l’envoi de FIN → FIN_WAIT_2 une fois ce FIN acquitté → TIME_WAIT après réception et acquittement du FIN du correspondant → CLOSED. Le correspondant passe par CLOSE_WAIT pendant que son application termine, puis par LAST_ACK après l’envoi de son propre FIN, et enfin par CLOSED à la réception de l’ACK.

Permettre la récupération du dernier ACK

Dans le parcours habituel d’une fermeture active, TIME_WAIT dure deux fois la durée de vie maximale d’un segment. Si l’ACK final disparaît, l’autre extrémité peut renvoyer son FIN et recevoir un nouvel ACK. L’attente laisse aussi aux anciens segments le temps d’expirer avant la réutilisation du quadruplet de la connexion. La valeur MSL de deux minutes prévue par la norme donne quatre minutes ; les implémentations peuvent utiliser des durées différentes, 60 secondes étant une valeur courante sous Linux.

Un RST diffère d’un FIN : il interrompt la connexion ou refuse une demande. Un SYN destiné à un port fermé reçoit normalement RST. SYN-ACK indique qu’un service est à l’écoute ; le silence peut résulter d’un filtrage, d’une perte ou d’une destination indisponible.

Protéger les négociations inachevées

Une inondation SYN envoie de nombreuses demandes d’ouverture sans les mener à terme. Un serveur qui réserve des ressources pour chaque connexion semi-ouverte peut épuiser l’espace disponible pour ces états. Les cookies SYN retardent l’allocation de cet état propre à chaque connexion. Le serveur encode des informations de connexion vérifiables dans l’ISN choisi, à l’aide d’un secret et d’une valeur dépendant du temps. Un ACK final valide renvoie le cookie dans son numéro d’acquittement, ce qui permet au serveur de le vérifier et de créer l’état. Le serveur conserve une socket d’écoute et des ressources partagées ; il évite de stocker une connexion inachevée distincte pour chaque SYN.

TCP a besoin d’un délai de retransmission assez long pour permettre les allers-retours normaux, mais assez court pour récupérer rapidement après une perte. Le temps aller-retour varie avec les changements de files d’attente et de chemins : le délai suit donc à la fois une estimation lissée et l’ampleur des écarts récents.

Prendre une mesure sans ambiguïté

SampleRTT mesure l’intervalle entre l’envoi de données et la réception d’un ACK qui les couvre. Dans une implémentation de base, TCP chronomètre un segment admissible à la fois. L’algorithme de Karn exclut les données retransmises des mesures ordinaires du temps aller-retour : un ACK peut se rapporter à la copie initiale ou à celle de remplacement. Des horodatages négociés peuvent lever cette ambiguïté.

La première mesure valide $R$ initialise EstimatedRTT à $R$ et DevRTT à $R\mathrm{/}2$. Avant toute mesure, le délai initial recommandé est de 1 s.

Actualiser l’écart avant la moyenne

Pour une nouvelle mesure, utilise l’EstimatedRTT précédent pour mesurer l’écart :

Actualise ensuite la moyenne mobile à pondération exponentielle :

Les pondérations recommandées sont $\beta =1\mathrm{/}4$ et $\alpha =1\mathrm{/}8$. Les mesures anciennes conservent moins d’influence après chaque actualisation. Actualiser d’abord la moyenne modifierait l’écart utilisé dans la première équation.

Effectuer une actualisation

Pars de EstimatedRTT = 100 ms et DevRTT = 10 ms ; prends une mesure de 120 ms.

1. Écart absolu : $\mathrm{\mid }120-100\mathrm{\mid }=20\text{ ms}$.
2. Nouveau DevRTT : $\mathrm{0,75}(10)+\mathrm{0,25}(20)=\mathrm{12,5}\text{ ms}$.
3. Nouveau EstimatedRTT : $\mathrm{0,875}(100)+\mathrm{0,125}(120)=\mathrm{102,5}\text{ ms}$.
4. Délai de base : $\mathrm{102,5}+4(\mathrm{12,5})=\mathrm{152,5}\text{ ms}$.

La règle de base est

La norme complète utilise EstimatedRTT + max(G, 4 DevRTT), où $G$ est la granularité de l’horloge. Lorsque la marge de quatre écarts dépasse l’intervalle de l’horloge, la règle de base donne le même résultat.

La norme recommande de porter à 1 s toute valeur calculée inférieure à 1 s. Les implémentations réelles peuvent utiliser un minimum plus faible ; sous Linux, un minimum courant est de 200 ms. Les 152,5 ms calculées sont donc une estimation brute, qui ne correspond pas nécessairement au délai réglé par un hôte. Une limite supérieure facultative doit être d’au moins 60 s.

Augmenter le délai après son expiration

Lorsque le temporisateur expire, TCP renvoie les plus anciennes données non acquittées et double le délai de retransmission. Une valeur actuelle de 0,75 s devient 1,5 s, puis 3 s après une nouvelle expiration. Des tentatives immédiates répétées ajouteraient du trafic à un chemin qui ne parvient déjà pas à acheminer les retours.

Un nouvel ACK ne réduit pas nécessairement ce délai augmenté. TCP a besoin d’une nouvelle mesure valide du temps aller-retour pour recalculer l’estimation. Sans horodatage, l’ambiguïté liée à la retransmission empêche d’utiliser comme nouvelle mesure un ACK pour les données renvoyées. Une fois de nouvelles données admissibles envoyées et acquittées, une nouvelle mesure peut faire baisser le délai calculé.

TCP combine une somme de contrôle, des numéros de séquence d’octets, des ACK cumulatifs et la retransmission pour livrer un flux fiable. L’émetteur doit distinguer un ACK qui fait avancer la livraison de celui qui répète la limite actuelle.

Suivre les événements de l’émetteur

SendBase est le premier octet non acquitté ; NextSeqNum est le prochain numéro d’octet inutilisé. Les nouvelles données applicatives sont envoyées avec le numéro de séquence NextSeqNum, qui avance ensuite de la longueur des données. Si aucun temporisateur de retransmission ne fonctionne, l’envoi de données en attente d’acquittement le démarre.

L’algorithme de base recommandé utilise un seul temporisateur de retransmission pour le plus ancien segment non acquitté. L’expiration du délai provoque la retransmission de ce plus ancien segment en attente, double l’intervalle et redémarre le temporisateur. Un ACK supérieur à SendBase fait avancer la base et redémarre le temporisateur si des données restent en attente d’acquittement. Si tout est acquitté, le temporisateur s’arrête. Un acquittement dupliqué ne fait pas avancer la base.

Les ACK perdus peuvent cesser de poser problème

A envoie 500 octets à partir de 501. B les reçoit et envoie ACK 1 001, qui est perdu. Si rien d’autre ne confirme ces octets, le délai de A expire et A les renvoie. B reconnaît le doublon, ne livre aucune donnée supplémentaire et renvoie ACK 1 001.

Supposons maintenant que A ait aussi envoyé les 500 octets suivants, à partir de 1 001. Si ACK 1 501 arrive avant l’expiration du délai, il confirme les deux segments. La perte de ACK 1 001 ne nécessite aucune retransmission. Un ACK est cumulatif : l’émetteur n’a donc pas besoin qu’un ACK distinct pour chaque segment parvienne à destination.

En cas d’expiration prématurée du délai, A ne renvoie que le plus ancien segment. Si des ACK retardés confirment ensuite les deux segments initiaux, A n’a pas besoin de renvoyer le second. Une expiration indique que le retour n’est pas arrivé à temps, sans prouver que tous les segments en attente ont disparu.

Utiliser le moment d’envoi des ACK pour signaler les manques

Pour des données reçues dans l’ordre sans ACK en attente, le récepteur peut différer brièvement un ACK, pendant moins de 0,5 s, afin de regrouper les acquittements. Il doit acquitter au moins un segment de taille maximale sur deux. Une deuxième arrivée dans l’ordre pendant qu’un ACK est en attente déclenche un ACK cumulatif. Une arrivée dans le désordre au-delà d’un manque déclenche immédiatement un acquittement dupliqué ; le comblement de tout ou partie d’un manque déclenche lui aussi immédiatement un ACK.

Combler un manque avant l’expiration du délai

Supposons que A envoie cinq segments de 1 000 octets commençant à 1 001, 2 001, 3 001, 4 001 et 5 001. Le deuxième est perdu. L’ACK de B après le premier est 2 001. Les trois arrivées suivantes produisent chacune un nouvel ACK 2 001.

Après trois acquittements dupliqués, A utilise la retransmission rapide pour renvoyer le segment commençant à 2 001 sans attendre l’expiration du délai. Les données ultérieures étant en mémoire tampon, le comblement de ce manque permet à B d’envoyer l’acquittement 6 001. Le premier ACK 2 001 est l’ACK initial ; les trois suivants sont des doublons. Un ou deux doublons peuvent résulter d’un simple changement dans l’ordre d’arrivée, ce qui explique l’attente d’indices supplémentaires.

TCP combine des idées des deux protocoles à fenêtre. Ses ACK cumulatifs et son temporisateur unique de base ressemblent à GBN, mais sa mise en mémoire tampon et ses retransmissions ciblées ressemblent à la répétition sélective. L’option SACK négociée signale les blocs d’octets conservés au-delà de la limite cumulative, afin que l’émetteur puisse identifier plusieurs manques plus précisément. TCP n’envoie pas de NAK en cas d’échec de la somme de contrôle ; le manque qui en résulte est révélé par les ACK ultérieurs ou l’expiration du délai.

Le contrôle de flux empêche un émetteur TCP de faire déborder le tampon du récepteur. Il réagit à la vitesse de lecture de l’application réceptrice. Le contrôle de congestion réagit à la charge du réseau ; les deux contrôles protègent des ressources différentes.

Calculer l’espace disponible

Soit RcvBuffer la capacité du tampon, LastByteRcvd le dernier octet stocké dans l’ordre et LastByteRead le dernier octet lu par l’application. Dans ce modèle de données contiguës, l’espace occupé est LastByteRcvd − LastByteRead. La fenêtre de réception est

Le récepteur annonce l’espace disponible dans le champ de fenêtre des segments qu’il renvoie. L’émetteur maintient son nombre d’octets non acquittés dans cette limite :

Pour RcvBuffer = 40 000 octets, LastByteRcvd = 30 000 et LastByteRead = 18 000, l’espace occupé est de 12 000 octets et rwnd vaut 28 000 octets. ACK 30 001 avec cette fenêtre autorise des octets non acquittés jusqu’à 58 000. Si l’émetteur a déjà envoyé jusqu’à 34 000, il a 4 000 octets en attente d’acquittement et peut en envoyer 24 000 de plus. La fenêtre est une limite pour tous les octets en attente d’acquittement, et non une autorisation supplémentaire qui s’y ajoute.

Reprendre après une fenêtre nulle

Lorsqu’il ne reste plus de place, le récepteur annonce rwnd = 0 et l’émetteur arrête la transmission normale de nouvelles données. Lorsque l’application lit, le récepteur annonce l’espace nouvellement disponible dans une mise à jour de fenêtre.

Cette mise à jour peut être un ACK pur, qui n’est pas acheminé de manière fiable à lui seul. S’il est perdu, l’émetteur pourrait continuer d’attendre alors que de l’espace est disponible. Les sondes de fenêtre nulle, qui transportent couramment un octet, incitent le récepteur à renvoyer sa fenêtre actuelle. Les sondes sont espacées par des intervalles croissants ; elles ne constituent pas un envoi normal de données en masse à travers une fenêtre fermée.

Relier la fenêtre au débit effectif

Avec une fenêtre et un temps aller-retour fixes, le débit effectif idéal limité par la fenêtre vérifie

Utilise des octets et des secondes pour obtenir des octets/s. Une fenêtre de 65 535 octets avec un temps aller-retour de 0,1 s permet environ 655 350 octets/s, soit 5,2 Mbit/s. Un débit de liaison plus élevé ne peut pas supprimer cette limite imposée par la fenêtre.

Pour occuper pleinement un chemin, la fenêtre doit couvrir son produit débit-délai. À 1 Gbit/s et 0,1 s, les données en vol nécessaires représentent 100 millions de bits, soit 12,5 Mo. Cette taille de fenêtre est nécessaire pour atteindre ce débit idéal, mais ne garantit pas qu’il sera atteint.

Mettre le champ à l’échelle et éviter les mises à jour minuscules

Le champ de 16 bits seul ne peut pas représenter une fenêtre aussi grande. Une option de mise à l’échelle de la fenêtre négociée dans les SYN multiplie les valeurs ultérieures de la fenêtre par $2^s$, avec $s\le 14$. La plus grande échelle donne un peu moins de 1 Gio. Un décalage de 7 autorise au plus 8 388 480 octets ; un décalage de 8 en autorise 16 776 960, ce qui suffit pour l’exemple de 12,5 Mo. Le facteur d’échelle reste fixe pour son sens, tandis que l’espace annoncé continue de changer. Les champs de fenêtre des SYN eux-mêmes ne sont pas mis à l’échelle.

Annoncer chaque petit groupe d’octets nouvellement libérés peut provoquer le syndrome de la fenêtre stupide : de nombreux segments minuscules avec une forte surcharge d’en-tête. Pour l’éviter, le récepteur attend qu’une quantité utile d’espace soit libre, généralement une MSS ou la moitié du tampon, selon la plus petite des deux valeurs. L’algorithme de Nagle traite les petites écritures de l’émetteur en les retenant tant que des données antérieures restent non acquittées, ou jusqu’à ce que suffisamment de données forment un segment plein.