HTTP Over the Decades: Tarina fysiikasta, latenssista ja Grudging Sopeutumisesta

Sunday, 28 December 2025

HTTP ei kehittynyt. pakko muuttaa fysiikalla, latenssilla ja väärinkäytöllä.

Jokainen versio on olemassa, koska edellisellä on kovat rajoitteet. Jos ymmärrät nämä rajoitukset, ymmärrät, miksi verkko toimii niin kuin se toimii - ja miksi niin monet "parhaat käytännöt" ovat itse asiassa protokollarajoituksia, joita olemme venkoilleet jo kolmekymmentä vuotta.

Olen rakentanut verkkosovelluksia vuodesta 1997 lähtien. Olen purkanut HTTP/1.0-yhteysmyrskyjä, katsellut selainten avaavan kuusi yhteyttä isäntää kohti "ominaisuutena", kironnut HTTP/2:n TCP-pääeston mobiiliverkoissa, ja lopulta nähnyt HTTP/3:n myöntävän, mitä tiesimme koko ajan: verkko on ongelma.

Tämä ei ole protokollaopetus, vaan tarina siitä, miten päädyimme tänne.

HTTP/1.0: Stateless Text Over Epäluotettavat putket

Maailma joka teki sen

HTTP/1.0 suunniteltiin vuonna 1996 maailmaa varten, jota ei enää ole. Ymmärtääksesi, miksi se toimi, sinun täytyy ymmärtää, mitä "verkko" tarkoitti vuonna 1996:

Soittoyhteydet klo 28.8kbps (jos kävi tuuri)
Sivut olivat asiakirjoja - teksti, ehkä muutama pieni kuva, hyperlinkit
Käyttäjät klikkasivat ja odottivat - välitöntä reagointia ei odotettu
Palvelimet olivat kalliita - yliopistot ja yritykset, eivät kaikki

Tässä maailmassa pullonkaula oli kaistanleveys50KB-sivun lataaminen kesti 15 sekuntia. Kuka välitti 200 metrin ylimääräisestä kädenpuristuksesta?

Mihin HTTP/1.0 optimoitiin:

Yksinkertaisuus (todennäköisyys telnetin kanssa)
Valtiottomuus (palvelijat eivät seuraa yhteyksiä)
Inhimillinen luettavuus (tekstiprotokolla)
Yksi pyyntö, yksi vastaus, yhteys suljettu

GET /index.html HTTP/1.0
Host: example.com

HTTP/1.0 200 OK
Content-Type: text/html

<html>...

Yksinkertainen, elegantti, täydellinen vuodelta 1996 ja täysin käyttökelvoton kaikkeen muuhun kuin asiakirjahakuun.

Paine, joka mursi sen

Sitten verkko muuttui nopeasti.

Vuonna 1998 sivut eivät olleet vain asiakirjoja, vaan niissä oli tyylisivuja, JavaScript-kuvia ja useita kuvia. Yksi sivu voi tarvita 20-30 erillistä resurssia.

Jokainen vaadittu pyyntö:

TCP-puristus (1 kierros)
Pyyntö lähetetty (1 kierros)
Saatu vaste
Yhteys suljettu
Toista jokaisen kuvan, kirjoitustyylin, käsikirjoituksen...

20-resurssilla varustettu sivu tarkoitti 20 TCP-kädenpuristusta. 200 ms:n latenssiyhteydellä (joka on yhä yleinen), 4 sekuntia vain kättelyä ennen kuin mitään sisältöä siirretään.

Perusoletus HTTP/1.0:sta:

Aika oli halpaa.

Vuonna 1996 se oli. Bandwidth oli pullonkaula. Vuonna 1999 kaistanleveys parani, mutta Latenssi ei ollut Yhtäkkiä kierroksilla oli merkitystä.

HTTP/1.0 oli suunniteltu dokumentteja varten. Netistä oli tullut sovellusalusta.

HTTP/1.1: Paikkaamme sen

