Modèle en couches¶

Pourquoi on empile des abstractions — et ou elles craquent en production.

Pourquoi des couches¶

Un réseau est un système d'une complexité énorme. Entre le signal électrique qui traverse un cable et la page web qui s'affiche dans un navigateur, des dizaines de mécanismes cooperent. Sans organisation, cette complexité serait ingeerable.

Le modèle en couches découpé le problème en niveaux d'abstraction. Chaque couche fournit un service à la couche supérieure et utilise les services de la couche inférieure. L'idée est simple mais puissante : on peut changer l'implémentation d'une couche sans affecter les autres, tant que l'interface est respectee. On remplacé Ethernet par Wi-Fi sans toucher a TCP. On remplacé TCP par QUIC sans toucher a HTTP (en théorie).

Ce principe d'abstraction est exactement le même que celui qui structure les logiciels : séparation des preoccupations, encapsulation, contrat d'interface. Tanenbaum (Réseaux, 4e edition) en fait le fil conducteur de tout son ouvrage. Stallings (Data and Computer Communications) détaillé les implications de chaque frontiere entre couches.

Les avantages concrets du modèle en couches :

• Interchangeabilite : on remplacé une technologie physique (cuivre, fibre, Wi-Fi) sans modifier les applications
• Specialisation : les équipes réseau, système et applicative travaillent sur des couches différentes avec des outils différents
• Standardisation : les protocoles de chaque couche sont normalises independamment, ce qui permet l'interopérabilité entre constructeurs
• Depannage : on isole le problème a une couche, ce qui réduit l'espace de recherche

Le prix a payer : l'overhead de l'encapsulation (chaque couche ajoute ses en-têtes) et la rigidite du modèle (les optimisations cross-layer sont difficiles a exprimer).

Le modèle OSI¶

L'ISO a propose en 1984 le modèle OSI (Open Systems Interconnection) en sept couches. C'est un modèle de référence — un outil conceptuel — pas une implémentation. Aucun système en production n'implémenté strictement les sept couches OSI.

Les couches 5, 6 et 7 du modèle OSI sont souvent critiquees. La distinction entre présentation et session est floue en pratique. TLS opère-t-il en couche 5 ou 6 ? La réponse dépend de qui on interroge. C'est une des raisons pour lesquelles le modèle TCP/IP a gagne la bataille.

Le modèle TCP/IP¶

Le modèle TCP/IP est ne de la pratique, pas de la théorie. Il a été conçu autour des protocoles réels d'Internet, et il ne comporte que quatre couches.

La force du modèle TCP/IP : il colle à la réalité. Les protocoles existent d'abord, le modèle les organisé ensuite. La faiblesse : la couche "Accès réseau" est un fourre-tout qui melange physique et liaison, et la couche "Application" absorbe tout ce qui est au-dessus du transport.

En pratique, la plupart des architectes utilisent un modèle hybride a cinq couches — physique, liaison, réseau, transport, application — qui prend le meilleur des deux mondes.

OSI vs TCP/IP : pourquoi la distinction compte encore¶

Le debat OSI vs TCP/IP semble academique, mais il a des conséquences pratiques. Les équipements réseau sont classes par la couche a laquelle ils opèrent :

• Un switch L2 commute sur les adresses MAC
• Un switch L3 route sur les adresses IP — c'est un routeur avec des ports switch
• Un load balancer L4 distribué le trafic sur les ports TCP/UDP — il ne voit pas le contenu HTTP
• Un load balancer L7 inspecte le contenu HTTP — il peut router sur l'URL, les cookies, les en-têtes

Choisir le mauvais type d'équipement pour un besoin donne est une erreur classique. Un load balancer L4 est plus rapide et consomme moins de ressources, mais il ne peut pas faire de routage intelligent base sur le contenu. Un load balancer L7 est plus flexible mais doit terminer la connexion TLS pour inspecter le trafic — ce qui ajoute de la latence et de la charge CPU.

Encapsulation¶

