Les idées principales, dégagées des considérations techniques
Sur ce site j’ai publié récemment un article pour expliquer l’Internet à des lecteurs dépourvus de toute connaissance technique sur le sujet, ainsi que les recensions de deux livres d’histoire des réseaux, Inventing the Internet de Janet Abbate et La France en réseaux (1960-1980) de Valérie Schafer. Pour ceux que ces textes de vulgarisation auraient laissés sur leur faim, le numéro de février 2023 des Communications of the Association for Computing Machinery (CACM), l’organe de la principale société savante informatique, publie un article de James McCauley, Scott Shenker et George Varghese [1] intitulé Extracting the Essential Simplicity of the Internet, qui en une dizaine de pages (de grand format et assez denses) donne la meilleure synthèse que j’aie lue des idées selon lesquelles fonctionne le réseau, sans entrer dans les considérations d’implémentation [2] développées ici (chapitre 6). Cet article m’a notamment aidé à comprendre certaines caractéristiques de BGP, un protocole dont ne parlent guère que les spécialistes alors qu’il conditionne le fonctionnement planétaire du réseau, ainsi que la radicalité des infractions aux principes généraux de l’Internet introduites par les réseaux privés des diffuseurs de contenus (Contents Distribution Networks d’Akamai ou de Netflix par exemple) et des opérateurs d’infonuagique (Cloud Computing).
Les auteurs ont choisi délibérément de faire abstraction du fatras de sigles qui désignent autant de protocoles pour faire émerger l’audace d’une idée brillante dans sa simplicité conceptuelle, l’Internet en un mot.
Modèle de service
Les services rendus par l’Internet reposent sur trois mécanismes clé :
– le routage, qui consiste à calculer un itinéraire pour l’acheminement des données entre l’émetteur et le récepteur ;
– la garantie de remise, qui assure que les données seront délivrées à leur destinataire intégralement et sans erreur, selon un itinéraire calculé par le routage ;
– la résolution de noms, qui consiste à traduire un identifiant propre à une application d’accès au réseau (adresse électronique pour une application de courrier électronique, URL d’une page Web pour un navigateur...) en adresse de destination utilisable pour l’acheminement des données.
Pour réaliser ces services, deux philosophies sont envisageables :
- Un modèle ambitieux, qui implémenterait toutes les fonctions nécessaires aux applications envisagées, avec une supervision centralisée de leur fonctionnement. C’était le modèle de tous les systèmes de réseau concurrents de l’Internet, tels X25 ou EARN/Bitnet, et c’est ce qui causa leur extinction, pour les raisons suivantes :
- implémenter toutes les fonctions nécessaires aux applications prises en compte nécessite, chaque fois qu’une nouvelle application apparaît (et a priori on espère qu’une telle apparition sera fréquente), une modification de l’ensemble de l’architecture du réseau pour lui ajouter de nouvelles fonctions ;
- la supervision centralisée du réseau facilite sans doute son administration (et la facturation des abonnés...), mais interdit pratiquement (ou du moins complique énormément) le développement de nouvelles applications et de nouveaux protocoles par des équipes indépendantes, parce que ces développements auront nécessairement des répercussions sur le cœur de réseau.
- Un modèle « modeste », qui implémente les trois services mentionnés ci-dessus de façon minimale, dite de « best effort ». Ce modèle est à la base du succès de l’Internet, il lui a permis de passer sans modification fondamentale d’un réseau de quelques centaines de nœuds au réseau que nous connaissons, où plusieurs milliards de terminaux peuvent communiquer quasi instantanément. Il est issu de la prise de conscience d’une évolution que peu de gens avaient perçue en ces années 1970 : alors que le réseau téléphonique traditionnel mettait en communication des terminaux aux fonctions très rudimentaires, très « bêtes », les progrès de l’électronique et de l’informatique inauguraient une ère où il serait possible d’installer dans les terminaux des fonctions complexes, en fait tout ce que l’on appelle aujourd’hui la « pile TCP/IP », le logiciel complet qui fait fonctionner le réseau. Et il devient ainsi possible d’avoir un cœur de réseau très simple, aux fonctions très rudimentaires, que pourront facilement utiliser les créateurs de nouvelles applications, à charge pour eux de développer les fonctions d’extrémité à implanter dans les terminaux : le meilleur exemple en est l’évolution récente des navigateurs Web, qui incorporent de plus en plus de fonctions auparavant dévolues au système d’exploitation et aux systèmes de gestion de bases de données (analyse issue d’une communication personnelle de Christian Queinnec).
- Un corollaire de ce modèle « modeste » est l’acceptation de l’erreur comme la situation normale d’un réseau de transmission de données. Non seulement la perte de paquets [3] de données lors de la transmission est un phénomène normal, mais elle est un moyen de réglage du fonctionnement du réseau : si un émetteur émet à une cadence trop rapide pour les capacités du récepteur (ou pour celles d’un équipement intermédiaire sur le trajet des données), il y aura des pertes de paquets, qui seront détectées par les logiciels d’extrémité, cette information pourra être communiquée à l’émetteur, qui pourra adapter son débit.
- Ce modèle « modeste » et son corollaire d’acceptation des erreurs de transmission trouvent leur achèvement ultime dans le concept de datagramme, formulé par Louis Pouzin et son équipe du réseau Cyclades : dans un réseau à commutation de paquets, il n’est pas nécessaire de calculer de façon centralisée un itinéraire que suivront tous les paquets de données d’une même communication. Il suffit d’étiqueter chaque paquet par son adresse d’origine et par son adresse de destination, et d’installer sur les « postes d’aiguillage » du réseau, appelés routeurs, les logiciels et les bases de données qui permettent de calculer quel sera la prochaine destination du paquet. Ce calcul se nomme le routage, et fera l’objet de la prochaine section de cet article. L’article des CACM omet malheureusement de citer le datagramme et le travail de l’équipe de Louis Pouzin, pourtant reconnu par Vinton Cerf et Bob Kahn, les auteurs principaux de TCP/IP. Le datagramme est un élément essentiel de la flexibilité et de la versatilité de l’Internet.
Modèle de réseau
Les auteurs de notre article décrivent l’architecture de l’Internet en la décomposant selon quatre couches logiques.
Couche 1 - Physique
La couche 1, physique, a trait aux transmissions de données d’une station (ordinateur, imprimante ou téléphone mobile, c’est la même chose) à une autre, sur le même support physique, qui peut être filaire, hertzien, voire infra-rouge, etc.
Couche 2 - Réseau
Un réseau de couche 2 relie par un même support physique (filaire ou hertzien) des stations proches géographiquement.
La couche 2, nommée liaison de données dans le modèle OSI [4], mais que nos auteurs nomment couche réseau, a pour tâches :
- Découper le flux de bits issus de la couche 1 en paquets, typiquement de l’ordre de 1500 octets (un octet peut correspondre à un caractère), et placer en tête de chaque paquet un en-tête qui indique où il doit être acheminé.
- Livrer chaque paquet à la station appropriée, au sein du réseau local.
- Un tel réseau local peut fonctionner :
- soit par diffusion (broadcast), c’est-à-dire que chaque station reçoit tous les paquets émis, quitte à jeter ceux qui ne lui sont pas destinés ; c’est notamment ainsi que fonctionnent les réseaux sans fil ; ce modèle de diffusion n’est possible que pour un réseau local, d’étendue géographique limitée, un immeuble par exemple, ou la portée d’une antenne WiFi ou de téléphonie mobile ;
- soit au moyen de commutateurs (switches) qui dirigent les paquets vers leur station de destination.
Sur toute station chaque interface matérielle d’accès à un réseau (prise Ethernet, antenne WiFi ou cellulaire...) possède une adresse unique, immuable et permanente, dite adresse MAC (Media Access Control). C’est cette adresse qui permet au service de couche 2 de remettre les paquets de données à la station destinataire.
Couche 3 - Internet
La couche 3, réseau dans le modèle OSI [5], mais que nos auteurs nomment Internetnetwork, achemine les paquets du réseau local de l’émetteur au réseau local du destinataire, le cas échéant en traversant d’autres réseaux, en tout point de l’Internet mondial.
Chaque interface réseau de chaque station (ordinateur) connectée à l’Internet (ou « nœud » du réseau) reçoit, lors de sa connexion à un réseau, une adresse IP (couche 3), ou numéro IP, qui, comme le numéro de téléphone dans le réseau téléphonique, est unique et permet de l’atteindre depuis n’importe quel autre nœud du réseau, n’importe où dans le monde. Quand la station change de réseau, ne serait-ce qu’en débranchant sa prise Ethernet et en passant au Wi-Fi, elle reçoit une nouvelle adresse IP, différente de la précédente. Chaque paquet de données comporte un en-tête qui mentionne l’adresse IP de son émetteur et celle de son destinataire.
Les réseaux de couche 3 échangent des données entre eux au moyen de routeurs, que l’on peut comparer à des postes d’aiguillage du réseau. Un routeur n’est ni plus ni moins qu’un ordinateur spécialisé qui possède au moins deux interfaces réseau, ce qui lui permet d’être connecté à au moins deux réseaux différents et ainsi de faire passer des paquets de données d’un réseau à un autre. Nous allons voir ci-dessous comment les routeurs déterminent l’acheminement des paquets de données d’un réseau à un autre.
Couche 4 - Transport
La couche 4, transport, assure les fonctions suivantes :
- vérifier que tous les paquets d’une communication sont bien arrivés à destination, sans altération accidentelle ;
- le cas échéant, remettre les paquets dans le bon ordre, s’ils sont arrivés en désordre ;
- remettre les données à l’application adéquate : ainsi, la station destinataire peut héberger un logiciel de courrier électronique et un navigateur Web. Chaque paquet comporte un en-tête de couche 4, qui précise un numéro de port, typiquement par exemple 995 pour la remise de courrier électronique sécurisée et 443 pour la navigation Web sécurisée. En fonction de ce numéro de port, les données seront remises soit au logiciel de messagerie, soit au navigateur. C’est ainsi que le modèle de service de l’Internet permet la coexistence de multiples protocoles de transport au sein d’un même réseau.
Systèmes autonomes (AS)
L’Internet n’est pas un réseau unique, mais, comme son nom l’indique, un réseau de réseaux. Chacun de ces réseaux est la propriété d’un opérateur (ou ISP, Internet Service Provider) différent, qui l’administre à sa façon. Un réseau administré de façon unique par un ISP est un AS (Autonomous System, ou domaine) ; si l’on compare l’Internet à un continent, les AS en sont les pays, séparés par des frontières, avec chacun sa législation. Un grand ISP peut posséder plusieurs AS, à l’instar d’un état fédéral. Chaque AS est identifié par un numéro d’AS. L’Internet est constitué d’à peu près 75 000 AS (mars 2023), dont le plus grand (AS 749) comporte 210 millions d’adresses IP, et le plus petit (AS 2111) un seul ordinateur.
Un AS peut comporter plusieurs réseaux de couche 3, reliés entre eux par des routeurs. À l’intérieur d’un AS les routeurs appartiennent à l’ISP ou à ses clients et sont administrés selon les règles qu’il a fixées. Pour que l’Internet existe et puisse fonctionner, il faut établir des communications entre AS d’ISPs différents : pour ce « passage de frontière », un ISP disposera des routeurs de frontière de système autonome, directement reliés aux routeurs de frontière des ISPs avec qui il veut établir une liaison.
Nous allons voir que le routage à l’intérieur d’un AS et le routage entre AS obéissent à des protocoles différents, bien que les deux cas relèvent de la couche 3 de notre modèle.
Routage
Le routage consiste à calculer un moyen de remettre un paquet de données à son destinataire. Nos auteurs distinguent le routage au sein de la couche 2, le routage de couche 3 au sein d’un réseau dans un AS, le routage de couche 3 entre AS différents.
Routage de couche 3 au sein d’un AS (ou intra-domaine)
Commençons par le routage de couche 3 au sein d’un AS. Les principes sont les suivants :
- chaque paquet de données comporte une adresse IP de destination ;
- chaque routeur appartient à un réseau local (couche 2) par lequel il communique directement avec des routeurs voisins, connectés à d’autres réseaux ;
- chaque routeur possède une table de transfert (forwarding table), qui indique :
- soit qu’il est connecté (couche 2) au réseau local de destination du paquet considéré, ce qui permet de le remettre directement au destinataire,
- soit l’adresse MAC d’un routeur voisin, accessible directement par le réseau local (couche 2), auquel transmettre le paquet de données pour le rapprocher de sa destination.
Nous dirons que l’ensemble des interconnexions entre routeurs constitue le graphe du réseau, que l’ensemble des tables de transfert constitue l’état de transfert, et que l’union des deux constitue l’état de routage. Une instance donnée de l’état de routage sera dite valide si elle permet toujours d’acheminer les paquets à destination ; on dira que l’état de routage considéré comporte une boucle s’il y a des cas où un paquet peut retourner à un routeur par lequel il est déjà passé. Nos auteurs démontrent qu’une instance de l’état de routage est valide si et seulement si elle ne comporte pas de boucles, démonstration pour laquelle nous renvoyons à l’article.
Il existe essentiellement deux familles de protocoles de routage intra-domaine :
– Protocoles à vecteur de distance, basés sur l’algorithme de Bellman-Ford, dont l’ancêtre est RIP (Routing Information Protocol) et le successeur EIGRP (Enhanced Interior Gateway Routing Protocol). Ces protocoles ont été populaires au début du réseau parce qu’ils sont peu gourmands en mémoire. En fonction de la métrique choisie, chaque routeur calcule sa distance à chaque réseau destination, et la propage à ses voisins, ce qui permet finalement de déterminer le chemin le plus court vers la destination.
– Protocoles à état de liaison, basés sur l’algorithme de Dijkstra, dont le modèle est OSPF (Open Shortest Path First). OSPF est gourmand en mémoire parce que chaque routeur doit assembler le graphe complet du réseau, mais il est plus efficace que les protocoles à vecteur de distance.
Tous ces protocoles garantissent l’absence de boucle.
Routage de couche 3 entre AS (ou inter-domaines)
Un AS doit acheminer tous les paquets pour lesquels il est soit l’origine soit la destination, mais tous les autres paquets sont du trafic de transit, depuis un autre AS vers un troisième AS. Le propriétaire d’un AS est libre de choisir quel trafic de transit il accepte, et par quel itinéraire il va le faire passer ; ces choix dépendent des accords commerciaux qu’il a (ou qu’il n’a pas) avec d’autres AS ; et comme ces accords sont en règle générale confidentiels, les choix de transit et de routage d’un AS ne sont pas publics, et ne sont divulgués que si le propriétaire de l’AS le veut bien, et à qui il le veut bien. Ces impératifs de confidentialité (qui interdisent l’usage d’OSPF) et de possibilité de choix arbitraire d’itinéraire (qui interdisent les protocoles à vecteur de distance) font que les protocoles de routage inter-domaines sont différents des protocoles de routage interne à un domaine. Le protocole de routage inter-domaines utilisé actuellement est BGP (Border Gateway Protocol), qui permet à un AS de choisir à qui il annonce ses itinéraires, et quel itinéraire il utilise quand il a le choix entre plusieurs.
Routage de couche 2
Pour éviter les boucles de routage dans les réseaux locaux en couche 2 qui ne sont pas des réseaux à diffusion (où tout le monde reçoit tous les paquets), le protocole STP (Spanning-Tree Protocol, protocole d’arbre couvrant, basé sur un algorithme décrit par Radia Perlman) extrait du graphe du réseau un arbre, en éliminant certaines liaisons. Ce protocole garantit ainsi l’absence de boucle.
Quand le réseau de couche 2 n’est pas un réseau à diffusion (où toutes les stations reçoivent tous les paquets, y compris ceux qui ne lui sont pas destinés), chaque paquet est remis à la station destinataire selon le protocole ARP (Address Resolution Protocol), qui consiste à envoyer à tout le monde un message qui demande « quelle station ou quel routeur à telle adresse IP ? », ce à quoi le destinataire répond en fournissant son adresse MAC. On imagine que ce protocole pose quelques problèmes de sécurité (ARP poisoning...), pour lesquels existent des contre-mesures.
Résolution de noms
Ce qui précède expose comment un paquet de données peut être remis à l’adresse IP de destination à l’autre bout de la planète, mais il reste un problème à résoudre : les internautes n’utilisent pas des adresses IP, mais des adresses de courrier électroniques, telles jean.martin@mon-ecole.fr
, ou des URL, tels www.mon-ecole.fr
. Dans ces deux exemples, mon-ecole.fr
est un nom de domaine (nos auteurs préfèrent l’appellation application-level name), plus confortable pour un être humain qu’une adresse IP, mais les protocoles de l’Internet ont besoin de l’adresse IP pour acheminer les paquets de données à destination. D’où la nécessité d’un système de résolution de noms en adresses (ou numéros) IP, similaire aux annuaires téléphoniques du siècle dernier.
Un tel système de résolution de noms doit effectuer les fonctions suivantes :
– attribuer le contrôle administratif de chaque nom à une autorité unique, qui décide à quelle adresse IP il correspond ;
– assurer un traitement efficace et rapide des demandes de résolution ;
– effectuer ces opérations pour des milliards de noms.
Ces fonctions sont accomplies par le Système de noms de domaines (Domain Name System, DNS) dont la première spécification a été rédigée en 1983 par Paul Mockapetris (RFC 882 et RFC 883), qui en a également écrit la première implémentation.
Le DNS est un espace de noms hiérarchique que l’on peut représenter comme un arbre sous la racine (sobrement nommée .
) duquel on trouve une première rangée de top-level domains (TLD) tels que .fr
, .dz
, .edu
ou .com
, contrôlée par une autorité centrale, l’Internet Corporation for Assigned Names and Numbers (ICANN). Chaque TLD est à son tour administré par une autorité unique, ainsi pour le domaine .fr
l’Association française pour le nommage Internet en coopération (Afnic), habilitée à déléguer l’attribution de sous-domaines tels que .ined.fr
à des bureaux d’enregistrement, et ainsi de suite, récursivement.
Cette structure arborescente permet une résolution de nom (pour un nom de domaine, trouver l’adresse IP du serveur correspondant) parallélisée et un contrôle administratif décentralisé, les deux indispensables à l’efficacité du système. Les informations de la racine du DNS, qui en permettent le fonctionnement global, sont répliquées à des centaines d’exemplaires tout autour du monde, ce qui en assure la résilience.
Les secrets du succès de l’Internet
Nos auteurs ont ainsi ramené l’impénétrable complexité de l’Internet à un petit ensemble de choix de conception. Comprendre les motifs de ces choix et les raisons pour lesquelles ils se sont avérés judicieux pourrait d’ailleurs être utile à la conception d’un nouvel Internet, techniquement différent de l’actuel mais doté des mêmes qualités. L’article mentionne quatre raisons principales de ce succès :
– modestie : plutôt que de vouloir répondre à tous les besoins des différentes applications de l’Internet, offrir un modèle de service minimum mais suffisamment général pour permettre le développement de nouvelles applications aux caractéristiques inédites ;
– modularité : le modèle en couches de l’Internet, dont Hubert Zimmermann de l’équipe Cyclades fut le concepteur principal, permet au réseau d’évoluer fréquemment et rapidement sans qu’il faille mobiliser des équipes trop nombreuses pour chaque innovation ;
– admettre que l’erreur est le cas normal : dès qu’un système est très vaste, et surtout s’il s’agit de fonctions aussi contingentes que des transmissions à distance dans toutes sortes d’environnements imprévisibles, s’acharner à éviter les erreurs aurait un coût énorme pour un résultat décevant ;
– consensus informel et preuve par l’exemple : plutôt que de multiplier les réunions de comités de spécification, la tradition de l’Internet Engineering Task Force (IETF) est plutôt que l’on se mette d’accord en gros sur le but à atteindre et que celui qui exhibera un « code qui tourne » aura le dernier mot (jusqu’au prochain « code qui tourne » mieux...).
Reste-t-il des défauts ?
Oui bien sûr. Mais nos auteurs réfutent l’accusation de « manque de sécurité » de l’Internet. Tout système informatique peut être sujet à une faille de sécurité, mais elle ne peut être imputée à l’architecture du réseau, et chaque attaque contre un des éléments constituants de l’Internet a trouvé une parade rapide et efficace.
Il est plus justifié de critiquer la multiplication des middle-boxes, qui pour des raisons diverses modifient les paquets de données sur le trajet entre leur origine et leur destination. Ainsi les opérateurs d’informatique en nuage, tels Amazon, Microsoft ou Google, et de Contents Delivery Networks (CDN), tels Netflix ou Akamai, ont-ils développé des protocoles non-standard et non publiés pour améliorer l’efficacité de leurs opérations. Ils tendent désormais à déployer d’immenses réseaux privés pour desservir leurs clients, ce qui est bien sûr légitime, mais risque de faire perdre de vue l’idéal de connectivité universelle dont l’Internet reste le symbole et le porte-drapeau.