Réseaux, internet et web : IP, DNS, HTTP et le modèle client-serveur

Les réseaux et les paquets

Presque aucun logiciel moderne ne fonctionne seul. Une application de livraison de repas sur votre téléphone dialogue avec les serveurs de l’entreprise, qui dialoguent avec les tablettes des restaurants, un prestataire de paiement, un service de cartographie et un service de notifications. Cette section explique comment fonctionne ce dialogue, en partant du bas.

Un réseau est un ensemble d’ordinateurs reliés de façon à pouvoir échanger des données, par câble, Wi-Fi, réseau mobile ou fibre optique. Internet est un réseau de réseaux : des millions de réseaux appartenant à des propriétaires différents (box internet à domicile, opérateurs mobiles, universités, fournisseurs de cloud) qui ont accepté de transporter le trafic les uns des autres selon des règles communes appelées protocoles.

Les données ne circulent pas en un seul flux continu. Elles sont découpées en paquets : des morceaux d’environ 1500 octets au maximum en général, chacun étiqueté avec sa provenance et sa destination, comme un colis portant l’adresse de l’expéditeur et celle du destinataire. Des appareils appelés routeurs font passer les paquets d’un réseau à l’autre, chacun choisissant un bon saut suivant, un peu comme des centres de tri qui font suivre les colis vers leur destination. Différents paquets d’un même message peuvent emprunter des routes différentes, arriver dans le désordre ou parfois se perdre, et l’ordinateur destinataire les remet dans l’ordre. Découper les données en paquets permet à des millions de conversations de partager équitablement les mêmes câbles, et permet au trafic de contourner une liaison coupée.

Les adresses : adresses IP et ports

Pour qu’un paquet arrive, la destination a besoin d’une adresse. Chaque appareil sur internet est joignable par une adresse IP (IP signifie Internet Protocol). L’ancienne version, IPv4, écrit les adresses sous la forme de quatre nombres de 0 à 255, comme 192.0.2.10 ; elle permet environ 4,3 milliards d’adresses, ce qui ne suffit pas pour tous les téléphones, ordinateurs portables et capteurs du monde. La nouvelle version, IPv6, utilise des adresses beaucoup plus longues écrites en hexadécimal (base 16, avec les chiffres 0 à 9 et les lettres a à f), comme 2001:db8::1, et peut accueillir un nombre pratiquement illimité d’appareils. Les deux sont utilisées côte à côte. (Les adresses d’exemple de cette section proviennent de plages réservées à la documentation : elles n’appartiennent à aucune machine réelle.)

Une adresse IP amène un paquet au bon ordinateur, mais un ordinateur exécute de nombreux programmes à la fois. Un numéro de port, de 0 à 65 535, indique quel programme doit le recevoir. Si l’adresse IP est l’adresse postale d’un immeuble de bureaux, le port est le numéro du bureau. Les services courants ont des ports standard : 443 pour HTTPS, 80 pour HTTP simple, 53 pour le DNS, 5432 pour la base de données PostgreSQL. Un programme serveur écoute sur un port, en attendant des connexions ; quand votre navigateur contacte un site web, il se connecte au port 443 de l’adresse IP du site.

TCP et UDP : deux façons de livrer

Au-dessus d’IP se trouvent deux grands protocoles de transport, qui décident du soin apporté à la livraison. TCP (Transmission Control Protocol) offre à deux programmes un flux d’octets fiable et ordonné. Avant tout envoi de données, les deux côtés établissent une connexion par une poignée de main (handshake) en trois étapes. Chaque paquet est numéroté ; le destinataire accuse réception de ce qui est arrivé ; tout ce qui manque est renvoyé ; tout est remis au programme dans le bon ordre. TCP ralentit aussi quand le réseau est encombré. C’est comme un envoi recommandé avec suivi : fiable, mais avec un certain surcoût.

UDP (User Datagram Protocol) envoie simplement des paquets isolés, appelés datagrammes, sans poignée de main, sans accusé de réception, sans renvoi et sans ordre. C’est comme envoyer des cartes postales : bon marché et rapide, mais certaines peuvent ne pas arriver. C’est exactement ce qu’il faut quand un paquet en retard ne sert de toute façon plus à rien. Dans un appel vidéo, un fragment de son qui arrive avec une demi-seconde de retard est pire qu’un fragment qui n’arrive jamais : les appels, les diffusions en direct et les jeux en ligne utilisent donc UDP et s’accommodent de petites lacunes. Les requêtes DNS, qui sont de toutes petites questions et réponses, utilisent elles aussi traditionnellement UDP.

Le DNS : le carnet d’adresses d’internet