Maailma joka teki sen

HTTP/1.1 saapui vuonna 1997, juuri kun verkko oli räjähtämässä. Dotcom-buumi oli alkamassa. Kaikki yritykset tarvitsivat nettisivut. Web-sivut olivat mutkikkaita - taulut ulkoasua varten, JavaScript vuorovaikutteisuutta varten, kuvat kaikkialla.

Painostus oli selvä: Liitäntäpyyntö oli tapposuoritus. Mutta täysin HTTP:n uudelleen suunnittelu ei ollut vaihtoehto. Liika infrastruktuuri oli jo kiinni siitä. Ratkaisun piti olla takaperin yhteensopiva.

Mikä muuttui:

Jatkuvat yhteydet (Connection: keep-alive Oletuksena) – TCP-yhteyden uudelleenkäyttö
Siirretty koodaus (stream-vastauksia tietämättä kokoa etukäteen)
Isäntäotsikot (virtuaalinen isännöinti - useita sivustoja per IP, ratkaiseva jaettu hosting)
Väliseinät semantiikassa (Cache-Control, ETag, ehdolliset pyynnöt)
Putket (lähetä useita pyyntöjä odottamatta vastauksia)

Mikä ei muuttunut:

Yhä peräkkäisiä vasteita (jopa piipulla)
Silti tekstiotsikoita (toistetaan joka pyynnöstä)
Vielä yksi vastaus kerrallaan yhteyttä kohden

GET /page.html HTTP/1.1
Host: example.com
Connection: keep-alive

HTTP/1.1 200 OK
Transfer-Encoding: chunked
Cache-Control: max-age=3600

...

Miksi se tavallaan toimi?

HTTP/1.1 ei itse asiassa ratkaissut suoritusongelmaa, vaan se vain liikutti sitä.

Putket epäonnistuivat. Spektrolin avulla voitiin lähettää useita pyyntöjä yhdellä yhteydellä, mutta:

Vastaukset piti palauttaa kunnossa (linjan sulku)
Yksi hidas reaktio esti kaiken sen takana
Buggy proxies silpoi putkijohtoisia pyyntöjä
Useimmat selaimet poistivat sen kokonaan

Sen sijaan, että protokollaa olisi korjattu, selaimet huijasivat:

Avaa 6 rinnakkaista yhteyttä isäntää kohti (selkärankaraja)
Käyttö verkkotunnuksen siristys (static1.example.com, static2.example.com) liittymien moninkertaistaminen
Spriittilevyt kuvien yhdistämiseen
CSS/JS-niputus pyyntöjen vähentäminen
CDN-koodit latenssin vähentäminen

Mikään näistä ei toiminut suunnitellusti, vaan koko ekosysteemi korvasi HTTP/1.1:n perustavanlaatuisen rajoituksen.

HTTP/1.1 skaalautuu huijaamalla, ei korjaamalla mallia.

Miksi se kuitenkin selviytyi?

HTTP/1.1 toimi tarpeeksi hyvin Viisitoista vuotta, ei siksi, että se olisi hyvä, vaan siksi, että ympäristö kompensoi:

Laajakaista saapui. 20 millin kädenpuristukset 200 millin sijaan. Kipu oli siedettävää.
Mooren laki auttoi. Palvelimet pystyivät käsittelemään kuusi yhteyttä selainta kohti vuoteen 2005 mennessä.
CDN:t peittivät ongelman. Edge-palvelimet 20 metrin päässä 200 metrin sijaan.
Työpöytä hallitsi. Langattomat yhteydet, matala latenssi, luotettavat verkot.

Olimme vain onnekkaita, että maailma salasi sen.

Todelliset kustannukset

Nuo kuusi liittymää per isäntä eivät olleet ilmaisia:

Jokainen yhteys tarkoitti toista TCP-kädenpuristusta
Jokainen yhteys kilpaili kaistanleveydestä
Palvelimien piti ylläpitää enemmän samanaikaisia yhteyksiä
Verkkosulku siirtyi juuri TCP:lle - menettää yhden yhteyden paketin, että yhteys on tallella

