Mitä eroja on HTTP/1.1:n, HTTP/2:n ja HTTP/3:n välillä?

Question

IT Interview Practice · Accepted Answer

Kaikki kolme tarjoavat saman HTTP-semantiikan (metodit, otsakkeet, tilakoodit), mutta eroavat siinä *miten* ne siirtävät tavuja johtoa pitkin — kukin versio korjaa edellisen pullonkaulan. Läpileikkaava teema on **head-of-line (HOL) -tukoksen poistaminen**, jossa yksi jumittunut pyyntö pidättelee muita.

```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** lähettää yhden pyynnön kerrallaan yhteyttä kohti; selaimet kiertävät tämän avaamalla ~6 rinnakkaista yhteyttä hostia kohti, ja tekstiotsakkeet lähetetään pakkaamattomina. **HTTP/2** lisää **multiplexingin** — monta samanaikaista **streamiä** yhden yhteyden yli — sekä binäärikehystyksen, otsakepakkauksen (HPACK) ja server pushin. Mutta koska se yhä toimii TCP:n päällä, yksi kadonnut paketti tukkii *jokaisen* streamin, kunnes se on lähetetty uudelleen: HOL-tukos vain siirtyi HTTP-kerrokselta alas TCP:hen.

**HTTP/3** ratkaisee tuon toimimalla **QUICin** päällä, uuden **UDP:lle** rakennetun kuljetuskerroksen. QUIC toteuttaa streamit itse, joten häviö yhdellä streamillä ei jumita muita. Se myös yhdistää kuljetuksen ja TLS:n kättelyt (1-RTT, usein 0-RTT jatkettaessa) nopeampaa yhteyden muodostusta varten ja tukee **connection migrationia**, jotta istunto selviää verkon vaihtumisesta (Wi-Fi → mobiiliverkko).

## Miksi se on tärkeää

Tämä on suosittu keskitason kysymys, koska vastaus on tarina *ongelma → korjaus → uusi ongelma → korjaus*, mikä on juuri se tapa, jolla vahva insinööri päättelee kehittyvistä järjestelmistä. Keskeinen oivallus, jota haastattelijat etsivät, on **head-of-line-tukoksen ymmärtäminen kahdella kerroksella**: HTTP/2 ratkaisi sen sovelluskerroksella mutta jäi yhä TCP:n vangiksi, ja HTTP/3:n piti muuttaa itse kuljetuskerrosta saadakseen työn valmiiksi. Se on myös käytännöllistä: tämän tietäminen ohjaa todellisia päätöksiä yhteyksien uudelleenkäytöstä, siitä kannattaako domaineja yhä pilkkoa, ja siitä mitä hyödyt ottamalla HTTP/3:n käyttöön CDN:ssäsi.

Miksi se on tärkeää

Aiheeseen liittyvät kysymykset