High Performance Browser Networking

1La vitesse est une fonctionnalité, et elle se paie en millisecondes

« Speed is a feature. » Pas un confort : une fonctionnalité, avec des chiffres de chiffre d'affaires derrière. L'exemple le plus parlant du livre : Bing a mesuré qu'un délai artificiel de 2 000 ms faisait chuter le revenu par utilisateur de 4,3 %. Et la perception humaine a des seuils précis, que le livre pose en tableau : sous 100 ms, c'est instantané. Entre 300 et 1 000 ms, « la machine travaille ». Au-delà de 1 000 ms, l'esprit du visiteur est déjà ailleurs. La règle du pouce du livre : afficher quelque chose en moins de 250 ms.

À l'autre bout de l'échelle, la finance donne le prix exact d'une milliseconde : le câble Hibernia Express, 300 M$ de fibre posée entre New York et Londres pour gagner ~5 ms sur les liaisons existantes. 60 M$ la milliseconde.

2La bande passante ne compte (presque) plus

Le test fondateur, mené par Mike Belshe (le futur créateur de SPDY) : on fait varier la connexion et on chronomètre le chargement d'une page. Passer de 1 à 2 Mbps divise presque le temps par deux. Mais passer de 5 à 10 Mbps ne gagne que ~5 %. La courbe s'aplatit : au-delà de quelques Mbps, votre fibre n'accélère plus rien.

La latence, elle, ne s'aplatit jamais : chaque 20 ms gagnées améliorent le chargement linéairement. Pourquoi ? Parce qu'une page n'est pas UN téléchargement : c'est ~90 requêtes vers 15 hôtes (la page moyenne de 2013 : 1 311 Ko). Des dizaines de petits allers-retours, et chaque aller-retour paie la distance. « Bandwidth doesn't matter, much. » (la bande passante ne compte pas, ou si peu). C'est ce constat chiffré qui a lancé SPDY, donc HTTP/2.

Et la latence a un plancher physique : la lumière dans la fibre avance à ~200 000 km/s (l'indice de réfraction du verre la freine d'un tiers). New York-Londres : 56 ms aller-retour, incompressible. On peut toujours acheter plus de bande passante ; on ne peut pas acheter la vitesse de la lumière.

3Chaque connexion neuve paie un péage

Avant d'envoyer le premier octet utile, TCP exige un aller-retour de politesse : le handshake (SYN, SYN-ACK, ACK : « je veux parler », « d'accord, moi aussi », « alors on parle »). Puis le slow start : TCP ne connaît pas la capacité du chemin, alors il démarre prudemment (aujourd'hui 10 segments, ~14 Ko) et double à chaque aller-retour. Une connexion neuve est donc lente PAR CONSTRUCTION, quelle que soit votre fibre.

L'exemple chiffré du livre : servir 64 Ko entre New York et Londres (RTT 56 ms) prend 264 ms sur une connexion neuve, 96 ms sur une connexion réutilisée. Presque trois fois plus vite, pour le même fichier et le même réseau. La leçon opérationnelle tient en un mot : réutiliser (keepalive, pools de connexions, CDN qui terminent le TLS près de l'utilisateur).

4TLS n'est plus cher, mais il se règle

Le mythe « HTTPS, ça rame » est mort en janvier 2010, quand Gmail est passé tout-HTTPS. Adam Langley (Google) : moins de 1 % de CPU, moins de 10 Ko de mémoire par connexion, moins de 2 % de surcoût réseau. « SSL/TLS n'est plus coûteux en calcul », et l'auteur ajoute : si vous arrêtez de lire ici, retenez au moins ça.

