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

Nous voici au sommet de la pile, celui que vous utilisez sans y penser à chaque instant. Les sept chapitres précédents ont construit un tuyau fiable et mondial ; la couche application est ce que les programmes en font. Quand vous chargez une page web, une chorégraphie invisible se déclenche en une fraction de seconde : votre machine obtient une adresse (DHCP), traduit le nom du site en adresse IP (DNS), établit une connexion (TCP, chapitre 7) et demande la page (HTTP). Ce chapitre démonte cette chorégraphie.

C'est aussi le chapitre où l'on voit converger tout le cours : chaque service applicatif s'appuie sur les couches du dessous, et fait un choix — TCP ou UDP, tel port, tel protocole — qu'on sait désormais interpréter.

Le modèle client-serveur

La plupart des applications réseau suivent le modèle client-serveur. Le serveur attend passivement, à l'écoute sur un port connu (chapitre 7) ; le client prend l'initiative, se connecte, envoie une requête, reçoit une réponse. Votre navigateur est un client, le site un serveur ; votre application de courriel est un client, le serveur de messagerie un serveur.

Ce modèle est asymétrique par nature : le serveur doit être joignable en permanence à une adresse stable (d'où l'importance du DNS, plus bas), le client peut apparaître et disparaître. Il existe d'autres organisations — le pair-à-pair, où chaque machine est à la fois client et serveur — mais le client-serveur reste le modèle dominant, et celui de tous les services de ce chapitre.

DNS : traduire les noms en adresses

Vous tapez www.exemple.fr, mais le routage (chapitre 6) ne connaît que des adresses IP. Le DNS (Domain Name System) fait le pont : il traduit les noms en adresses. C'est l'annuaire d'Internet — et l'une des idées les plus élégantes du réseau.

Sa force est qu'il n'existe aucun annuaire central. Le DNS est une base de données distribuée et hiérarchique, lue de droite à gauche :

1www . exemple.fr .2 │      │      └── géré par les serveurs racines3 │      └───────── géré par les serveurs du TLD « .fr »4 └──────────────── géré par les serveurs du domaine « exemple.fr »

Résoudre un nom, c'est descendre cette hiérarchie : demander à un serveur racine où trouver .fr, puis au serveur .fr où trouver exemple.fr, puis au serveur du domaine l'adresse de www. Chaque niveau ne connaît que le suivant — cette délégation est ce qui permet au système de gérer des milliards de noms sans effondrement.

Deux points pratiques essentiels. D'abord, le cache : les réponses sont mémorisées (pour une durée, le TTL), sinon chaque clic redemanderait toute la chaîne aux serveurs racines, qui s'effondreraient sous la charge mondiale. Ensuite, le protocole : le DNS emploie surtout UDP (chapitre 7) — question courte, réponse courte, rapidité prioritaire, et on redemande si une réponse se perd. C'est exactement le profil pour lequel UDP existe. L'exercice de ce chapitre vous fera dérouler cette résolution, cache compris.

HTTP et HTTPS : le web

