Français
Menu

HTTP/1.1 vs HTTP/2 vs HTTP/3 : transport, multiplexage, blocage en tête de ligne, compression d’en-têtes, chiffrement

Les trois versions partagent la même sémantique HTTP (RFC 9110), comme les méthodes, les codes d’état et les champs d’en-tête ; ce qui diffère, c’est le format et le transport utilisés pour les acheminer. HTTP/1.1 (RFC 9112) envoie des messages texte sur TCP et renvoie les réponses une par une sur chaque connexion. HTTP/2 (RFC 9113) découpe les messages en trames binaires et multiplexe plusieurs flux sur une seule connexion TCP. HTTP/3 (RFC 9114) utilise QUIC (RFC 9000), qui fonctionne sur UDP et prend en charge dans le transport le multiplexage des flux et le chiffrement TLS 1.3. Cela évite le blocage en tête de ligne (head-of-line blocking) de TCP, où la perte d’un seul paquet bloque tous les flux.

CritèreHTTP/1.1HTTP/2HTTP/3
SpécificationRFC 9112 (sémantique dans la RFC 9110, commune aux trois versions)RFC 9113RFC 9114 (QUIC : RFC 9000)
TransportTCPTCPQUIC (fonctionne sur UDP)
Format des messagesTexte : une ligne de requête et des champs d’en-tête écrits ligne par ligneTrames binairesTrames binaires (sur des flux QUIC)
MultiplexageAucun : une connexion traite une requête et une réponse à la fois, si bien qu’une récupération en parallèle exige d’ouvrir plusieurs connexionsPlusieurs flux sont envoyés en parallèle sur une seule connexion TCPPlusieurs flux QUIC sont envoyés en parallèle ; les flux sont gérés par le transport
Blocage en tête de ligneSe produit au niveau de la couche HTTP : sur une même connexion, la réponse suivante ne peut pas être envoyée avant la fin de la précédente (même avec le pipelining, les réponses reviennent dans l’ordre des requêtes)Résolu au niveau de la couche HTTP, mais comme TCP livre les octets strictement dans l’ordre, la perte d’un paquet fait attendre tous les flux jusqu’à la retransmissionQUIC gère l’ordre par flux : une perte n’affecte que les flux dont des données ont été perdues
Compression des en-têtesAucune (le corps peut être compressé, mais les en-têtes sont envoyés en texte clair)HPACK (RFC 7541)QPACK (RFC 9204), une adaptation de HPACK qui fonctionne même lorsque les flux arrivent dans le désordre
ChiffrementFacultatif : https utilise TLS, tandis que http est envoyé en clairLa spécification définit à la fois une variante sur TLS (h2) et une variante en clair (h2c) ; sur TLS, elle exige au minimum TLS 1.2. Les principaux navigateurs ne prennent en charge HTTP/2 que sur TLSObligatoire : TLS 1.3 est intégré à QUIC et il n’existe pas de mode en clair
Allers-retours pour établir la connexionUn pour TCP, plus un autre avec TLS 1.3 : la requête part après deux allers-retours au totalComme HTTP/1.1 (deux allers-retours pour TCP et TLS)QUIC regroupe les poignées de main de transport et de chiffrement en un seul aller-retour ; le 0-RTT, qui envoie des données dès le tout premier envoi, est aussi disponible avec les serveurs déjà contactés
Lorsque le réseau changeUne connexion TCP est identifiée par les adresses et ports source et destination : un changement d’adresse IP impose une nouvelle connexionComme HTTP/1.1QUIC identifie les connexions par des identifiants de connexion : la même connexion peut se poursuivre lors du passage du Wi-Fi au réseau mobile (migration de connexion)

Les valeurs indiquées sont des ordres de grandeur typiques et varient selon la génération de procédé et le produit.

Quand choisir l'un ou l'autre ?

HTTP/1.1
La version de base que tout client et tout serveur peuvent utiliser. Elle sert aussi aux communications internes des systèmes de serveurs et aux interfaces web simples, comme les pages de réglage des appareils.
HTTP/2
Lorsqu’une page web qui charge de nombreux petits fichiers doit être servie efficacement sur une seule connexion. Comme il fonctionne sur les réseaux qui bloquent UDP, c’est la solution de repli même pour les sites qui prennent en charge HTTP/3.
HTTP/3
Lorsqu’on veut éviter que les flux se bloquent mutuellement sur des liaisons à pertes et à forte latence, comme les réseaux mobiles, ou accélérer l’établissement des connexions. Certains réseaux bloquent UDP : les sites prennent donc généralement aussi en charge HTTP/2 ou HTTP/1.1.

Questions fréquentes

HTTP/2 n’a-t-il pas éliminé le blocage en tête de ligne ?

