Jakie są różnice między HTTP/1.1, HTTP/2 a HTTP/3?

Question

IT Interview Practice · Accepted Answer

Wszystkie trzy dostarczają tę samą semantykę HTTP (metody, nagłówki, kody statusu), ale różnią się *tym, jak* przenoszą bajty po drucie — każda wersja naprawia wąskie gardło poprzedniej. Motywem przewodnim jest **usuwanie head-of-line (HOL) blocking**, gdy jedno utknięte żądanie wstrzymuje pozostałe.

```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** wysyła jedno żądanie na połączenie naraz; przeglądarki obchodzą to, otwierając ~6 równoległych połączeń na host, a tekstowe nagłówki są wysyłane bez kompresji. **HTTP/2** dodaje **multipleksowanie** — wiele równoczesnych **streamów** na jednym połączeniu — plus binarne ramkowanie, kompresję nagłówków (HPACK) i server push. Ale ponieważ nadal działa na TCP, pojedynczy zgubiony pakiet blokuje *każdy* stream do czasu retransmisji: HOL blocking po prostu przesunął się z warstwy HTTP w dół do TCP.

**HTTP/3** rozwiązuje to, działając na **QUIC**, nowym transporcie zbudowanym na **UDP**. QUIC sam implementuje streamy, więc utrata na jednym streamie nie blokuje pozostałych. Scala też handshake transportu i TLS (1-RTT, często 0-RTT przy wznowieniu) dla szybszego ustanawiania połączenia i wspiera **migrację połączenia**, aby sesja przeżyła zmianę sieci (Wi-Fi → komórka).

## Dlaczego to ważne

To ulubione pytanie na poziomie middle, bo odpowiedź to opowieść *problem → naprawa → nowy problem → naprawa*, czyli dokładnie tak, jak mocny inżynier rozumuje o ewoluujących systemach. Kluczowe spostrzeżenie, którego szukają rekruterzy, to zrozumienie **head-of-line blocking na dwóch warstwach**: HTTP/2 rozwiązał je na warstwie aplikacji, ale wciąż był uwięziony pod TCP, a HTTP/3 musiał zmienić sam transport, aby dokończyć dzieło. To także praktyczne: wiedza o tym prowadzi realne decyzje o ponownym użyciu połączeń, o tym, czy nadal shardować domeny, i o tym, co zyskujesz, włączając HTTP/3 na swoim CDN.

Dlaczego to ważne

Powiązane pytania