HTTP (HyperText Transfer Protocol) est le protocole du web, sur le port 80. Il est client-serveur et requête-réponse : le navigateur envoie une requête (GET /index.html, « donne-moi cette page »), le serveur renvoie une réponse (la page, précédée d'un code de statut : 200 succès, 404 introuvable, 500 erreur serveur, 301 déplacé). HTTP repose sur TCP (chapitre 7) : le web exige que la page arrive complète et dans l'ordre, c'est le profil « fiabilité avant tout ».

HTTPS est HTTP chiffré, sur le port 443. Il ajoute une couche de sécurité (TLS) entre TCP et HTTP, qui chiffre les échanges et authentifie le serveur — vous parlez bien au site annoncé, et personne sur le chemin ne peut lire ni modifier le contenu. C'est aujourd'hui le standard : le web non chiffré disparaît. Retenez la distinction : HTTP transporte en clair, HTTPS chiffre en transit — la première des notions de sécurité de ce chapitre.

Messagerie et DHCP

Deux autres services complètent le tableau du quotidien.

La messagerie électronique combine plusieurs protocoles : SMTP pour envoyer un message (de client à serveur, puis de serveur à serveur), IMAP (ou l'ancien POP) pour consulter sa boîte depuis un client. La séparation envoi/réception explique une réalité familière : un problème de « je ne reçois plus » et un problème de « je ne peux plus envoyer » relèvent de protocoles différents.

DHCP (Dynamic Host Configuration Protocol) est le service qui vous configure automatiquement en arrivant sur un réseau. Sans lui, il faudrait saisir à la main, sur chaque machine, son adresse IP, son masque (chapitre 5), sa passerelle par défaut (chapitre 6) et son serveur DNS. DHCP les attribue automatiquement : à la connexion, votre machine diffuse « qui peut me configurer ? », un serveur DHCP lui répond avec un jeu de paramètres pour une durée donnée. C'est le service invisible qui fait qu'un téléphone rejoint un Wi-Fi « tout seul » — et, là encore, il emploie surtout UDP.

Notez la belle mise en abyme : DHCP vous donne l'adresse (chapitre 5) et la passerelle (chapitre 6), et vous indique le serveur DNS, qui vous permettra ensuite de résoudre les noms. Tout le cours se retrouve dans les premières secondes d'une connexion.

Notions de base de sécurité

La sécurité mérite un chapitre entier (et un cours entier, en L3) ; on en pose ici les trois idées minimales, ancrées dans ce qu'on a vu.

Le chiffrement en transit protège les données pendant leur voyage sur le réseau. C'est ce que fait HTTPS : sans lui, tout ce qui transite sur un réseau (surtout un Wi-Fi public, chapitre 4) peut être lu par un tiers. Le cadenas de votre navigateur signale ce chiffrement.

Le mot de passe authentifie l'utilisateur, mais il ne vaut que s'il voyage chiffré (donc en HTTPS) et s'il est fort. Un mot de passe envoyé en HTTP clair est lisible par quiconque sur le chemin — d'où la disparition du web non chiffré.

Le pare-feu (firewall) filtre le trafic entrant et sortant selon des règles : il autorise ce qui est légitime, bloque le reste. C'est la première barrière d'un réseau contre les connexions non désirées.

Ces trois notions ne sont qu'un aperçu — elles répondent chacune à une menace précise (écoute, usurpation d'identité, intrusion), et le cours de cybersécurité de L3 les reprendra en profondeur, attaques à l'appui.

À vous

L'exercice fait dérouler la résolution DNS, la première étape invisible de toute navigation. Vous implémentez la descente dans la hiérarchie — racine, puis .fr, puis le domaine — avec un cache, et vous comptez les requêtes réseau : trois pour la première résolution, zéro pour la seconde grâce au cache.

Vous verrez concrètement pourquoi le DNS doit être hiérarchique (personne ne connaît tout l'Internet) et pourquoi le cache est vital (sans lui, les serveurs racines crouleraient). Et vous retrouverez, en filigrane, le choix d'UDP du chapitre 7 : question courte, réponse courte, rapidité d'abord.

// Le DNS traduit un NOM (www.exemple.fr) en ADRESSE IP. Il n'existe pas UN
// annuaire géant : le nom est résolu par une HIÉRARCHIE de serveurs, lus de
// DROITE à GAUCHE — racine, puis .fr, puis exemple.fr.

// La hiérarchie (simulée). Chaque niveau connaît le serveur du niveau suivant.
const RACINE   = { "fr": "serveur .fr", "com": "serveur .com" };
const TLD_FR   = { "exemple.fr": "serveur exemple.fr" };
const AUTO_EX  = { "www.exemple.fr": "93.184.5.10", "mail.exemple.fr": "93.184.5.20" };

const cache = {};   // nom -> IP (mémorise les réponses passées)
let requetes = 0;

function demander(serveur, question) {
  requetes++;
  console.log("   requête #" + requetes + " -> " + serveur + " : « " + question + " ? »");
  if (serveur === "racine")            return RACINE[question];
  if (serveur === "serveur .fr")       return TLD_FR[question];
  if (serveur === "serveur exemple.fr")return AUTO_EX[question];
}

// ── À VOUS : la résolution récursive ────────────────────────────────────────
// Pour résoudre "www.exemple.fr" :
//   1. si le nom est dans le cache, le renvoyer SANS aucune requête réseau
//   2. sinon : demander à la racine le serveur de "fr",
//              puis à ce serveur le serveur de "exemple.fr",
//              puis à ce serveur l'IP de "www.exemple.fr"
//   3. mettre le résultat en cache
function resoudre(nom) {
  if (cache[nom]) { console.log("   (cache) " + nom + " = " + cache[nom]); return cache[nom]; }
  // à compléter :
  // const srvFr = demander("racine", "fr");
  // const srvDom = demander(srvFr, "exemple.fr");
  // const ip = demander(srvDom, nom);
  // cache[nom] = ip; return ip;
  return null;
}

// ── Vérification ────────────────────────────────────────────────────────────
console.log("1re résolution de www.exemple.fr :");
console.log(" => " + resoudre("www.exemple.fr"));
console.log("");
console.log("2e résolution de www.exemple.fr :");
console.log(" => " + resoudre("www.exemple.fr"));
console.log("");
console.log("Total de requêtes réseau émises :", requetes);

function resoudre(nom) {
  if (cache[nom]) { console.log("   (cache) " + nom + " = " + cache[nom]); return cache[nom]; }
  const srvFr  = demander("racine", "fr");            // racine -> serveur .fr
  const srvDom = demander(srvFr, "exemple.fr");       // .fr    -> serveur du domaine
  const ip     = demander(srvDom, nom);               // domaine -> IP finale
  cache[nom] = ip;                                    // on mémorise
  return ip;
}
// 1re résolution : 3 requêtes (racine, .fr, exemple.fr) -> 93.184.5.10
// 2e résolution : 0 requête, le cache répond.
// Total : 3 requêtes réseau, pas 6.

// ── Ce que l'exercice enseigne ──────────────────────────────────────────────
//
// 1. Le DNS est une BASE DE DONNÉES DISTRIBUÉE et HIÉRARCHIQUE. Aucun serveur
//    ne connaît tout l'Internet ; chaque niveau connaît seulement le serveur
//    du niveau en dessous. On lit le nom de DROITE à GAUCHE : racine -> TLD
//    (.fr) -> domaine (exemple.fr) -> hôte (www). Cette délégation est ce qui
//    rend le système extensible à des milliards de noms.
//
// 2. Le CACHE est vital. Sans lui, chaque clic redemanderait toute la chaîne
//    à la racine — quelques serveurs racines s'effondreraient sous la charge
//    mondiale. Avec lui, la 2e résolution coûte 0 requête. Les réponses ont
//    une durée de vie (TTL) après laquelle le cache est rafraîchi.
//
// 3. Le DNS emploie surtout UDP (chapitre 7) : une question courte, une
//    réponse courte, la rapidité prime — et si une réponse se perd, on
//    redemande. C'est exactement le profil « UDP » vu au chapitre transport.
//
// 4. C'est la PREMIÈRE étape invisible de toute navigation : avant même de
//    contacter un site en HTTP, le navigateur résout son nom en IP. Une panne
//    DNS donne l'impression que « tout Internet est cassé » alors que le
//    routage fonctionne — un grand classique du dépannage (chapitre 9).

Ce que la suite en fait

La pile est complète, de bout en bout : du signal sur le fil jusqu'à la page web affichée. Vous comprenez maintenant chaque étage et chaque protocole majeur, et surtout comment ils coopèrent — une simple navigation mobilise DHCP, DNS, TCP et HTTP, sur IP, sur Ethernet ou Wi-Fi, sur un support physique.

Le chapitre 9, dernier du cours, est entièrement pratique. Il apprend à configurer une machine et surtout à diagnostiquer une panne — non pas au hasard, mais méthodiquement, couche par couche, en partant du bas. Toute la structure en couches du cours y devient un outil de travail : savoir à quelle couche se situe un problème, c'est déjà l'avoir à moitié résolu.

À retenir