HTTP/1.1, HTTP/2 et HTTP/3 : les différences qu'un opérateur remarque

Ce que c'est

HTTP/1.1 (RFC 9112) encode les messages en texte : une ligne de requête, des lignes d'en-tête, un corps optionnel délimité par Content-Length ou par un encodage de transfert fragmenté (chunked). Les connexions sont persistantes par défaut, mais les réponses doivent revenir dans l'ordre des requêtes, ce qui force les clients à attendre ou à ouvrir plusieurs connexions. HTTP/2 (RFC 9113) conserve la même sémantique mais utilise des trames binaires, de nombreux flux concurrents sur une seule connexion, une compression d'en-têtes HPACK et un contrôle de flux par flux. Il se négocie via ALPN sous le nom h2 en TLS ; le h2c en clair n'existe qu'avec une connaissance préalable, la RFC dépréciant le chemin Upgrade. HTTP/3 (RFC 9114) porte la même sémantique sur QUIC, un transport basé sur UDP avec TLS 1.3 intégré ; chaque flux de requête est livré indépendamment, si bien qu'un paquet perdu ne retarde que son propre flux, et les en-têtes utilisent QPACK, qui limite le blocage de tête de ligne que la compression pourrait causer. Les clients apprennent l'existence d'un point de terminaison HTTP/3 via un en-tête Alt-Svc (RFC 9114) ou un enregistrement DNS HTTPS (RFC 9460), et devraient revenir à du HTTP basé sur TCP si la connexion QUIC échoue, par exemple parce qu'UDP est bloqué.

Pourquoi c'est important

La version change ce que l'opérateur doit configurer et peut observer. HTTP/2 concentre le trafic d'un navigateur sur une seule connexion, si bien qu'une réinitialisation de connexion ou une retransmission TCP lente bloque tous les flux à la fois ; les limites de connexion par client signifient autre chose qu'avec HTTP/1.1. HTTP/3 implique que le port UDP annoncé (la RFC 9114 autorise n'importe quel port ; Alt-Svc le nomme toujours explicitement) doit être ouvert dans les pare-feux, les groupes de sécurité et les répartiteurs de charge, et les captures de paquets montrent de l'UDP chiffré plutôt que des enregistrements TLS lisibles.

Comment l'appliquer

• Terminer HTTP/2 et HTTP/3 en périphérie (reverse proxy ou répartiteur de charge) et parler HTTP/1.1 aux serveurs d'application, sauf s'ils tirent parti du multiplexage ; cela garde simple la gestion des connexions côté application.
• N'annoncer HTTP/3 qu'après avoir testé l'accessibilité UDP depuis l'extérieur ; un Alt-Svc erroné coûte aux clients une tentative échouée avant qu'ils ne se replient.
• Conserver les limites par flux (SETTINGS_MAX_CONCURRENT_STREAMS) et les limites de corps de requête dans le proxy ; le multiplexage permet à un seul client d'ouvrir de nombreuses requêtes à moindre coût.
• Journaliser le protocole négocié par requête afin de pouvoir isoler dans le journal d'accès les problèmes propres à une version.

Pièges

Les noms d'en-têtes sont en minuscules en HTTP/2 et HTTP/3, et certains en-têtes (Connection, Transfer-Encoding) sont interdits ; un middleware qui réécrit les en-têtes doit gérer les deux formes. La RFC 9113 note que le chemin Upgrade en clair n'a jamais été largement déployé ; les navigateurs ne parlent HTTP/2 qu'en TLS avec ALPN, si bien que h2c reste une option serveur-à-serveur. Les identifiants de connexion QUIC permettent à un client de changer d'adresse en cours de connexion, ce qu'un équilibrage de charge sans état basé sur le 4-tuple ne gère pas.