Care sunt diferențele dintre HTTP/1.1, HTTP/2 și HTTP/3?

Question

IT Interview Practice · Accepted Answer

Toate cele trei livrează aceeași semantică HTTP (metode, header-e, coduri de status), dar diferă în *modul* în care mută bytes pe fir — fiecare versiune rezolvă un blocaj al celei anterioare. Tema este **eliminarea head-of-line (HOL) blocking**, unde o cerere blocată le ține pe loc pe celelalte.

```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** trimite câte o cerere pe conexiune odată; browserele ocolesc asta deschizând ~6 conexiuni paralele per host, iar header-ele text sunt trimise necomprimate. **HTTP/2** adaugă **multiplexing** — multe **stream**-uri concurente peste o singură conexiune — plus binary framing, comprimarea header-elor (HPACK) și server push. Dar pentru că încă rulează pe TCP, un singur pachet pierdut blochează *fiecare* stream până la retransmisie: HOL blocking-ul s-a mutat pur și simplu de la stratul HTTP jos la TCP.

**HTTP/3** rezolvă asta rulând pe **QUIC**, un transport nou construit pe **UDP**. QUIC implementează el însuși stream-urile, deci pierderea pe un stream nu le blochează pe celelalte. De asemenea, îmbină handshake-urile de transport și TLS (1-RTT, adesea 0-RTT la reluare) pentru o stabilire mai rapidă a conexiunii și susține **connection migration**, astfel încât o sesiune supraviețuiește unei schimbări de rețea (Wi-Fi → celular).

## De ce contează

Aceasta este o întrebare favorită de nivel middle pentru că răspunsul este o poveste de *problemă → soluție → problemă nouă → soluție*, exact modul în care un inginer puternic raționează despre sisteme în evoluție. Intuiția cheie pe care o caută intervievatorii este înțelegerea **head-of-line blocking la două straturi**: HTTP/2 l-a rezolvat la stratul aplicație, dar rămânea prins sub TCP, iar HTTP/3 a trebuit să schimbe însuși transportul pentru a termina treaba. Este și practic: a ști asta ghidează decizii reale despre reutilizarea conexiunilor, dacă mai merită să faci sharding pe domenii și ce câștigi activând HTTP/3 la CDN-ul tău.

De ce contează

Întrebări conexe