L'encapsulation est le mécanisme central du modèle en couches. Quand une application envoie des données, chaque couche ajoute son propre en-tête (et parfois un trailer) autour des données reçues de la couche supérieure. Le résultat est un empilement de poupees russes.

graph TB
    A["Application<br>Donnees"] --ajoute en-tete HTTP--> B["Transport<br>En-tete TCP + Donnees"]
    B --ajoute en-tete IP--> C["Reseau<br>En-tete IP + Segment TCP"]
    C --ajoute en-tete + trailer Ethernet--> D["Liaison<br>Trame Ethernet complete"]
    D --signal electrique/optique--> E["Physique<br>Bits sur le medium"]

Chaque couche a sa propre PDU (Protocol Data Unit) :

• Application : message ou données
• Transport : segment (TCP) ou datagramme (UDP)
• Réseau : paquet
• Liaison : trame (frame)
• Physique : bits

À la reception, le processus s'inverse : chaque couche retire son en-tête et passe les données à la couche supérieure. On parle de desencapsulation.

L'overhead de l'encapsulation¶

L'encapsulation a un coût. Pour envoyer 1 octet de données applicatives sur Ethernet/IPv4/TCP :

Pour 1 octet utile, on transmet 67 octets. C'est pourquoi les protocoles applicatifs modernes (HTTP/2, gRPC) cherchent à regrouper les petits messages — le batching réduit l'overhead relatif de l'encapsulation.

Le ratio s'amélioré avec des payloads plus grands. Pour un payload de 1400 octets (proche du MTU Ethernet), l'overhead tombe a environ 4.5%. C'est la raison pour laquelle les protocoles performants cherchent à remplir les paquets au maximum — on gaspille moins de bande passante en overhead.

Multiplexage et demultiplexage¶

Chaque couche doit identifier à quel flux de la couche supérieure appartient un PDU reçu. C'est le demultiplexage, et il repose sur des identifiants dans les en-têtes :

Le multiplexage fonctionne dans l'autre sens : plusieurs flux de la couche supérieure partagent une même connexion de la couche inférieure. TCP multiplexe des connexions applicatives sur un seul lien IP. IP multiplexe des flux sur un seul lien Ethernet.

Traversee réelle d'un paquet¶

Pour ancrer le modèle dans la réalité, suivons le trajet d'une requête HTTP depuis un navigateur jusqu'à un serveur distant.

sequenceDiagram
    participant App as Application<br>(navigateur)
    participant TCP as Transport<br>(TCP)
    participant IP as Reseau<br>(IP)
    participant ETH as Liaison<br>(Ethernet)
    participant SW as Switch
    participant R as Routeur
    participant ETH2 as Liaison<br>(serveur)
    participant IP2 as Reseau<br>(serveur)
    participant TCP2 as Transport<br>(serveur)
    participant App2 as Application<br>(serveur web)

    App->>TCP: Donnees HTTP
    TCP->>IP: Segment TCP
    IP->>ETH: Paquet IP
    ETH->>SW: Trame Ethernet
    SW->>R: Trame Ethernet
    Note over R: Desencapsule L2<br>Route sur L3<br>Re-encapsule L2
    R->>ETH2: Nouvelle trame
    ETH2->>IP2: Paquet IP
    IP2->>TCP2: Segment TCP
    TCP2->>App2: Donnees HTTP

Le point essentiel : le routeur opère en couche 3. Il desencapsule la trame Ethernet, examine le paquet IP pour déterminer le prochain saut, puis re-encapsule dans une nouvelle trame. L'adresse MAC change à chaque saut, mais les adresses IP source et destination restent les mêmes de bout en bout.

Le switch, lui, opère en couche 2 : il lit l'adresse MAC destination et transmet la trame vers le bon port. Il ne touche pas au paquet IP.

Ce que voit chaque équipement¶

Un point souvent mal compris : chaque équipement sur le chemin ne "voit" que les couches qui le concernent.

