Dans la décennie 1960, le département de la défense américain s'intéresse donc à un système de communication qui pourrait s'affranchir d'une mise hors service par une simple rupture de câble, en créant une réseau maillé, avec des chemins redondants d'un point à un autre. Parallèlement, les centres de recherche éprouvent le besoin de s'échanger des informations, dans un même pays d'abord, un peu partout dans le monde ensuite.

Ceci donne naissance à un modèle théorique de briques de base qui prendra le nom de «modèle D.o.D» et qui définit 5 couches distinctes. Ceci donnera naissance au réseau dans les systèmes Unix.

Dans les années 1970, La société Xerox met en place un système de réseau qui devinera le réseau Ethernet, standardisé par la norme 802.3 une décennie plus tard. Le réseau dit «TCP/IP» s'appuiera dessus en donnant un modèle à seulement 4 couches.

L'Organisation internationale de normalisation (ISO) quant-à elle va définir l'OSI (Open Systems Interconnection) qui propose 7 couches distinctes. Les trois modèles restent cohérents dans leur ensemble. L'intérêt de définir des couches spécialisées avec des interfaces de liaison entre elles est de pouvoir, suivant les besoins, utiliser des concepts très différents dans chaque couche pourvu que les interfaces restent en cohérence. Nous aurons l'occasion de constater ceci plus loin.

Dans le cadre qui nous intéresse le plus, après avoir fait l'inventaire de quelques exemples de couche physique, nous nous intéresserons plutôt au modèle TCP/IP qui nous concerne directement.

Dans le cas de nos réseaux locaux, la couche «accès réseau» est assimilée au protocole de communication «Ethernet» qui englobe la couche physique et la liaison de données.¹⁾

Le but de cette architecture peut se schématiser comme ceci:

• Une application client envoie une requête à une application serveur, par exemple un «browser» réclame la page d'accueil d'un site web.
• Le serveur répond à la requête du client.

Au niveau des applications, le client comme le serveur ont l'impression de discuter directement entre eux (flèche bleue), mais dans la pratique, les données cheminent dans la pile en suivant les flèches rouges

Le «browser web» (open-source, de préférence) comme Firefox, Chromium, Brave, Midori etc. génère une requête pour obtenir une page «web», par exemple: https://www.debian.org/. client et serveur utilisent pour ce faire le protocole de dialogue HTTP (HyperText Transfer Protocol). Une fois les textes de la requête comme de la réponse sont rédigés, ils sont postés à l'adresse du correspondant. Là s'arrête la conscience des applications. Lorsque nous rédigeons une lettre, après l'avoir rédigée et mise dans une enveloppe avec l'adresse du correspondant dans une boîte aux lettres postale, peu nous importe la façon dont le courrier voyage, pourvu qu'il voyage sans se perdre.

L'application va avoir du travail. Elle va devoir:

1. Exprimer la demande dans le langage protocolaire HyperText Transfer Protocol.
2. Trouver l'adresse IP du serveur correspondant à www.debian.org
3. transmettre la requête à la couche de transport en lui indiquant quelques directives pour le transport.

Vous êtes responsable d'une entreprise de jardinage, vous souhaitez recevoir une documentation de la part d'un dépositaire de matériel de tronçonnage. Vous dictez à votre secrétaire le texte du courrier que vous souhaitez envoyer à ce dépositaire, en lui indiquant le nom du dépositaire et le mode d'envoi du courrier (lettre simple, lettre recommandée). La secrétaire va mettre votre requête en forme sur papier, chercher l'adresse postale du dépositaire, mettre la lettre sous enveloppe, l'adresse du destinataire sur l'enveloppe et enfin la transmettre à la poste qui sera le transporteur.

Lorsque la couche de transport du serveur reçoit la requête qui lui vient de plus bas, elle transmet à l'application serveur http (Apache, Nginx ou autre) ce qui la concerne, à savoir la requête en langage protocolaire http. Le serveur commence alors son travail:

1. Il analyse cette requête.
2. S'il n'est pas capable d'y répondre (page inexistante, erreur interne non bloquante pour le serveur…) il renvoie un message d'erreur dans le langage protocolaire http.
3. S'il sait y répondre, il produit la réponse en langage html qu'il transmet au moyen toujours du langage protocolaire http à la couche de transport.

La secrétaire du dépositaire de matériel de tronçonnage reçoit l'enveloppe, en extrait le courrier et le transmet au responsable. Celui-ci, après avoir pris connaissance de vos desiderata va choisir la documentation correspondante et la passe à sa secrétaire, etc. etc.

le paquet que l'application a transmis est mis en forme. Entendons par là qu'il faudra vérifier si l'envoi est recommandé (TCP) ou si c'est un envoi simple (UDP). Autrement dit, cette couche devra assurer le transport de l'information:

• en utilisant un protocole qui devra s'assurer que la transmission s'est bien passée (Transmission Control Protocol, la lettre recommandée);
• en utilisant un moyen plus simple, qui laisse aux applications le soin de juger de l'intégrité du transport (User Datagram Protocol, la lettre simple).

Cette couche va devoir choisir l'itinéraire pour acheminer les données. En fonction des adresses IP (Internet Protocol) de l'émetteur et du destinataire, cette couche devra:

