Modèles en couches

Voici l'idée maîtresse de tout le cours, celle sans laquelle les réseaux seraient un chaos ingérable. Un réseau doit résoudre des dizaines de problèmes très différents : transmettre des bits sur un fil, trouver la bonne machine parmi des milliards, rattraper des paquets perdus, afficher une page web. Vouloir tout traiter d'un bloc serait impossible. La solution, trouvée très tôt, est de découper en couches.

Une fois ce modèle en tête, chaque protocole du reste du cours — Ethernet, IP, TCP, HTTP, DNS — prendra une place précise, et les huit chapitres suivants ne feront que remplir les cases. C'est le plan du cours autant qu'une technique.

Pourquoi découper en couches

Le principe est celui de la séparation des préoccupations : on empile des couches, chacune chargée d'un problème, chacune offrant un service à la couche au-dessus et s'appuyant sur le service de la couche en dessous. Une couche ne sait rien de ce que font les autres au détail — elle connaît seulement l'interface : ce qu'elle reçoit d'en haut, ce qu'elle demande en bas.

Trois bénéfices en découlent, et ils sont considérables :

• Indépendance. On peut remplacer une couche sans toucher aux autres. Passer du câble au Wi-Fi change la couche basse ; TCP et HTTP au-dessus ne s'en aperçoivent pas. Passer de HTTP à HTTPS change le haut ; IP en dessous ne change pas.
• Interopérabilité. Tant que deux implémentations respectent l'interface d'une couche, elles coopèrent — quels que soient leur fabricant, leur système, leur langage. C'est ce qui permet à un téléphone Android de parler à un serveur Linux via un routeur d'une troisième marque.
• Maîtrise de la complexité. On raisonne sur une couche à la fois. C'est aussi ce qui rend le dépannage méthodique — le chapitre 9 diagnostiquera une panne couche par couche.

Le modèle OSI : sept couches de référence

Le modèle OSI (Open Systems Interconnection) est le modèle théorique de référence, en sept couches. On ne l'implémente pas tel quel, mais son vocabulaire est universel : dire « c'est un problème de couche 3 » suppose ce modèle.

Retenez surtout la numérotation : « couche 2 », « couche 3 », « couche 7 » sont des expressions du métier. Un commutateur est un équipement « de couche 2 », un routeur « de couche 3 » — le chapitre 4 et le chapitre 6 le montreront.

Le modèle TCP/IP : quatre couches réelles

Le modèle TCP/IP est celui qu'Internet emploie réellement. Plus simple, en quatre couches, il regroupe certaines couches OSI :

Ce tableau est le plan du cours. On montera les couches de bas en haut : la couche accès réseau (chapitres 3-4), la couche réseau et son cœur, l'adressage IP (chapitres 5-6), la couche transport (chapitre 7), la couche application (chapitre 8).

Deux modèles, deux usages : OSI pour parler et raisonner (les sept couches, le vocabulaire), TCP/IP pour comprendre Internet (les quatre couches, les vrais protocoles). Ils ne s'opposent pas ; on emploie les deux.

Encapsulation et décapsulation

Comment les couches coopèrent-elles concrètement ? Par encapsulation. Quand une donnée descend la pile à l'émission, chaque couche l'enveloppe dans son propre en-tête — comme des poupées russes. Sur GET /index.html :

1application :                                  [HTTP] GET /index.html2transport   :                    [TCP port=80] [HTTP] GET /index.html3réseau      :      [IP dst=...]   [TCP port=80] [HTTP] GET /index.html4liaison     : [ETH][IP dst=...]   [TCP port=80] [HTTP] GET /index.html   ← sur le câble

À la réception, l'opération inverse — la décapsulation : chaque couche lit son en-tête, le retire, et transmet le reste à la couche au-dessus. La machine réceptrice défait exactement ce que l'émettrice a construit, dans l'ordre inverse.

Le vocabulaire de l'unité de données change à chaque niveau, et il faut le connaître : on parle de trame en couche liaison, de paquet (ou datagramme) en couche réseau, de segment en couche transport, de message en application. C'est toujours la même donnée, vue à travers un en-tête différent.

