Couche transport

La couche réseau (chapitres 5-6) sait acheminer un paquet à travers le monde — mais « au mieux » : elle le perd parfois, le duplique, le livre en désordre, sans jamais s'en soucier. Aucune application sérieuse ne peut vivre avec cela tel quel : un fichier téléchargé avec des morceaux manquants est inutilisable, une page web aux octets mélangés illisible. La couche transport comble ce vide.

Elle apporte deux choses que la couche réseau ne fournit pas : la capacité pour plusieurs applications de partager une même adresse IP (les ports), et, pour qui le demande, la fiabilité de bout en bout (TCP). Le point conceptuel du chapitre, celui qui explique toute l'architecture d'Internet, est que cette fiabilité est reconstruite aux extrémités, sur les deux machines aux bouts — jamais dans le réseau lui-même, qui reste volontairement simple.

Les ports : plusieurs applications, une adresse

Une machine a une seule adresse IP, mais fait tourner plusieurs applications réseau en même temps : un navigateur, un client de messagerie, une mise à jour en arrière-plan. Quand un paquet arrive, à laquelle le remettre ?

C'est le rôle du port : un numéro sur 16 bits (0 à 65535) qui identifie l'application destinataire au sein de la machine. Le couple (adresse IP, port) désigne donc précisément un point de communication — l'IP trouve la machine, le port trouve l'application dessus. C'est ce qu'on appelle le multiplexage : partager un même lien entre plusieurs conversations.

Certains ports sont standardisés, ce qui permet de joindre un service sans se concerter au préalable :

Quand vous tapez une adresse web, votre navigateur contacte le port 80 (ou 443) du serveur par convention — c'est pourquoi vous n'avez pas à le préciser.

UDP : le minimalisme

UDP (User Datagram Protocol) est le protocole de transport minimal. Il ajoute à IP juste ce qu'il faut pour atteindre une application — les ports et un petit contrôle d'erreur — et rien d'autre. Il n'établit pas de connexion, ne numérote pas, n'acquitte pas, ne retransmet pas, ne remet pas en ordre. Il est donc rapide et léger, mais hérite du « au mieux » d'IP : un datagramme UDP peut se perdre sans que personne ne s'en aperçoive.

Ce dépouillement n'est pas un défaut : c'est un choix, adapté à des usages précis où la rapidité prime sur la complétude. La vidéo et la voix en direct : mieux vaut sauter une image que figer l'écran pour attendre une retransmission qui arriverait trop tard. Le DNS : une requête, une réponse, très courtes — établir une connexion coûterait plus cher que la donnée elle-même. Le jeu en ligne : la position d'il y a une seconde ne sert à rien, on veut la dernière.

TCP : la fiabilité de bout en bout

TCP (Transmission Control Protocol) est l'opposé d'UDP : il transforme le service « au mieux » d'IP en un canal fiable et ordonné, au prix de plus de mécanismes et de délais. Il garantit que les données arrivent toutes, intactes, dans l'ordre, sans doublon.

Il y parvient par trois mécanismes, que l'exercice de ce chapitre vous fera implémenter :

1. Numérotation — chaque octet porte un numéro de séquence, ce qui permet de remettre en ordre les segments arrivés dans le désordre et de repérer les doublons.
2. Acquittement (ACK) — le récepteur confirme ce qu'il a reçu. L'émetteur sait ainsi ce qui est bien arrivé.
3. Retransmission — ce qui n'est pas acquitté dans un certain délai est renvoyé. C'est la correction des pertes — celle que la couche liaison (chapitre 4) ne faisait pas, se contentant de détecter et de jeter, et que IP ne fait pas du tout.

TCP ajoute par-dessus une fenêtre (plusieurs segments « en vol » à la fois, pour ne pas attendre un ACK après chaque envoi) et le contrôle de congestion (ralentir spontanément quand le réseau sature, pour ne pas l'aggraver — un comportement citoyen essentiel à la stabilité d'Internet). Ces raffinements dépassent la L1 ; retenez les trois mécanismes de base.

La connexion en trois temps

Contrairement à UDP, TCP est orienté connexion : avant d'échanger des données, les deux machines établissent une connexion par une poignée de main en trois temps (three-way handshake) :

