Comprendre vraiment le modèle OSI — disséquer une requête HTTP en ses sept couches

Le modèle OSI est la première chose qu’aborde tout ouvrage d’introduction aux réseaux, et pourtant on entend souvent la même remarque : « je sais réciter le nom des sept couches, mais honnêtement, je n’en ai pas une image concrète ». On mémorise couche physique, couche liaison de données, couche réseau, etc., mais on ne parvient jamais vraiment à relier ce schéma à sept étages au code C# que l’on écrit, ni à la panne de communication que l’on a sous les yeux.

Sur ce blog, nous avons déjà traité du comportement de L4 (la couche transport) — avec l’idée reçue selon laquelle on peut Receive dans les mêmes unités qu’on a Send sur TCP et le diagnostic des interruptions de communication d’une caméra industrielle causées par la retransmission TCP — mais nous n’avions encore jamais écrit d’article rassemblant l’idée sous-jacente de « couche » en elle-même.

L’approche de cet article est simple. Nous construisons une véritable trame Ethernet transportant une seule requête HTTP GET, et nous la disséquons de l’extérieur vers l’intérieur. Les sept couches ne relèvent pas seulement d’un schéma conceptuel : elles existent physiquement, imbriquées dans les 171 octets qui circulent sur le réseau. Une fois que vous l’aurez vu de vos propres yeux, par un dump hexadécimal et par Wireshark, le modèle OSI cessera d’être un objet à mémoriser.

Le code présenté dans cet article est publié sur GitHub sous la forme d’un ensemble d’exemples complet, compilable et exécutable (une bibliothèque d’assemblage et de dissection de trames, l’export d’un fichier pcap ouvrable dans Wireshark, et des tests unitaires).

osi-model-packet-anatomy - komurasoft-blog-samples (GitHub)

1. L’essentiel pour commencer

• Le modèle OSI est un « vocabulaire », pas une « implémentation ». Ce qui fonctionne réellement sur Internet est la suite de protocoles TCP/IP (quatre couches en pratique) ; les protocoles OSI à sept couches proprement dits ont perdu la course à l’adoption et ne sont pas utilisés. Ce qui a survécu, c’est le modèle en tant que langage commun — des expressions comme « isolons ça au niveau L2 » ou « c’est un problème de niveau L7 ».¹²
• Les sept couches sont physiquement imbriquées dans une séquence d’octets. Dans une trame transportant un GET HTTP, les 14 premiers octets forment l’en-tête Ethernet (L2), les 20 octets suivants l’en-tête IPv4 (L3), les 20 octets suivants l’en-tête TCP (L4), et le reste est le texte HTTP (L7). Vous pouvez vérifier directement, dans le dump hexadécimal de cet article et dans Wireshark, comment l’en-tête de chaque couche commence juste après celui de la couche précédente.
• Tout ce que votre code C# écrit directement, c’est la séquence d’octets de L7. Ce que vous passez à Socket.Send n’est que la donnée applicative ; la pile de protocoles de l’OS ajoute les en-têtes TCP et IP, et la carte réseau (NIC) ajoute l’en-tête Ethernet et le signal électrique. C’est précisément pour cela que choisir entre HttpClient, SslStream et Socket revient à choisir « à partir de quelle couche on délègue le travail à l’OS ».³
• L5 (la couche session) et L6 (la couche présentation) n’existent pas comme des couches indépendantes dans la pile réelle. TLS et l’encodage des caractères assument une partie de ce rôle, mais dans le modèle TCP/IP, tout cela est regroupé dans la couche application. Si vous ne voyez pas ce que L6 est censée représenter, ce n’est pas de votre faute : c’est précisément l’endroit où le modèle et la réalité divergent.²
• Là où le modèle OSI rend vraiment service en pratique, c’est pour le dépannage et la conversation. Circonscrire un problème avec le vocabulaire des couches — « le ping passe mais HTTP échoue, donc L3 est vivant et il faut soupçonner L4 ou au-dessus » — devient un langage commun compris aussi bien par les équipes réseau, les équipes infrastructure que les développeurs d’applications.

