Le modèle OSI, couche par couche, sans le superflu

La plupart des explications sur les réseaux traitent le modèle OSI comme un diagramme à mémoriser pour un examen de certification, puis à oublier. C'est une erreur. Dès que vous commencez à dépanner des problèmes réels, les sept couches deviennent une liste de contrôle mentale : s'agit-il d'un problème de câble, d'un problème de routage ou d'un bug applicatif ? Savoir à quelle couche vous avez affaire réduit considérablement votre temps de débogage.

Couche 1 : physical

C'est le support physique lui-même : cuivre, fibre optique, ondes radio. Les niveaux de tension, les connexions de broches, les types de connecteurs (RJ45, SFP+) et la modulation des signaux y vivent. Quand un port de commutateur affiche « link down » ou que vous avez des pertes de paquets intermittentes qui coïncident avec quelqu'un qui passe l'aspirateur près d'une ligne de câbles, vous êtes en territoire de couche 1. Des outils comme un testeur de câbles ou ethtool eth0 sur Linux vous montreront l'état de la liaison, la vitesse et les paramètres de duplex avant que vous ne perdiez du temps à déboguer quelque chose d'un niveau supérieur.

Couche 2 : data link

Ici vous trouvez les adresses MAC, les commutateurs et les trames. Ethernet opère à cette couche, tout comme ARP (techniquement un pont entre L2 et L3). Les VLAN sont aussi une construction de couche 2. Si un hôte ne peut rien atteindre sur son propre sous-réseau mais que les pings fonctionnent bien vers d'autres machines directement connectées, vérifiez arp -a ou ip neigh pour les entrées obsolètes, et examinez les configurations des ports du commutateur pour les incompatibilités de VLAN. Un piège classique : deux hôtes sur le même VLAN mais avec des paramètres MTU différents causant des symptômes étranges liés à la fragmentation.

Couche 3 : network

Les adresses IP, le routage et ICMP vivent ici. C'est là que traceroute et ping font leur travail, et où vous diagnostiquez si un paquet sort même du réseau local. Les routeurs prennent des décisions d'acheminement basées sur l'adresse IP de destination à cette couche. Quand ping 8.8.8.8 fonctionne mais que ping google.com ne fonctionne pas, ce n'est pas un problème de couche 3 du tout, c'est DNS, qui est couche 7 — un bon exemple de pourquoi la discipline de couche importe quand vous réduisez une panne.

Couche 4 : transport

TCP et UDP. C'est là que les ports, la séquençage et la fiabilité (ou son absence) entrent en jeu. La poignée de main en trois étapes de TCP, les minuteurs de retransmission et la mise à l'échelle de la fenêtre sont tous ici. Si curl s'arrête sur une tentative de connexion, tcpdump -i eth0 port 443 vous montrera si les paquets SYN reçoivent même un SYN-ACK en retour. Aucune réponse signifie généralement qu'un pare-feu abandonne silencieusement le trafic plutôt que de le rejeter franchement — une distinction qui importe quand vous rédigez le rapport d'incident.

Couche 5 : session

Cette couche a mauvaise réputation parce qu'elle est mince en pratique — beaucoup de piles réelles fusionnent la gestion des sessions dans la couche transport ou la couche application. La reprise de session TLS et des choses comme les sessions NetBIOS sont les exemples classiques des manuels. Dans l'architecture moderne, vous passerez moins de temps ici que sur n'importe quelle autre couche, mais c'est toujours utile conceptuellement pour expliquer pourquoi une connexion perdue peut reprendre sans une renégociation complète.

Couche 6 : presentation

L'encodage, la compression et le formatage du chiffrement techniquement appartiennent ici — pensez aux jeux de caractères, au formatage du chiffrement SSL/TLS (par opposition à l'établissement de session lui-même) et à la sérialisation des données. En pratique, la plupart des ingénieurs fusionnent ceci dans la couche 5 ou la couche 7 quand ils en parlent, parce que la frontière est floue. Si vous déboguez des caractères brouillés dans une charge utile par rapport à une poignée de main cassée, c'est votre séparation L6/L7.

Couche 7 : application

HTTP, DNS, SMTP, SSH — les protocoles sur lesquels vous écrivez réellement du code. La plupart du débogage quotidien en tant que développeur se fait ici, en vérifiant les codes de statut, les en-têtes et les charges utiles. Les outils de développement du navigateur, Postman et curl -v opèrent tous à cette couche. Il est tentant de blâmer le réseau en premier quand un appel API échoue, mais une réponse 500 signifie que la demande a traversé chaque couche inférieure correctement — le problème est entièrement dans la logique applicative.

Pourquoi se donner la peine avec un modèle que personne n'implémente exactement

Les réseaux réels, surtout TCP/IP, ne mappent pas parfaitement sur les sept couches d'OSI — TCP/IP a quatre couches dans son propre modèle de référence. Ce décalage n'est pas un problème. La valeur d'OSI n'est pas comme une spécification d'implémentation, c'est comme un vocabulaire partagé. Quand un collègue dit « cela ressemble à un problème de couche 2 », vous savez tous les deux immédiatement de vérifier les commutateurs et les VLAN au lieu de débattre sur les enregistrements DNS. C'est tout le sens d'apprendre cela correctement au lieu de la mémoriser pour un test.

Si ce type de présentation couche par couche vous a intéressé, les segments réseau de Korra Studio vont plus loin dans les captures de paquets, les exercices de sous-réseautage et le dépannage des règles de pare-feu qui s'appuient directement sur cette base.