Verkko nopeutui HTTP/1.1:n aikakaudella, mutta ei HTTP/1.1:n takia. Se nopeutui, koska:

Verkot nopeutuivat
Välilyönnistä tuli älykkäämpää
CDN-koodit imeytyivät latenssiin
Selaimet paranivat rinnakkainasettelussa

Rakensimme sovellusalustaa dokumenttien hakuprotokollalle, ja protokolla oli häviämässä.

Epämukava totuus, jota kukaan ei myönnä

Vuoteen 2010 mennessä verkon suorituskyky oli jatkuvaa taistelua HTTP:tä itseään vastaan.

Aikakauden "parhaat käytännöt" kertovat tarinan:

Yhdistä kaikki Javascript-tiedostot yhteen tiedostoon
Sprite kaikki kuvat yhdessä
Inline-kriittinen CSS
Käytä datan URI-tietoja pyyntöjen välttämiseksi
Verkkoalueen sirpale avaa lisää yhteyksiä
Laita skriptit sivun alalaitaan

Jokainen näistä on täyskäännös "HTTP/1.1:lle, joka ei pysty käsittelemään monia pyyntöjä tehokkaasti".

Rakensin monia näistä pienistä työkaluista, kuten sprite-generaattoreista, CSS-kompressorista, aloimme käyttää reagointikompressiota jne.

Selaimet eivät olleet nopeampia, koska HTTP parani. työskennellyt HTTP:n ympärillä.

Kuusi yhteyttä per isäntä ei ole ominaisuus. Se on hakata. Verkkoalueen sirpale ei ole paras käytäntö, vaan myöntää epäonnistuneensa.

Opetin vuosia kehittäjiä niputtamaan hyödykkeitä, sprite-kuvia ja inline-kriittisiä resursseja. Mikään niistä ei ollut "hyvää arkkitehtuuria". Protokollavaurioiden hallinta.

"HTTP on yksinkertainen" myytti jatkui, koska monimutkaisuus oli piilotettu:

Selainyhteyden hallinta
CDN:n reunalogiikka
Rakenna työkalujen tiivisteet
Palvelinkytkentäyhdistelmä

HTTP/1.1 toimi, koska kaikki toimi ympäri se teki ylitöitä kompensoidakseen.

Jos olet koskaan nähnyt kaavion HTTP:stä, jossa ei näy latenssia, menetyksiä tai vikatiloja, se valehtelee sinulle. Protokolla on yksinkertainen. Todellisuus ei ole.

HTTP/2: Korjasimme väärän kerroksen

Maailma joka teki sen

Vuonna 2010 verkko oli jälleen muuttunut. Kaksi massiivista vuoroa muutti kaiken:

1. Mobiili tapahtui. Vuonna 2007 lanseerattu iPhone. Vuonna 2012 mobiiliverkkoliikenne räjähti räjähdysmäisesti. Yhtäkkiä käyttäjät eivät olleet langallisella laajakaistayhteydellä - he olivat 3G:llä, sitten 4G:llä, vaihtelevalla latenssilla ja toistuvilla pakettitappioilla. Oletukset, jotka tekivät HTTP/1.1:stä siedettävän, olivat kaatumassa.

2. Verkkosovellukset korvasivat verkkosivut. Gmail. Google Maps. Facebook. Twitter. Nämä eivät olleet dokumentteja, joissa oli linkkejä, vaan sovelluksia, jotka tarvitsivat kymmeniä tai satoja resursseja, reaaliaikaisia päivityksiä ja pikaisia vastauksia. "Kuusi yhteyttä per isäntä" -hakkeri osoitti ikänsä.

Googlella oli valtava mittakaava, suorituskykyinsinöörejä, ja HTTP/1.1:n todistamiseen käytetty data oli pullonkaula. Vuonna 2009 he aloittivat SPIDYn - kokeellisen protokollan, josta tulisi HTTP/2.

