Le manuel de référence, passé en licence libre, qui explique pourquoi l'Internet a la forme qu'il a et pourquoi il tient debout.
Pourquoi ce livre
La fiche jumelle de High Performance Browser Networking. HPBN dit ce que le réseau coûte à vos pages ; celui-ci dit pourquoi le réseau est fait comme ça. C'est le manuel avec lequel des générations d'ingénieurs réseau ont appris, écrit par Larry Peterson et Bruce Davie, deux pointures du domaine, et il a fait une chose rare pour un manuel académique : sa sixième édition est passée en licence libre, texte source sur GitHub, lisible gratuitement en ligne, mise à jour au fil de l'eau.
Un dev web n'a pas besoin de tout ce livre. Mais il y a dedans une poignée de modèles mentaux que rien d'autre ne donne aussi bien, et qui expliquent d'un coup pourquoi HTTP, TCP et le cloud se comportent comme ils le font.
Les idées qui restent
1L'approche système : juger le tout, pas les boîtes
La thèse donne son nom au livre : « la clé de l'approche système est une vue d'ensemble : il faut regarder comment les composants d'un système interagissent pour produire un résultat global », pas empiler des couches étudiées chacune dans son coin. Le livre s'applique sa propre règle : la congestion, qui traverse toutes les couches, y a son chapitre à elle au lieu d'être rangée dans la boîte « TCP ».
Ce regard vaut au-delà du réseau : c'est le même que l'architecture logicielle demande (juger les frontières et les interactions, pas les modules un par un). Un réseau est un système distribué avant d'être un empilement de protocoles.
2Le sablier : tout sur IP, IP sur tout
Dessinez les protocoles en étages : en haut, des dizaines d'applications (web, mail, visio, jeux). En bas, des dizaines de supports physiques (fibre, cuivre, radio, satellite). Au milieu, le col du sablier : IP, tout seul. Tout ce qui est au-dessus parle IP, tout ce qui est en dessous transporte IP. Le livre le pousse jusqu'à l'absurde assumé : « en principe, IP peut tourner sur un réseau qui transporte les messages par pigeons voyageurs ».
Ce col unique est LE choix d'architecture de l'Internet : un contrat minimal au milieu, et l'innovation libre aux deux extrémités. On peut inventer une application ou un support physique sans demander la permission à personne, tant qu'on parle IP. C'est l'inverse d'une plateforme propriétaire.
3Best-effort : le réseau promet peu, exprès
IP ne promet presque rien : un datagramme part, il arrivera peut-être, peut-être en désordre, peut-être en double. Ce dénuement n'est pas une paresse, c'est l'argument bout-en-bout, la phrase la plus influente du livre : une fonction « ne doit pas être fournie dans les couches basses du système, sauf si elle peut y être implémentée complètement et correctement ». La fiabilité parfaite est impossible au milieu du réseau (seuls les deux bouts savent ce qui est arrivé), alors on ne la promet pas au milieu : on la construit aux extrémités, dans TCP, chez vous.
Réseau simple, extrémités intelligentes. C'est ce choix qui rend l'Internet extensible, et c'est le même argument qui revient à chaque débat d'architecture : où mettre l'intelligence ?
4Le tuyau a un volume : bande passante × délai
Le chiffre le plus contre-intuitif du manuel. Un lien se décrit par deux nombres : son débit (combien par seconde) et son délai aller-retour. Leur produit donne le volume du tuyau : combien d'octets sont « en vol » entre les deux bouts à un instant donné. Un lien transcontinental à 1 Gbps avec 100 ms de RTT contient ~400 Mb en vol.
Conséquence : si l'expéditeur n'a le droit d'envoyer que 64 Ko avant d'attendre un accusé (la vieille fenêtre TCP par défaut), il remplit une miette du tuyau puis attend. Le calcul du livre : sur ce lien à 1 Gbps, le débit effectif tombe à 74,1 Mbps. Vous payez un gigabit, la fenêtre vous en laisse 7 %. Toute l'ingénierie des « long fat networks » (fenêtres agrandies via l'extension window scaling) découle de ce seul produit.
5TCP fabrique de la fiabilité avec du chaos
Sous TCP, le réseau peut perdre, dupliquer, réordonner, retarder. Au-dessus, votre code lit un flux d'octets parfait. Entre les deux : des numéros de séquence, des accusés de réception, des retransmissions, et une fenêtre glissante qui pipeline le tout. Le manuel montre ce que ce tour de magie coûte en coins sombres : la connexion fermée reste en quarantaine 240 secondes (TIME_WAIT, le temps que les derniers paquets fantômes meurent), et les numéros de séquence de 32 bits, taillés pour les débits de 1981, font le tour en 3 secondes sur un lien 10 Gbps (d'où les extensions modernes).
La leçon transférable : la fiabilité n'existe pas dans la nature, elle se fabrique, et elle se paie en état à gérer, aux deux bouts.
6La congestion : TCP doit créer des pertes pour trouver la place
Fin des années 1980, l'Internet s'effondre sous sa propre charge (le congestion collapse, que Van Jacobson diagnostique et répare). Sa solution tourne encore dans votre machine : AIMD. Additive Increase, Multiplicative Decrease : tant que ça passe, j'augmente d'un cran par aller-retour ; à la première perte, je divise par deux. La courbe du débit dessine des dents de scie, et c'est voulu : « TCP a besoin de créer des pertes pour trouver la bande passante disponible ». La perte n'est pas un accident, c'est la sonde.
Les évolutions modernes raffinent sans renier : CUBIC (le défaut de Linux) remonte plus vite sur les gros tuyaux, BBR (Google) sonde le délai plutôt que la perte. Le livre note au passage un chiffre qui fâche : en compétition avec BBR, les flux CUBIC peuvent obtenir 100 fois moins de bande passante. L'équité entre algorithmes est un sujet ouvert, pas un acquis.
7L'Internet scale par hiérarchie, et BGP par économie
Comment router entre des milliards de machines sans que chaque routeur connaisse chacune ? En agrégeant : les adresses se regroupent par préfixes (CIDR), les réseaux par systèmes autonomes (AS : un opérateur, une université, un cloud), et le routage se fait à deux niveaux : fin à l'intérieur d'un AS, grossier entre AS.
Entre AS, le protocole s'appelle BGP, et sa vraie nature surprend : il ne cherche PAS le chemin le plus court. Il cherche un chemin conforme aux contrats : un fournisseur route pour ses clients, des pairs échangent leur trafic, et personne ne transporte gratuitement celui des autres. Le routage mondial est un système économique déguisé en protocole. Quand « l'Internet est lent » entre deux continents, la cause est parfois un contrat, pas un câble.
8Les applications réinventent toutes le même motif
Le dernier chapitre passe en revue mail, web, visio, CDN, et un motif se répète : une hiérarchie de noms (DNS, qui sous-tend tout le reste), un dialogue requête-réponse, et du cache le plus près possible de l'utilisateur. Les CDN y gagnent leur explication la plus propre : des serveurs partout, et un hachage cohérent pour décider, sans coordination centrale, quel serveur détient quoi.
Et l'histoire d'HTTP y est racontée en trois actes qu'on connaît par cœur une fois qu'on a lu HPBN : 13 connexions TCP pour une page et ses 12 icônes en HTTP/1.0, les connexions persistantes en 1.1, le multiplexage en HTTP/2, QUIC sous HTTP/3. Les deux livres se répondent exactement ici.
« We reject kings, presidents, and voting. We believe in rough consensus and running code. » (David Clark, IETF). Comprendre : nous rejetons les rois, les présidents et le vote. Nous croyons au consensus approximatif et au code qui tourne. Le manuel cite la devise en expliquant comment l'Internet se gouverne : pas de comité qui vote des standards sur papier, des implémentations qui tournent et un consensus approximatif. C'est la culture d'ingénierie qui a produit tout le reste du livre.
Mon avis, honnêtement
Je le dis d'entrée : je suis dev web, pas ingénieur réseau, et je n'ai pas le niveau pour juger ce manuel en expert. Voilà ce que le livre m'a fait : des choses que je subissais depuis des années (le TIME_WAIT qui traîne, les débits qui plafonnent sous le forfait, le CDN « magique ») ont cessé d'être des superstitions. Le sablier, le bout-en-bout et le produit bande passante × délai sont trois images que je ne désapprendrai pas.
Le reproche honnête : c'est un manuel d'université, avec la densité et la sécheresse du genre. On y croise des calculs de CRC et des automates que personne ne me demandera jamais. La lecture intégrale est un contresens pour un dev web : chapitres 1, 5, 6, le début du 3-4 et le 9, le reste en référence. Et l'ironie des auteurs eux-mêmes vaut citation : sur la transition IPv6, prévue temporaire, « il est douteux qu'ils aient anticipé que la période de transition approcherait son trentième anniversaire ».
Dans le duo avec HPBN : lisez HPBN d'abord, il part de vos pages et descend. Celui-ci monte depuis les câbles, et il répond aux « pourquoi » que HPBN laisse ouverts. Sa sixième édition libre, maintenue sur GitHub avec des exemples Netflix et des chapitres sur CUBIC et BBR, est un cadeau au métier : le manuel de référence est devenu un bien commun.
Odilon
Pour qui ?
Lisez-le si
- HPBN vous a plu et vous voulez le « pourquoi » sous le « combien »
- Vous touchez à l'infra (cloud, CDN, VPN) et le vocabulaire réseau reste du folklore
- Vous aimez comprendre les systèmes par leurs choix de conception, pas par leurs commandes
- Vous cherchez UN manuel réseau de référence gratuit et à jour
Passez si
- Vous n'avez pas encore lu HPBN : commencez par lui, il parle votre langue de dev web
- Vous voulez du directement applicable demain matin : ce livre explique, il n'outille pas
- Les manuels académiques vous tombent des mains : la densité est réelle
Pour aller plus loin
La fiche jumelle, côté pages web : High Performance Browser Networking, qui part de vos pages et mesure ce que le réseau leur coûte, quand ce livre explique pourquoi le réseau est fait comme ça.
Et pour voir ces couches à l'œuvre dans vos propres requêtes : le cours HTTP gratuit, plus le cours sécurité web pour le versant TLS.
Commentaires (0)