1. si le destinataire est dans le même réseau que l'émetteur, lui faire parvenir directement le paquet.
2. si le destinataire n'est pas dans le même réseau, la couche va chercher par quel «gateway» (routeur) accéder au réseau du destinataire ou à défaut par quel routeur accéder à un réseau qui sera susceptible d'atteindre le réseau du destinataire. Dans ce cas, le paquet voyagera de réseau en réseau jusqu'à son destinataire, ou mourra de vieillesse sans jamais avoir pu atteindre sa destination. Il faudra alors essayer d'en avertir l'émetteur.

Dans tous les cas, une fois le «hop» suivant trouvé (destinataire final ou routeur), le paquet est transmis à la couche inférieure.

Dans l'autre sens, lorsque la couche basse transmet un paquet à la couche IP, soit le destinataire est local, le paquet est alors après nettoyage transmis à la couche transport, soit le destinataire est dans un autre réseau et il sera transmis au routeur suivant.

Ici, c'est le véhicule qui trimballe le paquet. Cette couche ne voit que des adresses MAC qui sont par essence des nœuds informatiques. La couche ne se préoccupe de rien d'autre que:

• de diffuser le paquet sur son réseau pour l'émission d'un paquet en utilisant le protocole CSMA/CD;
• voir l'adresse MAC de destination des paquets diffusés et le remonter après nettoyage vers la couche IP si ce nœud est bien le destinataire.

Bien entendu, son travail est également la traduction du contenu du paquet en fonction du support physique (coaxial, fibre, paire torsadée, onde radio…).

Chaque couche a une fonction qui lui est propre et peut être changée en fonction des besoins pourvu qu'elle reste capable de communiquer avec ses couches adjacentes.

Dans notre cas, ce sont surtout les couches application et Accès réseau qui seront choisies en fonction du contexte, les couches transport et internet n'étant généralement pas modifiées.

Pour que l'ensemble fonctionne correctement, il va être nécessaire de disposer de quelques services compagnons.

L'adresse MAC n'est utilisée réellement que dans la couche d'accès au réseau. C'est une adresse qui est initialement fixée en «dur» dans l'interface réseau. Si initialement elle était considérée comme unique au monde, les ambitions ont été revues à la baisse puisque finalement son unicité n'est plus nécessaire qu'au sein du réseau «local».

L'adresse IP de chaque nœud doit en revanche être attribuée de façon cohérente en fonction de l'architecture du réseau concerné. Idéalement, elle doit être unique dans tout l'internet mais dans le cas des adresses IPv4, une astuce a été développée pour pallier l'épuisement de la réserve d'adresses, avec la pirouette du «masquerade». IPv4 étant un nombre de 32 bits (4 x 8), il n'y a au total que 2³² = 4 294 967 296 valeurs possibles ce qui est très loin d'être désormais suffisant. Bien que IPv6 soit désormais opérationnel avec ses 128 bits, son déploiement est encore loin d'être universel.

La méthode la plus triviale consiste à assigner « à la main» les adresses à chaque nœud. C'est certes possible sur de petits réseaux ou dans des cas très particuliers mais la solution est loin d'être universelle.

La méthode la plus professionnelle consiste à utiliser le protocole DHCP (Dynamic Host Configuration Protocol). Un serveur correctement paramétré pourra distribuer des adresses en cohérence avec l'architecture du réseau aux nœuds qui lui en feront la demande.

L'URI (Uniform Resource Identifier) comme par exemple debian.org dans l'URL (Uniform Resource Locator) https://www.debian.org doit pouvoir être traduit en adresse IP.

DNS (Domain Name System) est chargé de gérer ce problème. Une architecture de serveurs distribués dans le monde est là pour ça.

Sur cette couche, seules les adresses MAC sont comprises. Il faut donc trouver l'adresse MAC qui correspond à l'adresse IP au passage de la couche internet à la couche Réseau. C'est ARP (Address Resolution Protocol) qui se chargera de l'opération et nous verrons à quel point ce protocole est fragile.

Lorsque la couche Internet constate des impossibilités d'accès à certains nœuds lors du transit de l'information, elle a besoin de signaler le problème à l'émetteur. C'est ICMP (Internet Control Message Protocol) qui s'en charge. Ce protocole peut hélas être dévoyé pour créer plus de troubles que pour en signaler.

• UDP (User Datagram Protocol) pour le transfert de paquets (appelés ici datagrammes) sans contrôle d'intégrité.
• TCP (Transmission Control Protocol) pour le transfert de paquets avec contrôle d'intégrité.

Outre les protocoles spécifiques à chaque application (HTTP, FTP, SMTP, IMAP, POP3, TELNET…) il en existe un particulier qui est là pour le chiffrement des données, qui ajoute une sous-couche entre l'application et le transport. La couche SSL (Secure Socketd Layer), de plus en plus délaissée au profit de TLS (Transport Layer Security) utilise un système de chiffrement asymétrique qui permet, suivant ce que l'on souhaite:

• signer une donnée pour certifier son origine;
• chiffrer une donnée pour la rendre seulement lisible par son destinataire légitime.