Mikä muuttui:

Binäärikehys (ei tekstiä - tehokkaampi jäsennys)
Multipleksointi (Yhdellä yhteydellä useita pyyntöjä/vastauksia)
Otsikkopuristus (HPACK - ei enää toisteta samoja otsikoita)
Palvelimen työntö (lähetä resursseja ennen kuin asiakas kysyy - vaikka tämä osoittautuikin vaikeaksi virittää oikein ja on nyt suurelta osin nurinkurista)
Yksi yhteys alkuperää kohti (ei enää yhteyden räjähdystä)

┌──────────────────────────────────────────┐
│           Single TCP Connection          │
├──────────────────────────────────────────┤
│ Stream 1: GET /page.html                 │
│ Stream 3: GET /style.css                 │
│ Stream 5: GET /app.js                    │
│ Stream 7: GET /logo.png                  │
│ (all interleaved, no ordering required)  │
└──────────────────────────────────────────┘

Näin HTTP/1.1-putkenpidityksen olisi pitänyt olla. Virtaukset ovat itsenäisiä. Yksi hidas reaktio ei estä muita. Otsikko on tiivistetty. Protokolla vastasi lopulta sitä, miten käytämme verkkoa.

Miksi se toimi (oikeilla verkoilla)

HTTP/2 oli täydellinen laajakaistaverkolleJa vuonna 2015, kun se standardoitiin, laajakaista oli kaikkialla kehittyneessä maailmassa.

Mikä parani:

Latenssi kevyessä kuormassa (yksi yhteys, ei kädenpuristuksia pyydettäessä)
Vähemmän yhteyksiä (vähemmän palvelimen yläpuolella, vähemmän TCP-slow-start)
Parempaa kaistanleveyden käyttöä (ei keinotekoisia liityntärajoja)
Otsikkokompressio (toistuvat otsikot, kuten evästeet, eivät enää maksa kaistanleveyttä)
Ei enää sekoilua/springingiä (moni pieni tiedosto on nyt kunnossa)

HTTP/2 oli käyttäjille langallisilla yhteyksillä, joilla oli alhainen pakettitappio, todellinen parannus. Vertailuarvot näyttivät hyviltä. Mittarit paranivat. Google julisti voiton.

Paine, joka mursi sen

Mutta maailma oli jo mennyt eteenpäin. Mobiili oli nyt suurin osa verkkoliikenteestä.

Matkapuhelinverkoilla on perusominaisuus, jollaista laajakaistalla ei ole: pakettitappio on vakio.

TCP-takuut TilaustoimitusJos paketti 47 katoaa, paketit 48-100 odottavat, kunnes 47 lähetetään uudelleen - vaikka ne kuuluisivat täysin riippumattomiin HTTP/2 -virtoihin.

┌──────────────────────────────────────────┐
│              TCP Receive Buffer          │
├──────────────────────────────────────────┤
│ [pkt 45][pkt 46][  ?  ][pkt 48][pkt 49]  │
│                   ↑                       │
│         Waiting for packet 47             │
│                                          │
│ Stream 1 data: BLOCKED                   │
│ Stream 3 data: BLOCKED                   │
│ Stream 5 data: BLOCKED (has pkt 48-49)   │
│ Stream 7 data: BLOCKED                   │
└──────────────────────────────────────────┘

HTTP/2 ratkaisi kantapään tukoksen käyttökerroksessa, minkä jälkeen TCP palautti sen siirtokerrokseen.

Yksi kadonnut paketti tukkii kaikki purot. Puhtaalla langalla pakettihävikki on harvinaista. Matkapuhelimissa, hukassa olevilla WiFi-yhteyksillä tai ruuhkaisilla yhteyksillä pakkaushävikki on vakio. Ja koska HTTP/2 käyttää single yhteys (suunnitellusti), yksi kadonnut paketti nyt estää kaikki sen sijaan vain yksi kuudesta yhteydestä.

