HTTP/2 et HTTP/3 : le multiplexé

Prérequis : cours 7.1 et 6.2 (QUIC).

Pourquoi

HTTP/1.1 ouvre une connexion par ressource (6 en parallèle max par navigateur à l'époque) : lent par construction. HTTP/2 et 3 multiplexent tout sur une connexion — comprendre la différence explique bien des waterfalls réseau.

Concepts

• HTTP/1.1 : texte, une requête à la fois par connexion (pipelining mort-né), 6 connexions max → waterfall, domain sharding (éparpiller sur des sous-domaines pour paralléliser — anti-pattern aujourd'hui).
• HTTP/2 : binaire, multiplexé (requêtes entremêlées sur une connexion), priorités, compression des headers (HPACK). Même URLs, même sémantique — juste le transport qui change. Head-of-line blocking TCP restant (un paquet perdu bloque tout le multiplex).
• HTTP/3 : même sémantique sur QUIC/UDP : plus de head-of-line TCP, handshake 0-1 RTT, migration de réseau (4G→WiFi sans tout casser). Pré-requis : 443/udp ouvert (cf. cours 6.2).

Exemple : voir ce qu'on parle

curl -sI --http2 https://example.com        # négocie h2 si dispo
curl -sI --http3 https://example.com        # teste h3 (curl récent + udp ouvert)
# DevTools → Réseau → colonne Protocole : h1, h2, h3 par requête

Cas réel

Site « lent sur mobile mais rapide au bureau » : HTTP/1.1 + 80 ressources + latence 4G = waterfall catastrophique. Passage en HTTP/2 (souvent une option du proxy) : -60 % au chargement sans toucher au code.

Pièges

• Activer h2/h3 sans vérifier : tester au protocole réel (DevTools), pas « ça devrait ».
• Optimisations 1.1 (sharding, sprites, concaténation) conservées sous h2 : contre-productives, à démonter.
• h3 sans 443/udp : fallback silencieux et lent vers TCP (cf. 6.2).

À retenir

1.1 = une à la fois, 2 = multiplexé TCP, 3 = multiplexé QUIC ; vérifier le protocole réel ; démonter les vieilles optimisations.