Cette hiérarchie explique pourquoi un switch ne peut pas filtrer par adresse IP (il ne voit pas la couche 3) et pourquoi un routeur ne peut pas inspecter le contenu HTTP (il ne voit pas la couche 7 — sauf s'il fait du DPI, Deep Packet Inspection).

Les outils de diagnostic par couche¶

Chaque couche a ses propres outils de diagnostic. Connaître le bon outil pour la bonne couche permet de localiser un problème rapidement au lieu de tatoner.

La démarche de diagnostic suit généralement un parcours bottom-up :

1. Le lien physique est-il actif ? (ethtool eth0)
2. L'adresse MAC du gateway est-elle dans la table ARP ? (arp -a)
3. Le ping vers le gateway fonctionne-t-il ? (ping 10.0.0.1)
4. Le ping vers la destination fonctionne-t-il ? (ping 93.184.216.34)
5. Le port TCP est-il ouvert ? (telnet 93.184.216.34 443)
6. La requête applicative fonctionne-t-elle ? (curl -v https://example.com)

Si le problème apparait à l'étape 3, c'est un problème couche 3. Si les étapes 1 a 5 fonctionnent mais l'étape 6 échoué, c'est un problème couche 7 (certificat, configuration applicative, etc.).

Ou le modèle en couches casse¶

Le modèle en couches est une abstraction, et comme toute abstraction, elle fuit. Joel Spolsky appelle cela les "leaky abstractions" — les détails de la couche inférieure percent inevitablement vers la couche supérieure.

La performance traverse les couches¶

TCP garantit la livraison fiable des données. Mais il ne peut pas masquer la latence du réseau physique. Une application qui fait 100 appels TCP séquentiels sur un lien a 50 ms de RTT paiera 5 secondes de latence — et le modèle en couches ne fournit aucun mécanisme pour l'éviter. L'application doit connaître la réalité de la couche 1.

La sécurité traverse les couches¶

Un firewall couche 4 (filtrage par port TCP) ne protégé pas contre les attaques applicatives (injection SQL). Un WAF couche 7 ne protégé pas contre un ARP spoofing couche 2. La sécurité doit être pensee à chaque couche, pas delee a une seule.

Le debug traverse les couches¶

Quand une requête HTTP échoué, le problème peut venir de n'importe quelle couche : certificat TLS expire (couche 5-6), timeout TCP (couche 4), table de routage incorrecte (couche 3), cable debranche (couche 1). Un bon troubleshooter remonte methodiquement les couches.

Le modèle en couches comme outil de l'architecte¶

Pour l'architecte logiciel, le modèle en couches n'est pas un savoir academique — c'est un outil de diagnostic et de conception.

Diagnostic : face à un problème de performance ou de fiabilité, identifier la couche responsable est la première étape. "C'est un problème couche 3" (routage) ne se résout pas avec les mêmes outils que "c'est un problème couche 7" (application).

Conception : le choix du protocole de transport (TCP vs UDP vs QUIC) dépend de ce que la couche application exige — fiabilité, ordre, latence. Comprendre les compromis de chaque couche permet de faire des choix eclaires plutôt que de subir les défauts.

Communication : le vocabulaire des couches est le langage commun entre développeurs, ops, et ingénieurs réseau. Un architecte qui parle de "segments", "paquets" et "trames" avec précision est un architecte avec qui l'équipe infra aime travailler.

Choix d'abstraction : le modèle en couches rappelle que chaque abstraction a un coût. Un service mesh (Istio) ajoute une couche de proxy entre chaque appel — c'est une couche supplémentaire avec son overhead de latence, ses bugs, et sa complexité opérationnelle. Un overlay network (VXLAN) encapsule les trames Ethernet dans des paquets UDP — c'est une couche supplémentaire qui réduit le MTU effectif et ajoute du traitement. Chaque couche ajoutee doit justifier sa valeur.

Le modèle en couches est imparfait. Il ne capture pas les interactions cross-layer qui dominent la performance réelle. Mais il reste le meilleur outil d'organisation mentale pour un domaine d'une complexité redoutable.

Chapitre suivant : Couche liaison et commutation — Ethernet, adresses MAC, switches et VLANs.