2. Pourquoi le modèle OSI se réduit-il au par cœur ?

La plupart des explications commencent par un tableau de ce genre.

Ce tableau est juste, mais chaque ligne est rédigée dans des termes si abstraits que la lecture ne fait naître aucune image mentale. Dites à quelqu’un « ça transforme le format de représentation des données », et personne ne saura pointer la ligne de son propre code à laquelle cela correspond.

Il y a aussi un autre fait historique qu’il faut énoncer franchement. Le modèle OSI est une norme définie par l’ISO (Organisation internationale de normalisation) et l’ITU-T (ISO/IEC 7498-1, ITU-T X.200), et il devait à l’origine s’accompagner d’un ensemble ambitieux de protocoles OSI correspondant à chacune des sept couches.¹ Mais dans la course à l’adoption des années 1990, TCP/IP — qui disposait déjà d’implémentations fonctionnelles — est devenu la norme de fait, et les protocoles OSI eux-mêmes ont fini par n’être quasiment jamais utilisés. La RFC 1122, qui a posé les fondations d’Internet, décrit le monde en quatre couches en pratique — couche liaison, couche internet (IP), couche transport et couche application — sans couche indépendante correspondant à L5 ou L6.²

Autrement dit, si nous étudions encore le modèle OSI aujourd’hui, ce n’est pas « parce que c’est ainsi que les choses sont implémentées », mais pour nous approprier l’outil que constitue le raisonnement en couches, ainsi qu’un vocabulaire commun pour le dépannage. Une fois ce postulat admis, il n’est plus nécessaire de se tourmenter à chercher « où sont concrètement L5 et L6 », et tout devient soudain beaucoup plus clair.

3. Le cœur du sujet : disséquer une requête HTTP

Trêve de préambule, passons à la chose réelle. Le dump hexadécimal suivant est une trame Ethernet (171 octets au total) transportant une seule requête HTTP, GET /index.html HTTP/1.1. Elle a été assemblée par le code d’exemple présenté au début de cet article, et comme le checksum de l’en-tête IPv4 et celui de TCP sont tous deux calculés correctement, Wireshark l’affiche comme un paquet parfaitement normal lorsqu’on la charge.

0000  02 00 00 00 00 01 02 00  00 00 00 02 08 00 45 00  ..............E.
0010  00 9d 12 34 40 00 40 06  3b 99 c0 00 02 0a c6 33  ...4@.@.;......3
0020  64 50 cb 84 00 50 00 00  03 e8 00 00 07 d0 50 18  dP...P........P.
0030  ff ff a3 05 00 00 47 45  54 20 2f 69 6e 64 65 78  ......GET /index
0040  2e 68 74 6d 6c 20 48 54  54 50 2f 31 2e 31 0d 0a  .html HTTP/1.1..
0050  48 6f 73 74 3a 20 65 78  61 6d 70 6c 65 2e 63 6f  Host: example.co
0060  6d 0d 0a 55 73 65 72 2d  41 67 65 6e 74 3a 20 4b  m..User-Agent: K
0070  6f 6d 75 72 61 53 6f 66  74 44 65 6d 6f 2f 31 2e  omuraSoftDemo/1.
0080  30 0d 0a 41 63 63 65 70  74 3a 20 74 65 78 74 2f  0..Accept: text/
0090  68 74 6d 6c 0d 0a 43 6f  6e 6e 65 63 74 69 6f 6e  html..Connection
00a0  3a 20 63 6c 6f 73 65 0d  0a 0d 0a                 : close....

En observant la colonne ASCII à droite, on voit apparaître, à partir du décalage (offset) 0x36, un texte lisible par un humain : GET /index.html HTTP/1.1. Alors, que sont les 54 octets qui précèdent ? Si on les soumet au dissecteur de l’exemple, voici ce qu’il rapporte.