Le point le plus important, celui qui fait toute la puissance du modèle : chaque couche ne lit que son propre en-tête et ignore le contenu qu'elle transporte. Un routeur (couche 3) lit l'en-tête IP pour décider où envoyer le paquet — il ne regarde jamais le HTTP à l'intérieur. C'est cette indifférence au contenu qui rend les couches indépendantes, et c'est exactement ce que Wireshark vous montrera : les en-têtes emboîtés, du câble vers l'application.

Protocole et service : ne pas confondre

Dernière distinction, discrète mais structurante. Un service est ce qu'une couche offre — son interface, le « quoi ». Un protocole est comment deux machines de même couche communiquent — les règles, le « comment ».

La couche transport offre un service à l'application : « transmets ces données de façon fiable ». Elle le réalise par un protocole, TCP, avec ses règles précises d'échange (chapitre 7). L'appli ne connaît que le service (« fiable ») ; elle ignore le protocole (poignée de main, numéros de séquence). C'est pourquoi on peut, en principe, changer de protocole sans changer le service rendu — la promesse de l'indépendance des couches, encore.

À vous

L'exercice rend l'encapsulation tangible. À l'émission, vous faites descendre une donnée dans la pile, chaque couche ajoutant son en-tête ; à la réception, vous la faites remonter, chaque couche retirant le sien dans l'ordre inverse — et vous vérifiez qu'on retrouve la donnée d'origine, intacte.

Le point à saisir en le codant : chaque couche ne touche qu'à son en-tête et ignore ce qu'elle transporte. C'est cette indifférence au contenu qui autorise à changer une couche sans toucher aux autres — et c'est exactement ce que Wireshark affichera en TP, les en-têtes emboîtés les uns dans les autres.

// ── 1. Attributs publics : l'invariant ne tient à rien ────────────────────
class LivreOuvert {
  constructor(titre) {
    this.titre = titre;
    this.disponible = true;
    this.emprunteur = null;
  }
  // Invariant voulu : emprunteur non nul  <=>  disponible faux.
  emprunter(qui) {
    if (!this.disponible) return false;
    this.disponible = false;
    this.emprunteur = qui;
    return true;
  }
  invariantOk() {
    return (this.emprunteur === null) === this.disponible;
  }
  toString() {
    return this.titre + " [" + (this.disponible ? "libre" : "pris par " + this.emprunteur) + "]";
  }
}

// ── 2. Version encapsulée ─────────────────────────────────────────────────
class Livre {
  #titre; #disponible; #emprunteurs;      // # = champ réellement privé

  constructor(titre) {
    if (!titre) throw new Error("un livre doit avoir un titre");
    this.#titre = titre;
    this.#disponible = true;
    this.#emprunteurs = [];
  }
  get titre() { return this.#titre; }
  estDisponible() { return this.#disponible; }

  emprunter(qui) {
    // ← à écrire : refuser si déjà emprunté, sinon enregistrer l'emprunteur
    return false;
  }
  rendre() { this.#disponible = true; }

  // ← FUITE : ce getter rend la liste INTERNE, que l'appelant peut vider.
  getEmprunteurs() { return this.#emprunteurs; }
}

// ── À VOUS ────────────────────────────────────────────────────────────────
// 1. Cassez l'invariant de LivreOuvert en DEUX lignes, sans appeler emprunter.
// 2. Écrivez emprunter() dans Livre, et vérifiez que la même attaque échoue.
// 3. Réparez la fuite de getEmprunteurs, de deux façons : copie défensive,
//    puis exposition d'une valeur immuable.
// 4. Écrivez la même opération « emprunter si disponible » chez l'appelant,
//    puis dans l'objet. Que se passe-t-il quand la règle change ?

const a = new LivreOuvert("Dune");
console.log("   " + a.toString() + "   invariant :", a.invariantOk());

Ce que la suite en fait

Le modèle en couches est le squelette du cours. Les huit chapitres qui suivent le remplissent de bas en haut, et vous pourrez à chaque instant situer où vous êtes dans la pile.

On commence par le bas, au plus près du matériel. Le chapitre 3 traite la couche physique — comment des bits deviennent un signal sur un support — et le chapitre 4 la couche liaison — comment deux machines d'un même réseau local se parlent, avec Ethernet, les adresses MAC et le commutateur. Gardez le tableau TCP/IP sous les yeux : c'est votre carte.

À retenir