1client  ──SYN──────────────▶  serveur     (« je veux me connecter, seq = x »)2client  ◀──────SYN + ACK───  serveur     (« d'accord, seq = y, j'ai vu ton x »)3client  ──ACK──────────────▶  serveur     (« j'ai vu ton y, on est connectés »)

Cet échange synchronise les numéros de séquence de départ des deux côtés et confirme que chacun peut à la fois émettre et recevoir. Ce n'est qu'après ces trois messages que les données circulent. La fermeture suit un dialogue analogue. Ce coût initial — un aller-retour avant la première donnée — est le prix de la fiabilité, et l'une des raisons pour lesquelles UDP est préféré quand chaque milliseconde compte.

TCP ou UDP : comment choisir

Le choix se résume à une question : la perte d'une donnée est-elle grave, ou le retard est-il pire que la perte ?

Ce n'est pas que l'un serait « meilleur » : ils répondent à des besoins opposés. TCP échange de la rapidité contre de la garantie ; UDP fait l'inverse. Bien concevoir une application réseau, c'est d'abord savoir de quel côté de cet arbitrage on se trouve — le même type de compromis que débit/latence au chapitre 1, ou fiabilité/débit au chapitre 3.

À vous

L'exercice fait construire, de vos mains, la fiabilité de TCP au-dessus d'un canal qui perd un segment sur trois. Vous implémentez les trois mécanismes : numéroter les segments, acquitter le prochain attendu côté récepteur, et retransmettre côté émetteur ce qui n'est pas acquitté.

Vous constaterez que le message arrive entier et dans l'ordre malgré les pertes — et surtout, le point à emporter : cette fiabilité est ajoutée aux extrémités, sans jamais toucher au réseau « au mieux » du dessous. C'est le principe de bout en bout, le choix d'architecture fondateur d'Internet, rendu tangible.

// IP perd, duplique et désordonne les paquets (chapitre 6). TCP rétablit la
// fiabilité AUX EXTRÉMITÉS, avec trois idées :
//   1. NUMÉROTER chaque segment (numéro de séquence)
//   2. ACQUITTER ce qu'on a reçu (ACK)
//   3. RETRANSMETTRE ce qui n'est pas acquitté à temps
//
// On simule un canal qui perd un segment sur trois.

let horloge = 0;
function canalPeuFiable(segment) {
  horloge++;
  if (horloge % 3 === 0) { console.log("   [réseau] segment #" + segment.num + " PERDU"); return null; }
  return segment;                       // sinon, livré
}

// ── Le récepteur : remet en ordre, acquitte le prochain attendu ─────────────
const recu = {};              // num -> donnée reçue
let prochainAttendu = 0;      // le plus petit numéro pas encore reçu dans l'ordre
function recevoir(segment) {
  if (!segment) return null;                 // rien n'est arrivé
  recu[segment.num] = segment.donnee;
  while (recu[prochainAttendu] !== undefined) prochainAttendu++;  // avance
  return prochainAttendu;                     // ACK = « j'attends maintenant ça »
}

// ── À VOUS : l'émetteur fiable ──────────────────────────────────────────────
// Envoyer les segments 0..N-1 ; tant que TOUT n'est pas acquitté, renvoyer le
// premier segment non encore acquitté.
function envoyerFiable(donnees) {
  const segments = donnees.map((d, num) => ({ num, donnee: d }));
  let base = 0;                              // premier segment pas encore acquitté
  let tentatives = 0;
  while (base < segments.length && tentatives < 50) {
    tentatives++;
    const seg = segments[base];
    console.log("émission segment #" + seg.num + " (" + seg.donnee + ")");
    const ack = recevoir(canalPeuFiable(seg));
    // à compléter : si un ACK est revenu, avancer 'base' jusqu'à cet ACK
    // (ack = prochain attendu, donc tout ce qui est < ack est acquitté)
  }
  return prochainAttendu;
}

// ── Vérification ────────────────────────────────────────────────────────────
const message = ["HEL", "LO_", "WOR", "LD!"];
const livres = envoyerFiable(message);
console.log("");
console.log("segments livrés dans l'ordre :", livres, "/", message.length);
console.log("message reconstruit :", Object.keys(recu).sort((a,b)=>a-b).map(k=>recu[k]).join(""));

function envoyerFiable(donnees) {
  const segments = donnees.map((d, num) => ({ num, donnee: d }));
  let base = 0;
  let tentatives = 0;
  while (base < segments.length && tentatives < 50) {
    tentatives++;
    const seg = segments[base];
    console.log("émission segment #" + seg.num + " (" + seg.donnee + ")");
    const ack = recevoir(canalPeuFiable(seg));
    if (ack !== null && ack > base) {
      base = ack;              // tout ce qui est < ack est acquitté : on avance
    }
    // si ack est null (segment perdu) ou n'a pas progressé : on RENVOIE le
    // même segment au tour suivant. C'est la retransmission.
  }
  return prochainAttendu;
}
// Le message finit par arriver ENTIER et DANS L'ORDRE, malgré 1 perte sur 3 :
// les segments perdus sont simplement réémis jusqu'à être acquittés.

// ── Ce que l'exercice enseigne ──────────────────────────────────────────────
//
// 1. La fiabilité n'est PAS dans le réseau — elle est reconstruite AUX
//    EXTRÉMITÉS. IP reste « au mieux » (simple, rapide, chapitre 6) ; TCP,
//    seulement sur les deux machines aux bouts, rattrape ses défauts. C'est le
//    principe de bout en bout d'Internet.
//
// 2. Les trois mécanismes fondamentaux, tous vus ici :
//    - NUMÉROTATION : chaque octet/segment a un numéro de séquence, ce qui
//      permet la remise en ORDRE et la détection des DOUBLONS.
//    - ACQUITTEMENT (ACK) : le récepteur confirme ce qu'il a reçu (ici « le
//      prochain que j'attends »).
//    - RETRANSMISSION sur délai : ce qui n'est pas acquitté à temps est
//      renvoyé. C'est la CORRECTION des pertes — celle que la couche liaison
//      (chapitre 4) ne faisait pas, se contentant de détecter.
//
// 3. Le vrai TCP ajoute par-dessus une FENÊTRE (plusieurs segments en vol à la
//    fois, pour la vitesse) et le CONTRÔLE DE CONGESTION (ralentir quand le
//    réseau sature). Notre version envoie un segment à la fois : le principe
//    est correct, l'optimisation en moins.

Ce que la suite en fait

La pile est presque complète : les bits (chapitre 3), le lien local (chapitre 4), l'adressage et le routage mondial (chapitres 5-6), et maintenant un transport de bout en bout, fiable ou rapide selon le besoin. Il ne manque que le sommet — ce que les applications font réellement de tout cela.

Le chapitre 8 parcourt la couche application : le modèle client-serveur, le DNS (qui traduit les noms en adresses IP — et emploie surtout UDP, comme on vient de le voir), HTTP et HTTPS (le web), la messagerie, DHCP (qui attribue automatiquement les adresses), et une première approche de la sécurité. C'est là que tout ce que vous avez monté prend enfin la forme des services que vous utilisez chaque jour.

À retenir