HTTP/2:n suorituskyky:

Langaton, pieni menetys: Erinomaista
Liikkuva, kohtalainen tappio: Joskus pahempaa kuin HTTP/1,1
Suuri latenssi, mikä tahansa menetys: Katastrofaalinen

Ironista: HTTP/2 oli suunniteltu mobiilikäyttöön, mutta TCP:n takuut pahensivat mobiilissa sen korvaamaa protokollaa.

Miksi HTTP/2 tuntui nopeammalta (siihen asti, kun sitä ei ollut)

HTTP/2:n käyttöönotto osoitti todellisia parannuksia:

Vähemmän yhteyksiä tarkoitti nopeampaa alkukuormaa (TLS-puristus kerran, ei kuusi kertaa)
Otsikkokompressio kevennettynä yleisellä tasolla
Multiplexing toimi hyvin saman alkuperän omaisuuden hyväksi

Mutta hännän latenssi kertoi toisen tarinan. mediaani P99 paheni.

Näin tämän omin silmin: asiakas otti HTTP/2:n käyttöön CDN:ssä ja katseli mobiilia P99 latenssia lisäys Kojelaudat paranivat 40 prosentilla. Tukiliput tulivat mobiilikäyttäjiltä. Käytimme viikon sen selvittämiseen, että HTTP/2:n "parannus" pahensi suurimman osan liikenteestä.

Kun HTTP/2 toimii, se toimii kauniisti. Kun paketti putoaa mobiiliyhteydelle pahimmalla hetkellä, kaikki jäätyy. Käyttäjät huomaavat, että se jäätyy enemmän kuin nopeat mediaanit.

Perusongelma:

HTTP/2 oletti TCP:n kelpaavan.

Laajakaistan osalta se oli. Mobiilien kohdalla se ei ollut. Kun HTTP/2 standardoitiin, mobiili oli jo voitolla. Olimme ajaneet niin pitkälle kuin TCP pystyi.

HTTP/3: Hyvä on, siirrymme alas pinoon

Maailma joka teki sen

Vuoteen 2015 mennessä todisteet olivat selvät: TCP oli ongelma.

Google oli käyttänyt QUICia kokeellisesti vuodesta 2012 lähtien. Heillä oli tiedot mobiiliverkoista, häviöllisistä WiFi-yhteyksistä ja korkeista latenssiyhteyksistä. HTTP/2 epäonnistui TCP:n kohdalla tavoilla, joita ei voitu korjata vaihtamatta kuljetuskerrosta.

Mutta TCP:tä ei voi vain "korjata". Se on toteutettu käyttöjärjestelmän ytimessä. Se on leivottu jokaiseen internetin reitittimeen, palomuuriin ja välilaatikkoon. TCP:n muuttaminen tarkoittaa, että se odottaa vuosikymmeniä koko internetin infrastruktuurin päivittämistä.

Joten Google teki jotain uhkarohkeaa: he rakensivat UDP:n päälle uuden liikenneprotokollan.

UDP on "mykkä" suunnittelultaan - se vain lähettää paketteja ilman takuita. Mutta juuri sitä tarvitset, jos haluat toteuttaa omasi Luotettavuussemantiikkaa. QUIC toteuttaa uudelleen TCP:n takuut (luotettava, tilattu toimitus), mutta tekee sen Virtaa kohti Yhteyden sijaan.

HTTP/3 (2022) on HTTP yli QUIC. Se on tunnustus, että meidän piti mennä alle HTTP korjata HTTP.

Mikä muuttui:

KYMMENEN UDP:hen verrattuna (ei TCP)
Stream-tason tappion toipuminen (yksi kadonnut pakkaus vain tukkii virtansa)
Nopeamman yhteyden asennus (0-RTT:n uudelleenkäynnistys mahdollinen)
Salaus oletuksena (TLS 1,3 rakennettu QUICiin)
Liitännäismuutto (Keskeyttää IP-osoitteen muutokset)