Le vrai coût de TLS n'est pas le calcul, c'est encore et toujours les allers-retours : un handshake complet ajoute 2 RTT avant le premier octet. Tout le travail d'optimisation consiste à les raboter : reprise de session (le client et le serveur se souviennent l'un de l'autre : 1 RTT), OCSP stapling (le serveur joint la preuve de validité de son certificat au lieu de laisser le navigateur aller la chercher, ce qui coûtait jusqu'à +350 ms mesurés par Firefox). Depuis le livre, TLS 1.3 (2018) a intégré la leçon dans le protocole : 1 RTT par défaut.

5Pour la batterie, il n'existe pas de « petite requête »

Sur mobile, la puce radio est le deuxième consommateur de batterie après l'écran, et elle ne se paie pas à l'octet : elle se paie à l'allumage. Passer de veille à émission coûte ~10 joules par cycle, quel que soit le contenu. Le calcul du livre : une app qui polle son serveur toutes les minutes brûle ~600 joules par heure, environ 3 % de la batterie totale, par heure et par app, pour transporter trois fois rien. « There is no such thing as a "small request" as far as the battery is concerned. »

La parade : grouper. Précharger en une rafale puis laisser la radio dormir, plutôt que du goutte-à-goutte qui la réveille sans fin. C'est le « je charge tout d'un coup » assumé, à l'inverse du réflexe serveur.

6HTTP/1.1, l'art du contournement

HTTP/1.1 a un défaut structurel : une connexion ne sert qu'une réponse à la fois (le head-of-line blocking : la première réponse de la file bloque toutes les suivantes). Les navigateurs compensent en ouvrant 6 connexions par hôte, et les devs ont inventé toute une culture du contournement : domain sharding (éclater ses assets sur plusieurs domaines pour obtenir plus de connexions), concaténation des JS, sprites d'images, inlining. Le livre les documente en les appelant ce qu'ils sont : des pansements.

Deux chiffres pour mesurer le mal : 15 octets de JSON coûtent 352 octets d'en-têtes HTTP (96 % d'emballage), et Apple a gagné +300 % de débit dans iTunes juste en activant keepalive et pipelining (WWDC 2012). D'où la maxime la plus durable du chapitre : « The fastest request is a request not made. » (la requête la plus rapide est celle qu'on n'envoie pas).

7HTTP/2 change les règles : désapprendre est une optimisation

HTTP/2 (2015, issu de SPDY) garde la sémantique (GET, statuts, en-têtes) et change la tuyauterie : une seule connexion par origine, où toutes les requêtes et réponses voyagent découpées en trames entrelacées. Le head-of-line blocking HTTP disparaît. Mesure de Patrick McManus (Firefox) : 74 % des connexions HTTP/1 ne portent qu'UNE transaction, contre 25 % en HTTP/2.

La conséquence, et c'est l'idée la plus précieuse du livre : les contournements de l'idée 6 deviennent des ANTI-patterns. Le sharding casse la connexion unique, la concaténation casse le cache granulaire, le spriting fait retélécharger 100 icônes pour une modifiée. « The best optimization for HTTP/1.x is to deploy HTTP/2. » (la meilleure optimisation pour HTTP/1.x, c'est de déployer HTTP/2). Une optimisation peut avoir une date de péremption : ce que le protocole répare, votre outillage doit le désapprendre.

8Le temps réel se choisit, il ne se bricole pas

Pour pousser une donnée du serveur vers la page, le bricolage naturel est le polling : redemander toutes les N secondes. Le livre le chiffre : 10 000 clients qui pollent toutes les 60 secondes consomment ~1,13 Mbps en continu, même quand il n'y a RIEN à livrer. Du vide, emballé dans des en-têtes.

Les vrais outils existent, du plus simple au plus puissant : SSE (un flux texte unidirectionnel serveur→client, auto-reconnexion gratuite), WebSocket (bidirectionnel, binaire, mais on perd le cache et la compression HTTP : tout est à votre charge), WebRTC (pair-à-pair sur UDP, pour l'audio/vidéo où une image en retard est une image bonne à jeter). Le choix est un arbitrage, pas une échelle de modernité : le plus simple qui couvre le besoin gagne.