[ L2 Ethernet II | offset   0 |  14 bytes | dst=02:00:00:00:00:01 src=02:00:00:00:00:02 type=0x0800 (IPv4)
  [ L3 IPv4        | offset  14 |  20 bytes | 192.0.2.10 -> 198.51.100.80 TTL=64 proto=6 (TCP) checksum=OK
    [ L4 TCP         | offset  34 |  20 bytes | 52100 -> 80 [Psh, Ack] seq=1000 win=65535
      [ L7 HTTP        | offset  54 | 117 bytes | GET /index.html HTTP/1.1

C’est le schéma que je souhaite le plus vous voir retenir de cet article. Il y a trois points à en tirer.

1. Chaque couche commence juste là où la précédente s’arrête. L’en-tête Ethernet occupe les octets 0 à 13, l’en-tête IPv4 les octets 14 à 33, l’en-tête TCP les octets 34 à 53, et HTTP commence à l’octet 54. Une couche n’est pas une catégorie conceptuelle : on peut la désigner comme une plage d’octets à partir du début de la trame.
2. Une couche intérieure n’est rien de plus que la « charge utile » (le fret) de la couche extérieure. Du point de vue d’Ethernet, tout ce qui vient après — IPv4 et la suite — n’est que du fret, sans que la couche se soucie de savoir si le contenu est du TCP. Du point de vue d’IP, TCP et la suite constituent le fret ; du point de vue de TCP, c’est HTTP. Chaque couche ne lit que son propre en-tête et transmet la charge utile vers le haut sans y toucher. Cette structure d’« indifférence » est précisément ce qu’on appelle l’encapsulation.
3. L1 (la couche physique) ainsi que L5 et L6 n’apparaissent nulle part dans ce schéma. Le travail de L1 consiste à convertir cette séquence d’octets en signal électrique, en lumière ou en ondes radio, elle ne se voit donc jamais dans un dump ; quant à L5 et L6, comme vu au chapitre précédent, elles n’ont aucune existence indépendante dans du HTTP/1.1 en clair. « Sur sept couches, seules quatre apparaissent dans le dump » — voilà la réalité.

Répétons-le : il n’y a rien de spécial à HTTP ici. Qu’il s’agisse d’une connexion à une base de données, de gRPC, ou de GigE Vision pour une caméra industrielle, tous les paquets présentent exactement cette même structure imbriquée, dès lors qu’il s’agit de TCP/IP sur Ethernet. Seul le contenu du fret de L7 change.

4. L2, la couche liaison de données — livrer au « voisin »

Parcourons les résultats de la dissection de l’extérieur vers l’intérieur. Les 14 premiers octets constituent l’en-tête Ethernet II.

02 00 00 00 00 01   Adresse MAC de destination (6 octets)
02 00 00 00 00 02   Adresse MAC source (6 octets)
08 00               EtherType = 0x0800 (le fret est de l'IPv4)

Le travail de L2 consiste à « livrer au nœud voisin au sein du même segment réseau ». Il utilise une adresse MAC pour désigner la destination. Une adresse MAC est un identifiant attribué à une carte réseau (NIC), et en principe, elle n’atteint jamais son destinataire au-delà d’un routeur. Une trame envoyée d’un PC de bureau vers un serveur web a pour adresse MAC de destination, non pas le serveur web, mais la passerelle par défaut (le routeur).

C’est ici que beaucoup se demandent, au moins une fois, « puisqu’il y a déjà une adresse IP, pourquoi a-t-on aussi besoin d’une adresse MAC ? ». La réponse tient à la répartition des responsabilités entre couches. L’adresse IP est l’adresse qui désigne la « destination finale », tandis que l’adresse MAC est l’étiquette qui désigne « celui qui transporte le prochain tronçon ». Pour reprendre une image de livraison par transporteur, l’adresse IP correspond à l’adresse de livraison figurant sur le bordereau, et l’adresse MAC au nom du « prochain centre de tri ». Le bordereau (L3) ne change pas jusqu’à la fin, mais l’étiquette (L2) est remplacée à chaque tronçon. ARP est ce qui permet de retrouver l’adresse MAC d’un nœud voisin à partir d’une adresse IP, et la commande arp -a permet de consulter la table de correspondance que le PC a mémorisée.

Côté matériel, l’équipement qui lit L2 pour transférer les trames est le commutateur (switch, ou hub commuté). Un commutateur choisit son port de sortie en ne regardant que l’adresse MAC de destination ; il ne regarde jamais l’adresse IP transportée en tant que fret.

5. L3, la couche réseau — livrer jusqu’au bout du monde

Les 20 octets suivants constituent l’en-tête IPv4. Voici les principaux champs.

45          Version = 4, longueur d'en-tête = 5 mots (20 octets)
00 9d       Longueur totale : 157 octets (en-tête IP + TCP + HTTP ; n'inclut pas les 14 octets d'Ethernet)
40 06       TTL = 64, protocole = 6 (le fret est du TCP)
3b 99       Checksum de l'en-tête
c0 00 02 0a IP source        192.0.2.10
c6 33 64 50 IP de destination  198.51.100.80

Le travail de L3 consiste à « livrer jusqu’à l’hôte de destination finale, quel que soit le nombre de routeurs à traverser ». Alors que L2 ne transporte que sur un seul tronçon (un seul saut), l’adresse IP de destination de L3 reste inchangée du tout début à la toute fin de la communication. Un routeur regarde l’IP de destination du paquet qu’il reçoit, décide à quel routeur le transmettre ensuite, et le renvoie après avoir remplacé l’en-tête L2.

Le TTL (Time To Live) est le champ qui rend visible ce mouvement de « franchissement de routeurs ». Il diminue de 1 à chaque routeur traversé, et lorsqu’il atteint 0, le paquet est abandonné et une erreur est renvoyée à l’expéditeur. tracert (la commande Windows de traçage de route) fonctionne en envoyant délibérément des paquets avec un TTL fixé successivement à 1, 2, 3, etc., ce qui fait apparaître un à un les routeurs situés sur le chemin. Autrement dit, chaque ligne affichée par tracert est la manifestation concrète d’un « saut L3 ».

6. L4, la couche transport — décider quel processus reçoit les données

Les 20 octets suivants constituent l’en-tête TCP.

cb 84       Port source 52100
00 50       Port de destination 80
00 00 03 e8 Numéro de séquence
00 00 07 d0 Numéro d'accusé de réception
50 18       Longueur d'en-tête = 5 mots, drapeaux [PSH, ACK]
ff ff       Taille de fenêtre
a3 05       Checksum

Une fois L3 franchi, le paquet est arrivé à l’« hôte (la machine) » de destination. Mais sur cette machine, un serveur web, une base de données et bien d’autres processus communiquent simultanément. L’un des travaux de L4 est d’utiliser le numéro de port pour décider à quel processus (à quelle socket) remettre les données. Le port de destination 80 est, par convention, « le numéro sur lequel écoute un serveur HTTP » ; l’OS regarde ce numéro et empile les données dans le tampon de réception du processus correspondant.

L’autre grande mission de TCP est de fournir un flux d’octets fiable grâce aux numéros de séquence, aux accusés de réception, à la retransmission et au contrôle de flux.⁴ Ce comportement, et la manière de le gérer, sont chacun suffisamment riches pour mériter leur propre article ; je vous renvoie donc à l’article sur les limites de message en TCP et à l’article sur la retransmission TCP. Ce qu’il faut retenir ici, c’est cette sensation : « au-dessus de L4, les choses ne ressemblent plus du tout à un réseau — elles ressemblent à un tuyau reliant directement un processus à un autre ».

Voici un fait amusant qui illustre l’écart entre l’idéal du modèle et la réalité. Le checksum TCP n’est pas défini comme étant calculé sur le seul segment TCP : il est défini comme étant calculé avec un « pseudo-en-tête » regroupant des informations de L3 (les adresses IP source et destination), placé en tête du calcul.⁴ Si les couches étaient proprement indépendantes, il n’y aurait aucune raison que les adresses de L3 viennent se mêler au calcul de L4. C’est un bon exemple montrant que le modèle OSI n’est jamais qu’une carte pour organiser la pensée, tandis que les protocoles réels franchissent les frontières entre couches dès que c’est utile.

7. L5 et L6 — là où le modèle et la réalité divergent

Or, notre schéma de dissection ne comportait ni L5 (la couche session) ni L6 (la couche présentation). C’est la première cause de ce sentiment de « ne pas comprendre OSI », alors disons-le clairement.

L5 et L6 n’existent pas comme des couches indépendantes dans la pile TCP/IP réelle. Dans le modèle Internet de la RFC 1122, tout ce qui se trouve au-dessus de TCP est simplement la « couche application ».² Les rôles envisagés par le modèle OSI sont, dans la réalité, dispersés et absorbés comme suit.

Dans le cas de HTTPS, par exemple, TLS s’intercale au-dessus de TCP (L4), et HTTP circule à l’intérieur. « De quelle couche relève TLS ? » est une question qui donne envie d’en faire un sujet d’examen, mais il n’y a aucun intérêt pratique à trancher pour une seule bonne réponse. Savoir expliquer que TLS se situe au-dessus de L4, en dessous de L7, et qu’il combine à la fois la gestion de session (un rôle de type L5) et le chiffrement (un rôle de type L6), compte davantage que de pouvoir répondre du tac au tac « c’est L6 ».

Dans le code .NET, cette relation se retrouve directement dans la manière dont les classes s’enveloppent les unes les autres. Si vous enveloppez avec SslStream le flux de L4 obtenu via TcpClient.GetStream(), le texte en clair que vous écrivez avec Write est chiffré en enregistrements TLS avant même d’atteindre TCP.⁵

using var client = new TcpClient("example.com", 443);
// Enveloppe le flux d'octets de L4 avec TLS (approximativement L5/L6)
using var ssl = new SslStream(client.GetStream());
await ssl.AuthenticateAsClientAsync("example.com");
// Ce qu'on écrit ici, c'est du texte en clair L7 (HTTP). Le chiffrement est le travail de SslStream
await ssl.WriteAsync(Encoding.ASCII.GetBytes("GET / HTTP/1.1\r\n..."));

Cette structure d’un flux enveloppant un autre flux est l’équivalent, en code, de l’encapsulation. Si vous observez dans Wireshark le trafic sur le port 443, la charge utile TCP n’apparaît plus que comme un bloc opaque étiqueté Application Data, ce qui permet de confirmer, dans l’autre sens, que « L7 a bien été enveloppé dans quelque chose d’équivalent à L6 ».

8. Quelle couche votre code C# touche-t-il réellement ?

Faisons maintenant correspondre tout cela avec les outils qu’utilise un développeur d’applications Windows.

Deux choses ressortent de ce tableau.

Premièrement, choisir une API, c’est choisir « à partir de quelle couche on délègue le travail ». Avec HttpClient, vous pouvez déléguer jusqu’à l’assemblage de L7 ; avec Socket, vous devez écrire vous-même la totalité de L7. À l’inverse, une application Windows ordinaire ne manipule presque jamais directement L3 ou en dessous (les sockets brutes (raw sockets) exigent des privilèges administrateur et de fortes restrictions).

Deuxièmement, ce qu’on passe à Socket.Send, c’est la séquence d’octets de L7 et rien d’autre. La Part 2 de l’exemple est une démonstration qui envoie réellement une requête HTTP en boucle locale (loopback), mais tout ce que l’application prépare, ce sont les 60 octets de texte HTTP ; les en-têtes représentant les 54 octets vus au chapitre 3 sont ajoutés par l’OS et la carte réseau. Le code réseau de votre application ne fait en réalité que fabriquer le fret le plus intérieur des sept couches — voilà la relation exacte entre le modèle OSI et votre code.

using var socket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
await socket.ConnectAsync(IPAddress.Loopback, port);

byte[] request = Encoding.ASCII.GetBytes(
    $"GET / HTTP/1.1\r\nHost: localhost:{port}\r\nConnection: close\r\n\r\n");

// On ne passe que la séquence d'octets de L7. Les en-têtes TCP/IP/Ethernet
// sont ajoutés de l'autre côté de cet appel (par l'OS et la carte réseau)
int sent = await socket.SendAsync(request);

9. Passer à la pratique — assembler une trame et l’ouvrir dans Wireshark

Pour transformer un « j’ai compris en lisant » en « j’ai compris en voyant », voyons comment faire fonctionner le code d’exemple.

Au cœur de l’exemple se trouve SampleFrameBuilder, qui assemble la trame du chapitre 3 exactement dans l’ordre où elle est enveloppée, de L7 vers L2. Ce qui se passe à chaque couche au moment de l’envoi correspond directement à l’ordre dans lequel apparaissent les méthodes.

public static byte[] BuildHttpGetFrame()
{
    // L7 : la seule chose que l'application passe à Send, c'est cette séquence d'octets
    byte[] http = Encoding.ASCII.GetBytes(HttpRequest);

    // L4 : la pile de protocoles de l'OS ajoute l'en-tête TCP en préfixe
    byte[] tcp = WrapInTcp(http);

    // L3 : on ajoute ensuite l'en-tête IPv4 en préfixe
    byte[] ip = WrapInIpv4(tcp);

    // L2 : le pilote de la carte réseau ajoute l'en-tête Ethernet en préfixe juste avant l'envoi
    return WrapInEthernet(ip);
}

L’exécution de la démo affiche le dump hexadécimal et la vue imbriquée, et écrit en plus cette trame sous forme de fichier pcap.

dotnet run --project samples/Demo

Essayez d’ouvrir le fichier sample-http-get.pcap généré avec Wireshark.⁶ Le panneau central affiche quatre lignes empilées — Ethernet II / Internet Protocol Version 4 / Transmission Control Protocol / Hypertext Transfer Protocol — et cliquer sur l’une d’elles met en surbrillance uniquement la plage d’octets correspondante dans le dump hexadécimal ci-dessous. Un outil standard du secteur vous montre exactement la même chose que la vue imbriquée du chapitre 3. Une fois cela vérifié, passons au trafic réel : lancez une capture dans Wireshark, réglez le filtre sur quelque chose comme tcp.port == 443, ouvrez un site quelconque dans votre navigateur, et vous pourrez confirmer que toute communication réelle est construite selon cette même imbrication.

Notez également que l’implémentation du côté du dissecteur (PacketDissector) recèle elle aussi un enseignement pratique. Par exemple, lorsqu’on extrait le fret d’IPv4, il faut s’appuyer sur le champ TotalLength de l’en-tête plutôt que de prendre tout le reste du tampon de réception, car Ethernet impose une longueur de trame minimale (60 octets) et les paquets courts se voient ajouter en fin de trame un bourrage (padding) dénué de sens. « Éliminer une contrainte propre à la couche extérieure (le bourrage) grâce à l’information de longueur de la couche intérieure » — c’est là encore un exemple de la façon dont la répartition des rôles entre couches se manifeste dans l’implémentation, et cela est vérifié par un test unitaire.

10. Utiliser le modèle OSI en pratique — circonscrire un problème avec le vocabulaire des couches

Au début de cet article, j’ai écrit qu’OSI avait survécu en tant que vocabulaire. Voyons deux situations où ce vocabulaire rend réellement service.

Le dépannage. Un signalement du type « impossible de se connecter au serveur » peut être circonscrit de façon systématique une fois traduit dans le vocabulaire des couches. L’approche classique consiste à vérifier de bas en haut.

Par exemple, si « le ping passe mais Test-NetConnection échoue », tout ce qui va jusqu’à L3 est sain, et les soupçons se portent sur quelque chose qui bloque le port au niveau L4 (un service arrêté, un pare-feu, une erreur de configuration du numéro de port). Si « la connexion TCP réussit mais HTTP renvoie un 400 », le problème n’est pas réseau mais relève de L7 (le contenu de la requête). Plutôt que de débrancher et rebrancher des câbles au hasard, déterminer, couche par couche, jusqu’où les choses sont encore vivantes — voilà comment le modèle OSI s’utilise en pratique.

Un langage commun pour la conversation. Des échanges comme « ça ressemble à un problème de niveau L2, peux-tu regarder le port du switch » ou « ça, c’est du L7, donc c’est pour l’équipe applicative » se comprennent précisément entre les équipes réseau, infrastructure et les développeurs d’applications. Le numéro de couche est un système de coordonnées partagé à l’échelle du secteur pour énoncer brièvement un point de responsabilité.

11. Corriger les idées reçues courantes

Pour finir, reprenons et corrigeons les idées reçues que l’on rencontre couramment autour du modèle OSI.

• « Internet fonctionne sur les sept couches d’OSI » — Non, ce n’est pas le cas. Ce qui est implémenté, c’est TCP/IP (quatre couches en pratique) ; OSI est un modèle de référence destiné à l’explication et à la conversation.²
• « Les quatre couches de TCP/IP correspondent proprement aux sept couches d’OSI » — La correspondance de L5 à L7 est intrinsèquement floue. On voit souvent un tableau affirmant « couche application de TCP/IP = L5 + L6 + L7 d’OSI », mais comme vu au chapitre 7, les rôles de L5 et L6 sont, dans la réalité, dispersés entre TLS et les formats de sérialisation.
• « TLS est un protocole de la couche 6 (ou de la couche 5) » — Il n’y a aucun intérêt à le figer sur une seule couche. La description exacte est qu’il se situe au-dessus de L4, en dessous de L7, et qu’il combine des rôles équivalents à L5 et L6.
• « Le numéro de port suffit à identifier le protocole » — Le port 80 ne garantit pas qu’il s’agit de HTTP. Le numéro de port n’est qu’une convention ; on ne sait réellement ce qui circule qu’en regardant la charge utile. C’est précisément pour cette raison que le dissecteur de l’exemple identifie HTTP en examinant les premiers caractères du contenu, et non le numéro de port.
• « Les commutateurs sont des équipements L2, les routeurs des équipements L3 » — C’est juste comme point de départ, mais en réalité, il existe couramment des équipements qui chevauchent plusieurs couches : commutateurs L3, répartiteurs de charge qui aiguillent au niveau L4, WAF qui inspectent L7. Il est plus exact de raisonner en termes de « jusqu’à quelle couche cet équipement lit-il ».

12. Résumé

• Le modèle OSI n’est pas une implémentation, mais un vocabulaire pour penser en couches. Ce qui fonctionne réellement est TCP/IP (quatre couches en pratique)
• Les sept couches ne sont pas un schéma conceptuel : elles sont physiquement imbriquées dans la séquence d’octets d’une seule trame (L2 : 0-13, L3 : 14-33, L4 : 34-53, L7 : à partir de 54)
• Chaque couche ne lit que son propre en-tête et ne se préoccupe pas du fret (les couches intérieures) — c’est l’encapsulation
• L5 et L6 n’existent pas indépendamment dans la pile réelle ; TLS et l’encodage en ont absorbé les rôles
• Votre code C# n’écrit que la séquence d’octets de L7. Les en-têtes TCP/IP sont ajoutés par l’OS, et Ethernet par la carte réseau
• Son usage pratique consiste à dépanner en confirmant la survie couche par couche à partir du bas, et à servir de langage commun entre équipes
• En assemblant une trame avec le code d’exemple et en l’ouvrant dans Wireshark, vous pouvez vérifier de vos propres yeux tout le contenu de cet article

Articles connexes

• L’idée reçue selon laquelle on peut Receive dans les mêmes unités qu’on a Send sur TCP — concevoir la réception autour d’un flux d’octets
• Diagnostiquer les interruptions de communication d’une caméra industrielle causées par la retransmission TCP
• Tableau de décision pratique C# async/await - Task.Run et ConfigureAwait

Domaines de conseil associés

KomuraSoft LLC (合同会社小村ソフト) prend en charge la conception et l’implémentation d’applications Windows communiquant via TCP/IP, l’investigation des causes de dysfonctionnements de communication avec des équipements industriels (« ça se coupe de temps en temps », « ça ralentit »), ainsi que l’accompagnement au dépannage à l’aide de captures de paquets.

• Développement d’applications Windows
• Investigation de bugs et analyse des causes
• Conseil technique et revue de conception
• Contact

Références

Articles associés

Articles récents partageant les mêmes étiquettes, pour approfondir des sujets proches.

Sujets associés

Ces pages replacent le sujet dans un contexte plus large de services et de décisions.

Services liés à ce sujet

Cet article est directement lié aux services suivants.

Questions fréquentes

Questions souvent posées lors d’une consultation sur le sujet de cet article.

Est-ce que les 7 couches du modèle OSI sont réellement utilisées sur l'Internet actuel ?

Non, ce n'est pas le cas. Ce qui fonctionne réellement sur l'Internet actuel est la suite de protocoles TCP/IP (quatre couches en pratique) ; les protocoles OSI à 7 couches proprement dits ont perdu la course à l'adoption dans les années 1990 et ont fini par n'être quasiment jamais utilisés. La RFC 1122, qui a posé les fondations d'Internet, décrit le monde en quatre couches : la couche liaison, la couche IP, la couche transport et la couche application. Ce qui a survécu, c'est le modèle en tant que vocabulaire partagé pour le dépannage et la conversation — des expressions comme « isolons ça au niveau L2 » ou « c'est un problème de niveau L7 ».

Où se trouvent réellement la couche session (L5) et la couche présentation (L6) ?

Elles n'existent pas en tant que couches indépendantes dans la pile TCP/IP réelle. Les rôles envisagés par le modèle OSI sont en réalité dispersés et absorbés ailleurs : L5 (établir et gérer un dialogue) correspond à la négociation (handshake) TLS ou aux cookies et jetons HTTP, et L6 (transformer et chiffrer la représentation des données) correspond au chiffrement TLS, à l'encodage des caractères et aux formats de sérialisation comme JSON. Il n'y a aucun intérêt pratique à déterminer à quelle couche unique appartient TLS — ce qui compte davantage, c'est de pouvoir expliquer qu'il se situe au-dessus de L4 et en dessous de L7, en combinant des rôles équivalents à L5 et L6.

S'il existe déjà une adresse IP, pourquoi a-t-on aussi besoin d'une adresse MAC ?

Parce que les couches se répartissent les responsabilités différemment. L'adresse IP (L3) est l'adresse pointant vers la destination finale, et elle ne change pas du début à la fin de la communication. L'adresse MAC (L2) est l'étiquette indiquant qui transporte le prochain saut, et elle est remplacée à chaque fois qu'elle traverse un routeur. Une trame envoyée d'un PC de bureau vers un serveur web a pour adresse MAC de destination, non pas le serveur web, mais la passerelle par défaut (le routeur). ARP est ce qui permet de retrouver l'adresse MAC d'un nœud voisin à partir d'une adresse IP, et l'on peut consulter la table de correspondance avec la commande arp -a.

À quoi le modèle OSI sert-il concrètement dans la pratique ?

Au dépannage et à la conversation entre équipes. Un signalement du type « impossible de se connecter au serveur » peut être circonscrit de façon systématique en vérifiant, couche par couche à partir du bas, ce qui fonctionne encore : vérification visuelle du voyant de liaison (L1-L2), ping vers la passerelle (L3), confirmation d'une connexion TCP vers le port de destination (L4), et envoi d'une requête HTTP (L7). Par exemple, si le ping fonctionne mais que la connexion TCP échoue, les soupçons se portent sur quelque chose qui bloque le port au niveau L4, comme un service arrêté ou un pare-feu. Il fonctionne aussi comme un système de coordonnées partagé à l'échelle du secteur pour indiquer de façon concise un point de responsabilité, comme dans « ça ressemble à un problème L2, peux-tu regarder le switch ».

Profil de l’auteur

Page de présentation de l’auteur de l’article.

Go Komura

Représentant de KomuraSoft LLC

Spécialisé dans le développement de logiciels Windows, le conseil technique et l’analyse de pannes, notamment pour les systèmes existants et les incidents difficiles à reproduire.