┌──────────────────────────────────────────┐
│              QUIC Connection             │
├──────────────────────────────────────────┤
│ Stream 1: [pkt][pkt][pkt] ← flowing      │
│ Stream 3: [pkt][ ? ][pkt] ← waiting      │
│ Stream 5: [pkt][pkt][pkt] ← flowing      │
│ Stream 7: [pkt][pkt]      ← flowing      │
│                                          │
│ Lost packet only affects Stream 3        │
└──────────────────────────────────────────┘

Mikä pysyi samana:

HTTP-semantiikat (GET, POST, otsikot, tilakoodit)
Välimuistin logiikka
REST-kuviot
Kaikki sovelluskerroksessa

HTTP/3 ei muuttanut HTTP:tä, vaan se muutti sen, miten HTTP selviää todellisuudesta.

MIKSI KYSYMYKSIÄ

QUIC toteuttaa TCP:n luotettavuustakuut Virtaa kohtiTämä on avainnäkemys.

TCP:n lupaus: "Jokainen tavu saapuu järjestykseen." QUICin lupaus: "Jokainen taputus tässä virrassa saapuu kuntoon."

Tämän eron vuoksi HTTP/3 ei kaadu häviöllisissä verkoissa.

Muita QUIC-ominaisuuksia, jotka korjaavat pitkäaikaisia ongelmia:

Liitännäismuutto:

Phone on WiFi → walks out of range → switches to cellular
TCP: Connection dies. Restart everything.
QUIC: Connection ID maintained. Streams continue.

Tämä on tärkeää, koska mobiilikäyttäjät jatkuvasti Vaihda verkkoja, kävele ulos talostasi, menetä WiFi, vaihda kännykkään. TCP:n myötä jokainen yhteys katkeaa. QUIC:n kanssa yhteys jatkuu.

0-RTT:n uudelleen aloittaminen:

First connection: Full handshake (1-RTT)
Returning user: Send data immediately (0-RTT)

Salaus kaikkialla:

TCP + TLS: Handshake, then encrypted tunnel
QUIC: Encryption is the handshake (TLS 1.3 integrated)

Maailma, joka sitä tarvitsee

HTTP/3 on suunniteltu maailmaan, jossa oikeasti elämme:

Mobile first: Yli puolet verkkoliikenteestä on mobiilia
Luotettavat verkot: WiFi, soluverkko, ruuhkainen julkinen verkko
Maailmanlaajuiset käyttäjät: Suurlatenssiyhteydet kaukaisille palvelimille
Yksityisyysodotukset: Salaus on pakollista, ei vapaaehtoista

Protokolla vastaa vihdoin verkkotodellisuutta. 30 vuotta HTTP/1.0:n olettaman luotettavan langallisen yhteyden jälkeen HTTP/3 myöntää, että luotettavuus on poikkeus, ei sääntö.

Edistymisen kustannukset

HTTP/3 ei ole ilmainen:

UDP on usein tukossa Yhtiön palomuurit (varaudutaan HTTP/2:een)
Lisää prosessoria QUICin käyttötilan toteutukseen (ei ytimessä, kuten TCP:ssä, vaikka tämä aukko on sulkeutumassa ytimen ohituksella ja optimoiduilla pinoilla)
Uudet vianetsintätyökalut (tcpdump näyttää salatun UDP:n, ei luettavan HTTP:n)
Middlebox-häirintä (Jotkut verkostot silpovat UDP:tä arvaamattomasti)

Mutta mobiilien ensimmäisille sovelluksille, epäluotettaville verkoille ja latenssiherkille palveluille HTTP/3 on ensimmäinen versio, joka vastaa sitä, miten verkostot todellisuudessa käyttäytyvät.

Todellinen opetus kaikissa versioissa

Jokainen HTTP-versio vaihtui, koska ympäristö muuttui nopeammin kuin protokolla.