Les personnes retiennent des noms comme shop.example ; les réseaux acheminent selon des adresses IP. Le Domain Name System (DNS, système de noms de domaine) traduit les uns en les autres. C’est un annuaire mondial et distribué : aucun ordinateur ne détient à lui seul tous les noms. La responsabilité est au contraire répartie selon les points du nom, lus de droite à gauche. Les serveurs racine savent qui est responsable de chaque domaine de premier niveau, comme .com ou .uk ; ces serveurs de domaine de premier niveau savent quels serveurs de noms faisant autorité sont responsables de chaque domaine enregistré sous eux ; et les serveurs faisant autorité détiennent les enregistrements eux-mêmes, comme l’adresse IP de www.shop.example. La zone racine est servie par 13 identités de serveurs nommées, exploitées par 12 organisations indépendantes au moyen de bien plus d’un millier d’instances de serveurs dans le monde.

En général, votre appareil ne parcourt pas lui-même cette chaîne. Il interroge un résolveur récursif, généralement exploité par votre fournisseur d’accès à internet ou par un service public, qui fait le travail et mémorise (met en cache) les réponses pendant une durée fixée par le propriétaire du domaine, appelée TTL (time to live, durée de vie). Comme les réponses sont mises en cache à de nombreux niveaux, la plupart des recherches obtiennent une réponse en quelques millisecondes sans jamais atteindre la racine. Cette même mise en cache explique pourquoi la modification d’un enregistrement DNS peut mettre des minutes, voire des heures, à être visible partout.

HTTP : requêtes et réponses

Une fois qu’un programme peut joindre un autre programme, les deux ont besoin d’un langage commun pour dire ce qu’ils veulent. Sur le web, ce langage est HTTP (Hypertext Transfer Protocol). Il suit un schéma simple : le client envoie une requête ; le serveur renvoie une réponse. Chaque requête indique une méthode (quoi faire), un chemin (sur quoi), des en-têtes (des informations supplémentaires sous forme de paires nom-valeur) et parfois un corps (les données envoyées). Chaque réponse porte un code d’état, des en-têtes et généralement un corps : une page web, une image ou des données dans un format comme JSON (un format texte simple pour les données structurées, expliqué dans la section sur les API).

Les méthodes les plus courantes sont GET (récupérer quelque chose, sans le modifier), POST (soumettre quelque chose de nouveau, comme passer une commande), PUT (remplacer quelque chose à une adresse connue, comme mettre à jour une adresse de livraison) et DELETE (supprimer quelque chose). GET, PUT et DELETE sont par définition idempotentes : envoyer deux fois la même requête a le même effet que l’envoyer une fois, ce qui permet de les retenter sans risque après une panne réseau. POST ne l’est pas, et c’est pourquoi une nouvelle tentative imprudente peut passer une commande deux fois. Les en-têtes transportent des éléments comme le type de contenu (Content-Type: application/json), la langue préférée de l’utilisateur, les cookies (de petits éléments de données qu’un site demande au navigateur de stocker et de renvoyer avec les requêtes suivantes) et les identifiants, ainsi que des instructions de mise en cache.

HTTP est sans état : chaque requête se comprend par elle-même, et le serveur n’est pas tenu de se souvenir des précédentes. Les sessions de connexion sont construites par-dessus, généralement par l’envoi d’un cookie ou d’un jeton par le client à chaque requête. L’absence d’état est l’une des raisons pour lesquelles le web passe si bien à l’échelle : n’importe lequel de nombreux serveurs identiques peut traiter n’importe quelle requête.

POST /api/orders HTTP/1.1
Host: shop.example
Content-Type: application/json
Authorization: Bearer eyJhbGciOi...

{"product_id": 42, "quantity": 2}

HTTP/1.1 201 Created
Content-Type: application/json
Location: /api/orders/9917

{"order_id": 9917, "status": "received", "total_pence": 3000}

La distinction entre 4xx et 5xx compte en pratique. Un 4xx dit : « ne vous contentez pas de réessayer ; corrigez la requête ». Un 5xx dit : « le problème est de notre côté » ; réessayer plus tard peut fonctionner, et l’équipe d’exploitation doit être alertée quand le taux de 5xx augmente.

HTTPS et TLS : confidentialité et identité

HTTP simple envoie tout sous forme de texte lisible, si bien que n’importe qui sur le trajet, par exemple une personne connectée au même Wi-Fi d’un café, pourrait le lire ou le modifier. HTTPS, c’est HTTP envoyé dans un canal protégé créé par TLS (Transport Layer Security ; la version actuelle, TLS 1.3, a été publiée sous le nom de RFC 8446 en 2018). TLS apporte trois choses : la confidentialité (les personnes qui écoutent ne voient que des données brouillées), l’intégrité (toute falsification est détectée) et l’authentification (vous parlez vraiment à shop.example, et non à un imposteur).