Il l’a éliminé au niveau de la couche HTTP, mais il subsiste au niveau de TCP. HTTP/2 multiplexe plusieurs flux sur une seule connexion TCP, mais TCP ne sait pas à quel flux appartiennent les données et livre les octets strictement dans l’ordre. Lorsqu’un paquet est perdu, les données de flux sans rapport sont donc elles aussi retenues pour l’application réceptrice jusqu’à l’arrivée de la retransmission. Avec HTTP/3, QUIC gère l’ordre par flux : seuls les flux contenant les données perdues doivent attendre.

Comment un client sait-il qu’un serveur prend en charge HTTP/3 ?

HTTP/3 utilise UDP : il doit donc être lancé indépendamment d’une connexion TCP. Généralement, le client se connecte d’abord en HTTP/1.1 ou HTTP/2 sur TCP, et le serveur annonce dans l’en-tête de réponse Alt-Svc que HTTP/3 (h3) est disponible. Le client utilise ensuite QUIC pour les connexions suivantes. Par ailleurs, le choix entre HTTP/1.1 et HTTP/2 sur TLS est déterminé par ALPN pendant la poignée de main TLS.

Le 0-RTT de HTTP/3 présente-t-il des précautions ?

Oui. Les données envoyées en 0-RTT peuvent être enregistrées par un attaquant et renvoyées (attaque par rejeu). Avec le 0-RTT, il faut donc être prudent, par exemple en n’envoyant que des requêtes comme GET, sans danger si elles sont reçues plusieurs fois.

Faut-il réécrire les applications web pour HTTP/2 ou HTTP/3 ?

Dans la plupart des cas, non. La signification des méthodes, des codes d’état et des champs d’en-tête est commune aux trois versions (RFC 9110) ; seule la manière de les acheminer diffère. La version étant choisie par connexion, une architecture courante fait accepter HTTP/2 ou HTTP/3 aux navigateurs par un proxy inverse ou un CDN, qui dialogue en HTTP/1.1 avec les serveurs d’applications situés derrière.

Vérifier vos connaissances

Quelle combinaison donne correctement les éléments de la première ligne (la ligne de requête) d'une requête HTTP/1.1 ?

  1. ALa méthode, la cible de la requête (un chemin, etc.) et la version de HTTP
  2. BLa version de HTTP, le code d'état et une courte expression qui en indique la raison
  3. CL'adresse IP source, le numéro de port de destination et la méthode
Afficher la réponse et l'explication

Réponse : A. La méthode, la cible de la requête (un chemin, etc.) et la version de HTTP

Une requête HTTP se compose, dans cet ordre, de la ligne de requête, des en-têtes (un « Nom: valeur » par ligne), d'une ligne vide et du corps. Par exemple, « GET /docs/index.html HTTP/1.1 » est une ligne qui demande /docs/index.html avec la méthode GET. En HTTP/1.1, l'en-tête Host doit aussi être envoyé, pour que le serveur sache à quel site s'adresse la requête même lorsque plusieurs sites sont hébergés sur la même adresse IP. La première ligne d'une réponse est la ligne d'état, qui indique la version, le code d'état et la phrase de raison, comme dans « HTTP/1.1 200 OK ».

Quelle description de HTTP/2 et HTTP/3 est correcte ?

  1. AHTTP/2 peut traiter plusieurs requêtes en parallèle sur une seule connexion TCP, mais la perte d'un paquet peut faire attendre les autres flux ; HTTP/3 réduit ce problème avec QUIC, sur UDP
  2. BHTTP/2 est une version qui utilise des messages au même format texte que HTTP/1.1 et ouvre en parallèle une nouvelle connexion TCP par requête pour recevoir plusieurs ressources en même temps
  3. CHTTP/3 fonctionne sur TCP comme HTTP/2 et ne change que la méthode de compression des en-têtes ; l'effet d'une perte de paquet est le même qu'avec HTTP/2, et UDP n'est pas utilisé
Afficher la réponse et l'explication

Réponse : A. HTTP/2 peut traiter plusieurs requêtes en parallèle sur une seule connexion TCP, mais la perte d'un paquet peut faire attendre les autres flux ; HTTP/3 réduit ce problème avec QUIC, sur UDP

Même HTTP/1.1 peut réutiliser une connexion TCP grâce aux connexions persistantes (keep-alive), mais sur une connexion les réponses sont reçues une par une dans l'ordre ; les navigateurs ouvraient donc plusieurs connexions en parallèle. HTTP/2 découpe les messages en trames binaires et multiplexe plusieurs flux sur une seule connexion TCP pour les envoyer en parallèle. Cependant, TCP livre son flux d'octets dans l'ordre : lorsqu'un seul paquet est perdu, les données de flux sans rapport doivent aussi attendre l'arrivée de la retransmission (blocage en tête de ligne, head-of-line blocking). HTTP/3 utilise QUIC, qui fonctionne sur UDP et gère l'ordre flux par flux, si bien que l'effet d'une perte reste limité au flux concerné.