Versio: Aikakausi Ympäristö Oletus: Miksi se rikkoi? |---------|-----|-------------|------------|--------------| HTTP/1.0 1996 Dialup, dokumentit Bandwidth on pullonkaula. Sivuista tuli sovelluksia, latenssilla oli merkitystä. HTTP/1.1 Laajakaista, verkkosovellukset Low latency kätkee tehottomuuden Mobile saapui pakettitappiolla HTTP/2 2015-2022 Laajakaistahuippu, liikkuva nouseva TCP on tarpeeksi luotettava ja mobiili tuli hallitsevaksi, TCP epäonnistui. HTTP/3 HTTP 2022 + HTTP 2022 + HTTP 2022 + HTTP 2022 + HTTP 2022 + HTTP 2022 + HTTP 2022 + HTTP 2022 + HTTP 2022 + HTTP 2022 + HTTP 2022 + HTTP 2022 + HTTP 2022 + HTTP 2022 + HTTP 2022 + HTTP 2022 + HTTP 2022 + HTTP 2022 + HTTP 2022 + HTTP 2022 + HTTP 2022 + HTTP 2022 + HTTP 2022 + HTTP 2022 + HTTP 2022 + HTTP 2022

Malli on selkeä:

Protokolla on suunniteltu nykyiseen ympäristöön
Ympäristömuutokset (nopeammin kuin protokollat voivat mukautua)
Työkierroksia kertyy (CDN:t, yhteyden hakkerointi, niputtaminen)
Uusi protokolla tunnustaa todellisuuden
Toista

Protokollaa työnnetään yhä lähemmäs verkkoa. Jokainen riittävältä vaikuttanut abstraktio kuoriutui takaisin, kun ympäristö sitä vaati.

Muita huomioita:

"Stateless" on valhe, jonka kerromme itsellemme yöunille. Jokainen sessiokeksi, auth plake, ja kätkön otsikko on valtion johto, johon olemme pudonneet.
Useimmat suoritusvoitot tulivat treenitCDN:t, välimuistit, yhdysjohdot, kehotus yhdistää - kaikki kompensoivat protokollan rajoituksia.
HTTP/1.0 oli yksinkertainen. Tarvitsimme sinnikkäät yhteydet ja sitten multipleksoinnin. Sitten uusi siirto. Jokainen monimutkaisuuden kerros ratkaisi todelliset ongelmat.
Ajoituksella on väliä. HTTP/2 olisi ollut täydellinen, jos se olisi saapunut vuonna 2005. Vuoteen 2015 mennessä mobiili oli jo muuttanut peliä. Protokolla ratkaisi eilisen ongelman.

Mikä ei ole muuttunut 1,0:n jälkeen

30 vuoden protokollakehityksestä huolimatta:

Pyynnöt epäonnistuvat edelleen. Verkkojako, palvelimet kaatuvat, aikakatkaisut tapahtuvat. Koodisi tarvitsee vielä uutta logiikkaa.

Verkostot valehtelevat yhä. 200 OK ei tarkoita, että vastaus olisi oikea. Yhteys suljettuna ei tarkoita, etteikö pyyntö olisi onnistunut. Aikalisät eivät tarkoita, etteikö palvelin olisi käsitellyt pyyntöäsi.

Käpylät tarjoavat yhä tunkkaista dataa. Cache-Control Se on pyyntö, ei käsky. Proxies tekee mitä haluaa. CDN:n mitätöinti on parhaimmillaankin.

Asiakkaat yrittävät yhä huonosti. Käyttäjä napsauttaa painiketta, mitään ei tapahdu, napsahtaa uudelleen. Nyt sinulla on kaksi pyyntöä. Impotenssilla on merkitystä.

Kehittäjät ymmärtävät yhä väärin idempotenssin. PUT:n pitäisi olla idempotentti. POST on villi länsi. Useimmat API:t ymmärtävät tämän väärin.

