Quelles sont les différences entre HTTP/1.1, HTTP/2 et HTTP/3 ?

Question

IT Interview Practice · Accepted Answer

Les trois délivrent la même sémantique HTTP (méthodes, headers, codes de statut) mais diffèrent dans *la façon* dont ils déplacent les octets sur le fil — chaque version corrige un goulot d'étranglement de la précédente. Le thème est la **suppression du head-of-line (HOL) blocking**, où une requête bloquée retient les autres.

```text
HTTP/1.1  over TCP     one request at a time per connection
  conn ──[req A]──[req B]──[req C]──▶   B waits for A (HOL blocking at HTTP layer)

HTTP/2    over TCP     many streams multiplexed on ONE connection
  conn ══[A|B|C interleaved]══▶        but a lost TCP packet stalls ALL streams
                                       (HOL blocking moves down to TCP)

HTTP/3    over QUIC (UDP)   independent streams, per-stream delivery
  conn ══[A][B][C]══▶                  a lost packet stalls only its own stream
```

**HTTP/1.1** envoie une requête à la fois par connexion ; les navigateurs contournent cela en ouvrant ~6 connexions parallèles par host, et les headers texte sont envoyés non compressés. **HTTP/2** ajoute le **multiplexing** — de nombreux **streams** concurrents sur une seule connexion — plus le binary framing, la compression des headers (HPACK) et le server push. Mais parce qu'il tourne toujours sur TCP, un seul paquet perdu bloque *chaque* stream jusqu'à sa retransmission : le HOL blocking s'est simplement déplacé de la couche HTTP vers TCP.

**HTTP/3** résout cela en tournant sur **QUIC**, un nouveau transport construit sur **UDP**. QUIC implémente les streams lui-même, donc une perte sur un stream ne bloque pas les autres. Il fusionne aussi les handshakes du transport et de TLS (1-RTT, souvent 0-RTT à la reprise) pour un établissement de connexion plus rapide, et prend en charge la **connection migration** pour qu'une session survive à un changement de réseau (Wi-Fi → cellulaire).

## Pourquoi c'est important

C'est une question de niveau intermédiaire très appréciée parce que la réponse est une histoire de *problème → correction → nouveau problème → correction*, qui est exactement la façon dont un bon ingénieur raisonne sur des systèmes en évolution. L'idée clé que les recruteurs recherchent est la compréhension du **head-of-line blocking à deux couches** : HTTP/2 l'a résolu à la couche application mais restait piégé sous TCP, et HTTP/3 a dû changer le transport lui-même pour finir le travail. C'est aussi pratique : le savoir guide de vraies décisions sur la réutilisation de connexion, l'opportunité de continuer à sharder les domaines, et ce que vous gagnez en activant HTTP/3 sur votre CDN.

Pourquoi c'est important

Questions connexes