On récupère, l'un après l'autre, un fichier HTML et les quatre images qu'il référence sur un serveur web dont le RTT est de 40 ms. On suppose que l'établissement d'une connexion TCP prend un aller-retour et que chaque requête et sa réponse prennent un aller-retour, et l'on néglige le temps de transfert des données, le temps de traitement du serveur, TLS et la fermeture des connexions. Quelle est la différence de durée totale entre l'ouverture d'une nouvelle connexion TCP pour chaque objet et la réutilisation d'une seule connexion TCP (connexion persistante) ?

  1. A160 ms
  2. B200 ms
  3. C400 ms
Afficher la réponse et l'explication

Réponse : A. 160 ms

Il y a cinq objets au total. Avec une nouvelle connexion à chaque fois, chaque objet demande deux allers-retours, l'un pour établir la connexion et l'autre pour la requête et la réponse, soit 5 × 2 × 40 = 400 ms. Avec une connexion persistante, la connexion n'est établie qu'une fois au début, puis il ne reste que les cinq requêtes et réponses, soit (1 + 5) × 40 = 240 ms. La différence vaut 400 − 240 = 160 ms, ce qui correspond aux quatre établissements de connexion économisés. En HTTP/1.1, la connexion persistante est le comportement par défaut.

  1. Un client établit une nouvelle connexion HTTPS (TLS 1.3 sur TCP) vers un serveur web dont le temps aller-retour (RTT) est de 100 ms. Quelle durée est la plus proche du temps nécessaire jusqu'au début de la réception de la réponse à la première requête ? La résolution DNS est déjà faite, et l'on néglige le temps de traitement du serveur et le temps de transfert des données.
  2. Parmi les propositions suivantes, laquelle est protégée par HTTPS (HTTP protégé par TLS) ?

Questions d'entraînement sur Bases des technologies web

Termes clés expliqués

HTTP (Hypertext Transfer Protocol)
Protocole de la couche application qui sert à échanger du HTML, des images et des données entre un navigateur web et un serveur web, entre autres. Le client envoie une requête composée d'une méthode, d'une URL, d'en-têtes et d'un corps, et le serveur renvoie une réponse composée d'un code d'état, d'en-têtes et d'un corps. Le protocole est sans état : un état comme la connexion d'un utilisateur est conservé au moyen de cookies, entre autres. HTTP/1.1 utilise un format texte et des connexions persistantes, HTTP/2 multiplexe plusieurs flux sur une seule connexion TCP, et HTTP/3 utilise QUIC sur UDP. HTTP protégé par TLS s'appelle HTTPS.
TLS (Transport Layer Security)
Protocole qui chiffre la communication, détecte les falsifications et authentifie les serveurs à l'aide de certificats. HTTPS est HTTP protégé par TLS.
Three-way handshake (établissement en trois temps)
Procédure qui établit une connexion TCP. 3 échanges, le SYN du client, le SYN+ACK du serveur et l'ACK du client, confirment le numéro de séquence initial de chaque partie.
Méthode HTTP
Mot qui indique, dans une requête HTTP, l'opération que l'on veut effectuer sur une ressource. On trouve notamment GET (lecture), HEAD (lecture des seuls en-têtes), POST (traitement ou création), PUT (remplacement), PATCH (mise à jour partielle), DELETE (suppression) et OPTIONS (interrogation des fonctions disponibles). Une méthode qui ne modifie pas l'état du serveur est dite « sûre », et une méthode qui laisse le même état qu'on l'envoie une fois ou plusieurs fois est dite « idempotente ». GET est sûre et idempotente, PUT et DELETE sont idempotentes mais pas sûres, et POST n'est en général ni l'une ni l'autre.
Code d'état HTTP
Nombre à trois chiffres placé sur la première ligne d'une réponse HTTP, qui indique le résultat de la requête. Le chiffre des centaines donne la classe : 1xx information, 2xx succès (200 OK, 201 Created, 204 No Content), 3xx redirection (301 Moved Permanently, 302 Found, 304 Not Modified), 4xx erreur du client (400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found) et 5xx erreur du serveur (500 Internal Server Error, 503 Service Unavailable). 401 s'utilise lorsque les informations d'authentification sont absentes ou incorrectes, et 403 lorsque l'utilisateur est authentifié mais n'a pas le droit d'accès.
Proxy inverse (reverse proxy)
Serveur placé devant les serveurs web, qui reçoit les requêtes des utilisateurs à la place des serveurs et les relaie vers un ou plusieurs serveurs situés derrière lui. Il assure des rôles comme le traitement cryptographique centralisé de HTTPS (terminaison TLS), la conservation et le renvoi des réponses fréquemment demandées, la répartition de la charge entre plusieurs serveurs et le masquage de l'organisation des serveurs placés derrière lui. Il se distingue du proxy direct (forward proxy), placé du côté des utilisateurs et qui se connecte aux sites externes à leur place, par sa position et par ce qu'il protège.

Comparatifs associés