// This is still your problem, regardless of HTTP version
public async Task<Result> CreateOrderAsync(Order order)
{
    // What happens if this times out?
    // Did the server receive it?
    // Did it process it?
    // Will the client retry?
    // Will you create duplicate orders?
    
    // HTTP/3 doesn't save you here.
    // Idempotency keys do.
}

Jos et ymmärrä näitä, HTTP/3 ei pelasta sinua.

Mitä todella opin

Kun olet rakentanut web-sovelluksia kaikkien näiden protokolliversioiden päälle, tämä jäi jumiin:

1. Protokolla ei ole luotettava kerros.

HTTP antaa sinulle pyyntö- ja vastausselmantiikkaa. Se ei takaa toimitusta, korrektiutta tai tasan kertakäsittelyä. Se on sinun tehtäväsi.

2. Latenssi on vihollinen, ei kaistanleveys.

Suurin osa suoritusongelmista on pyöreitä, ei läpivientiin sidottuja. Vaatimusten vähentäminen on tärkeämpää kuin hyötykuorman keventäminen.

3. Jokaisella "parhaalla käytännöllä" on viimeinen käyttöpäivä.

Verkkoalueen siristys oli olennaista HTTP/1.1:lle. Se on haitallista HTTP/2:lle. CSS:n inlinointi oli fiksua. Nyt meillä on palvelimen työntö (joka myös epäonnistui) ja varhaiset vihjeet. Taktiikan muutos. Maali (vähennä viivettä) pysyy samana.

4. Mittaus todellisissa verkoissa.

Käyttäjäsi ovat mobiiliverkoissa, hotellin WiFissä ja kyllästetyissä kahviloissa. Testaa siellä.

5. Tylsyillä osilla on eniten merkitystä.

Aikakatkaisut, retries, virtapiirien katkaisut, häiriönsieto. Liitännäisten yhdistäminen. Nämä häikäisemättömät yksityiskohdat ratkaisevat, toimiiko järjestelmäsi kuormitettuna.

Päätelmät

HTTP ei nopeutunut, koska siitä tuli älykkäämpi. verkko oli ongelma.

Jokainen versio oli oikea aikansa:

HTTP/1,0 oli täydellinen valintadokumentin hakuun
HTTP/1.1 oli täydellinen laajakaistaverkkosovelluksiin
HTTP/2 oli täydellinen matalan tappion langallisille yhteyksille
HTTP/3 on rakennettu mobiili-ensimmäiselle, epäluotettavalle verkkotodellisuudelle, jossa oikeasti elämme

Virheessä luultiin, että jokin niistä oli pysyviä ratkaisuja, jotka kaikki reagoivat erityisiin ympäristöpaineisiin. Ympäristön muuttuessa protokollaa oli noudatettava.

HTTP-versiot eivät ole kuluttajamielessä päivityksiä, vaan ne on optimoitu erilaisiin vikajakeluihin.

Ja silti, kaiken tämän jälkeen, perusasiat ovat edelleen:

Pyynnöt epäonnistuvat
Verkot valehtelevat
Välilyönnillä on vaikeaa
Impotenssilla on merkitystä

Protokolla kehittyi, mutta ongelmat eivät hävinneet.

Rakenna järjestelmiä, jotka selviävät epäonnistumisista. Testaa todellisia verkkoja. Ymmärrä, että jokainen HTTP-versio on aikakautensa muovaama vaihtokauppa, ei päivitys, joka vanhentuu aiemmasta.

Se on kolmekymmentä vuotta HTTP:tä. Se on verkko, jonka rakensimme. Toisella vuosikymmenellä HTTP/3:n oletukset näyttävät todennäköisesti samalta kuin HTTP/1.0:n oletukset nyt.

Lisää luettavaa

RFC 9114: HTTP/3 - Viralliset tiedot
RFC 9000: QUIC - Kuljetusprotokolla
HTTP/2 selitetty - Daniel Stenbergin erinomainen katsaus
Tehokas selainverkko - Ilja Grigorikin syväsukellus (ilmainen verkossa)