L’authentification repose sur des certificats. Le certificat d’un site est un document numérique qui dit en substance : « cette clé publique appartient à shop.example », signé par une autorité de certification (CA) à laquelle votre navigateur ou votre téléphone fait déjà confiance. Il fonctionne comme un passeport : délivré par une autorité à laquelle les deux parties font confiance, vérifié par rapport à son titulaire, et valable seulement jusqu’à sa date d’expiration. Pendant la poignée de main TLS, le serveur présente son certificat, le client vérifie la signature, le nom et les dates, et les deux parties conviennent de nouvelles clés secrètes pour chiffrer le reste de la conversation. Si une vérification échoue, le navigateur affiche un avertissement.

TLS protège les données en transit entre deux points. Il ne protège pas les données une fois stockées, et il ne prouve pas que le site est honnête, seulement qu’il est bien celui qu’il prétend être. Aujourd’hui, HTTPS est la norme pour tout le trafic web, pas seulement pour les paiements, et les certificats sont souvent délivrés gratuitement et renouvelés automatiquement.

Le modèle client-serveur

La plupart des systèmes de ce cours suivent le modèle client-serveur. Un client (un navigateur, une application mobile, un autre programme) entame la conversation en envoyant une requête. Un serveur attend des requêtes et y répond. Le serveur détient ce qui doit être partagé et digne de confiance : le catalogue de produits, les commandes de tout le monde, les règles sur les prix et les remboursements. Le client gère l’écran de l’utilisateur et ses saisies.

Dans un restaurant, les convives sont les clients et la cuisine est le serveur : les convives passent commande ; la cuisine détient les ingrédients et le savoir-faire et sert de nombreux convives à la fois. Une conséquence est que le serveur ne doit jamais faire aveuglément confiance au client. Une application mobile peut être modifiée par son utilisateur : les prix, les autorisations et les niveaux de stock doivent donc être vérifiés sur le serveur, même si l’application les vérifie elle aussi avec soin.

Un serveur est souvent aussi un client : le serveur web de la boutique est client de sa base de données et du prestataire de paiement. Les systèmes réels sont des chaînes et des toiles de telles relations, comme le montre le diagramme de séquence ci-dessous.

Latence et bande passante

Deux chiffres décrivent la rapidité ressentie d’un réseau, et on les confond souvent. La bande passante est la quantité de données qu’une connexion peut transporter par seconde, par exemple 100 mégabits par seconde : la largeur du tuyau. La latence est le temps que met une donnée pour aller d’un bout à l’autre, généralement mesuré comme un temps d’aller-retour (RTT, round-trip time) en millisecondes : la longueur du tuyau. Une analogie autoroutière aide : ajouter des voies (la bande passante) laisse passer plus de voitures par heure, mais ne raccourcit le trajet d’aucune voiture (la latence).

La latence a un plancher fixé par la physique. Dans la fibre optique, la lumière se déplace à environ 200 000 km par seconde, soit environ les deux tiers de sa vitesse dans le vide. Londres et Sydney sont distantes d’environ 17 000 km en ligne droite à la surface du globe, si bien que même une fibre parfaite suivant cette ligne demanderait environ 85 ms dans un sens et 170 ms pour un aller-retour. Les câbles réels ne suivent pas le plus court chemin et les routeurs ajoutent du délai : les allers-retours mesurés sont donc généralement d’environ 250 ms. Aucune mise à niveau ne peut supprimer cela. Si le chargement d’une page depuis Sydney exige dix allers-retours successifs vers un serveur à Londres, l’utilisateur attend deux secondes et demie, quelle que soit la vitesse de sa connexion internet.

Ce qui se passe quand vous tapez une adresse web

Tous ces éléments se combinent chaque fois que vous visitez un site web. Voici l’enchaînement lorsque vous tapez https://shop.example/products/42 et appuyez sur Entrée, de façon simplifiée mais exacte.

Pourquoi c’est important pour l’architecture

Dès qu’un système est réparti sur plus d’un ordinateur, chaque interaction entre ses parties devient un appel réseau, avec de la latence, un risque de défaillance et un besoin de sécurité. Un appel de fonction à l’intérieur d’un programme prend des nanosecondes et ne se perd jamais ; un appel à travers un réseau prend des millisecondes, parfois bien plus, et parfois ne revient jamais. Beaucoup des problèmes les plus difficiles de l’architecture découlent de cette différence, et c’est pourquoi le chapitre 6 s’ouvre sur les illusions de l’informatique distribuée, comme la croyance que la latence est nulle.

Les protocoles vus ici reviennent aussi comme briques de base : HTTP sous-tend les API web de la partie suivante de ce chapitre et les styles de communication du chapitre 6, tandis que TLS et les certificats reviennent dans la communication sécurisée et le zero trust. Placer des serveurs près des utilisateurs relève de l’architecture multirégion et en périphérie (edge).