Quali sono le differenze tra HTTP/1.1, HTTP/2 e HTTP/3?

Question

IT Interview Practice · Accepted Answer

Tutti e tre forniscono la stessa semantica HTTP (metodi, header, status code) ma differiscono nel *modo* in cui spostano i byte sul filo — ogni versione risolve un collo di bottiglia della precedente. Il tema è **eliminare l'head-of-line (HOL) blocking**, in cui una richiesta bloccata trattiene le altre.

```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** invia una richiesta per connessione alla volta; i browser aggirano il problema aprendo ~6 connessioni parallele per host, e gli header di testo sono inviati non compressi. **HTTP/2** aggiunge il **multiplexing** — molti **stream** concorrenti su una singola connessione — più binary framing, compressione degli header (HPACK) e server push. Ma poiché gira ancora su TCP, un singolo pacchetto perso blocca *ogni* stream finché non viene ritrasmesso: l'HOL blocking si è semplicemente spostato dal livello HTTP giù al TCP.

**HTTP/3** risolve tutto ciò girando su **QUIC**, un nuovo transport costruito su **UDP**. QUIC implementa da sé gli stream, quindi la perdita su uno stream non blocca gli altri. Fonde inoltre gli handshake di transport e TLS (1-RTT, spesso 0-RTT alla ripresa) per un setup di connessione più veloce, e supporta la **connection migration** così che una sessione sopravviva a un cambio di rete (Wi-Fi → cellulare).

## Perché è importante

Questa è una domanda di livello middle molto amata perché la risposta è una storia di *problema → soluzione → nuovo problema → soluzione*, che è esattamente il modo in cui un bravo ingegnere ragiona sui sistemi in evoluzione. L'intuizione chiave che chi conduce il colloquio cerca è capire l'**head-of-line blocking a due livelli**: HTTP/2 lo ha risolto a livello applicativo ma restava intrappolato sotto il TCP, e HTTP/3 ha dovuto cambiare il transport stesso per portare a termine il lavoro. È anche pratico: saperlo guida decisioni reali sul riuso delle connessioni, se abbia ancora senso fare lo shard dei domini, e cosa guadagni abilitando HTTP/3 sul tuo CDN.

Perché è importante

Domande correlate