HTTP under årtiondena (Svenska (Swedish))

HTTP utvecklades inte, det var tvingat att ändras på grund av fysiken

Varje version existerar eftersom den tidigare träffade en hård begränsning.

Jag har byggt webbapplikationer sedan "1997.". Jag har löst upp "" HTTP "", /1.0" kopplingsstormar, , tittade på webblader som öppnade sex anslutningar per moder som en """ -feature, "" МSK6 "" förbannad vid "" Http "" och "Http 7", "TCP" -hjärnan, "Linblocking" av "M SK9" på mobila nätverk, , och till slut sett "HTP" -n, "Sk11" -att erkänna vad vi alltid visste. :, "Network is the problem" (nätverket är problemet)

Det här är "'", det är inte en instruktionsvideo, det är en historia om hur vi kom hit.

HTTP/1.0: Statlös text över osäkra piper

Världen som skapade det

HTTP designades i 1996 för en värld som inte längre existerar.

Dialuppkopplingar på 28.8kbps ( om du hade tur
sidor var dokument - text , kanske några små bilder
Användare klickade och väntade - var oväntad
Server var dyra - universitet och företag , inte alla

I denna värld, ",", var flaskkörteln bandbredd, inte latens . Det tog seconds att ladda ner en ♫ 50 ♫ KB-sida på telefontelefonen

Vad HTTP optimerade för:

Enkelhet (lösbar med telnet)
Stadslöshet (server inte ' inte spåra kopplingar)
Människo
Ett begäran , ett svar, koppling stängd

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

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

<html>...

Enkela. Eleganta . Perfekt för 1996. Och fullständigt oanvändbar för allt annat än att hitta dokument

Pressuren som förstörde den

Sedan ändrades webben.

På grund av "1998," -sidorna var inte bara dokument. De hade styletablar. "," JavaScript (JavaScript) ," flera bilder..En enda sida kanske kräver separata resurser."

Varje enda begäran kräver

TCP handshake (1 RTT
begäran/first byt (~1 RTT
Svaret fick
Verbinding stängd
upprepa för varje bild

En sida med 20 resurser betydde | 20 | TCP handrörelser | МSK2 | På en | 200 | ms latens-uppkoppling bara handdragande innan någon innehåll överfördes.

Det grundläggande antagandet av HTTP/1.0:

Tid var billigt

I 1996, var det . Bandbredden var flaskkörteln latens var't - och plötsligt var de där rondresorna viktiga

HTTP/1.0 var designad för dokument

HTTP/1.1: Vi' kommer att fixa det

Världen som skapade det

Presen var tydlig koppling-per-frågan dödade prestationen. Men att helt omdesigna HTTP var inte ett alternativ.

Vad förändrades:

Hållbara kopplingar (Connection: keep-alive standardmässigt) - återanvända TCP kopplingen
Chunked transfer enkodering (strömresponser utan att veta storleken i förväg
Hemma-Header (virtuell hosting | - | flera webbplatser per IP | МSK2 | avgörande för gemensamt hosting
Att kassera semantik (Cache-Control, ETag, villkorliga begäran
Pipelinering ( skicka flera begäran utan att vänta på svar

Vad hade ändrats?

Fortfarande sekvenserade reaktioner ( även med pippelning )
Ändå textkolor ( upprepade på varje fråga)
Ännu en respons vid ett tillfälle per koppling

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

...

Varför är det sorterat?

HTTP/1.1 löste faktiskt inte upp prestationens problem, ' det flyttade den bara runt.

Pipelinering var ett misslyckande. Spec allowed sending multiple requests on one connection, but:

Svar var tvungna att komma tillbaka i ordning (
En långsam respons blockerade allt bakom det.
Buggy-arbetare förvirrade pipelinede begäran
De flesta webblader deaktiverade den helt

Så webblader fuskade. Istället för att fixa protocoln jobbade de runt det.

Öffna 6 parallella anslutningar per host (browsergränsen)
Använda Domain-hashing (static1.example.com, static2.example.com) för att multiplicera kopplingar
Sprit-skivor att kombinera bilder
CSS/JS-bundling för att minska begäran
CDN för att minska latens

Inget av det här var protocolet som fungerade som designat.

HTTP/1.1 skalad genom fusk, , inte genom att fixa modellen.

Varför överlevde den i alla fall

HTTP/1.1 fungerade tillräckligt bra i femton år, inte för att det var bra, utan för att miljön kompenserade,

Breadband kom fram. 20ms handrörelser istället för 200msM SK2 smärtan var uthärdlig
Moores lag hjälpte Server kunde hantera sex anslutningar per webbläsare med 2005.
CDNs maskerade problemet. Randserver 20ms bort istället för 200ms.
Desktop dominerad. trådlösa kopplingar, låg latensitet , tillförlitliga nätverk.

Protokollet var fortfarande brutet.

Den verkliga kostnaden

De sex anslutningarna per host var inte gratis

Varje koppling betydde ett annat TCP handshake
Varje koppling tävlade om bandbredd
Server var tvungna att upprätthålla fler samtida kopplingar
"Had-" av - blockering precis flyttat till TCP - förlorar ett paquet på en koppling , kopplingen stannar upp

Webben blev snabbare under HTTP: s tidsålder. Men inte på grund av HTTP: n.

nätverk blev snabbare
Caching blir smartare
CDN absorberade latens
Bläser blir bättre på parallelism

Vi byggde en applikationsplattform på ett dokumentlagningprotokoll.

Den obehagliga sanningen som ingen erkänner

Enligt 2010, var webprestentialen en konstant kamp mot HTTP själv

De bästa metoderna på den tiden berättar historien.

Konkatera alla din JavaScript i en enda file
Spritera alla dina bilder tillsammans
Kritisk CSS inlyn
Använd data URIs för att undvika begäran
Domainshard för att öppna fler anslutningar
Lägg skript till sidans botten

Varenda en av dessa är ett tillvägagångssätt för "HTTP

Jag byggde många av dessa små verktyg som spritegeneratorer.

Browser var inte snabbare eftersom HTTP förbättrades. arbetade kring HTTP.

Sex anslutningar per host är inte en egenskap

Jag undervisade utvecklare i åratal att bundla tillgångar, ,, spritebilder och inlinera kritiska resurser. protokolskadorkontroll.

" Http är enkelt" myten överlevde eftersom komplexiteten var gömd i

Browseruppkopplingshantering
CDN gränslogik
Att bygga verktygskonkatenation
Serveruppkopplingspoolning

HTTP/1.1 fungerade eftersom allting runt omkring den arbetade övertid för att kompensera

Om du någonsin sett ett diagram av HTTP som inte visar latens, ', ,, förlust eller felläger,,, så ljuger det mot dig. . Protokollet är enkelt.

HTTP/2: Vi fixade den felaktiga ytan

Världen som skapade det

Vid 2010, hade webben omvandlats igen . Två massiva skivor förändrade allting

1. Mobiell hände . iPhonen lanserades i 2007. Genom ♫ 2012, ♫ blev mobilen webbtrafiken exploderande ♫. ♫ Plötsligt var användarena inte på kabelbundna bredband ♫

2. webbapplikationer som ersätter webbsidor Gmail, MSN0, Google Maps, MSN1, Facebook, MSN2, Twitter, MSN3 Det här var inga dokument med länkar, MSN5 Det var tillämpningar som behövde dussintals eller hundratals resurser, MSN6 verkliga, MSN7 tidliga uppdaterade, MSN8 och omedelbar respons, MSN9 Hacken, MSN10, sex anslutningar per moder, MSN11, visade sin ålder, MSN12

Google kände den här smärtan akut. De hade enorm skala. , prestationer, -, tvångslösa ingenjörer och data för att bevisa HTTP.

SPDY: Google's experiment

SPDY: "(" sa, "" МSK1 "" "fasty "", ")" var Googles "" answer to HTTP "" -lösning på /1.1' "" 's begränsningar "." Det var inte en standardmässig ansträngning, ' det var "" Google shipping code "" och se vad som fungerade.

Vad SPDY introducerade

Binärramer istället för att analysera text
Multiplexa strömmar över en enda TCP-koppling
Kompression (later raffinerad till HPACK för HTTP
Serverpuss för en proaktiv tillgång till resurser
Prioritering av strömmar att ladda kritiska resurser först

Google implementerade SPDY över Chrome och deras egna tjänster.

vägen till HTTP/2:

SPDY bevisade att koncepten fungerade. IETF lade märke till och använde SPDY som utgångspunkt för HTTP/2. Den slutliga HTTP /2 specifikationen | (2015) | är inte identisk med SPDY | - | skriftskompressionen ändrades signifikant | МSK6 | HPACK ersatte SPDY| M SK7 | zlib | - | baserad ansats efter säkerhetsproblem | ), | och olika detaljer raffinerades |- | men arkitekturen är uppenbar SPDY

Google förnekade SPDY i 2016 när HTTP ′ /2 ’ hade fått tillräckligt med anpassning ♫ . ♫ Uppdraget utförts ♫: ♫ de ’ ' ’ tvingade webben framåt genom att skicka först och standardisera senare ♫

Vad HTTP /2 förändrade ( byggande på SPDY

Binärramer (, inte text -, mer effektivt parerande
Multiplexing (multiple requests /responser interleaved på en koppling
Kompression (HPACK - inte längre upprepa samma opskrifte
Serverpuss ( skicka resurser innan klient frågar
Enkel koppling per ursprung ( inga fler kopplingsexplosioner

┌──────────────────────────────────────────┐
│           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)  │
└──────────────────────────────────────────┘

Det här är vad HTTP: s pipelinering skulle ha varit.

Varför det fungerade ( på rätta nätverken)

HTTP/2 var perfekta för bredbandnätverket. Och i 2015,, när den standardiserades, ,, var bredband allmänt förekommande i den utvecklade världen.

Vad förbättrades:

Längdtid under lätt last (en anslutning , inga handshake överhuvudtaget per begäran
Mindre anslutningar (färre överhead för servern, mindre TCP långsamt -start
Bättre bandbredd tillämpning ( inga artificiella gränser för anslutningar )
Koppersning av opskrifte ( upprepade opskrifte som cookies inte längre kostar bandbredd
Inget mer koncatenation/spriting behövs (manliga små filer är okej nu )

För användare med kopplade kopplingar med låg packetsförlust, var ,, HTTP, /2 en verklig förbättring.. Benchmarksen såg bra ut.., mätvärdena förbättrades.M SK4, Google bekänner succé.

Pressuren som förstörde den

Men världen hade redan gått vidare Mobila var nu majoriteten av webbtrafiken

Och mobila nätverk har en grundläggande egenskap som bredband inte har loss av paket är vanligt och oförutsägbart.

┌──────────────────────────────────────────┐
│              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 löst huvud- avM SK2 linje blockering på tillämpningslayret . Sen återintroduerade TCP den på transportlayret

Ett förlorat paket hindrar alla strömmar. På en ren kabelkopplung, loss av paquet är sällsynt . på mobila nätverk, förlorad WiFiM SK3 eller sammanträngda länkarMSC4 loss i packet är konstantMska5 Och eftersom HTTP ensamma anslutning (med design ), ett förlorat paquet blockerar nu allt istället för bara ett av sex anslutningar.

HTTP/2presterande

Kabeld, låg förlust: Utmärkt
Mobila, måttlig förlust: Ibland värre än HTTP/1.1
Hög latens – , – varje förlust: Katastrofisk

Ironiken var att :, HTTP, /2, var tänkta att fixa webbens multiplexingproblem.

Varför fungerade HTTP snabbare?

Initiella HTTP-implementeringar visade verkliga förbättringar

Fewer connections meant faster initial load (TLS handshake once
Headerkompression reduced overhead
Multiplexing fungerade bra för tillgångar med samma ursprung

Alla de verktyg jag byggde för 1.1? Allt försvann med HTTP /2, plötsligt var bundling något BAD, . HTTP+ /2'+ multiplexing var jättebra för tillgångar av samma ursprung, but it didn’ t help with cross

Men svans latens berättade en annan historia. i mitten blev bättre. P

Jag såg den här från första hand, :, en klient som aktiverade HTTP och /2 tvärs över sin CDN och tittade på mobila P. föröka av 40%. Talarborden visade förbättringar på datorbordet . stödbiljetterna kom från mobila användaren . Vi tillbringade en vecka med att lista ut att HTTP MSC3s M SK4 förbättringar MST5 gjorde saker värre för större delen av deras trafik

När HTTP fungerar/2 , det fungerar vackert. När ett paket faller på en mobil koppling i det värsta ögonblicket,

Det fundamentala problemet

HTTP/2 antog att TCP var tillräckligt bra

För bredband var det . för mobila , det var ' t . Och vid den tiden då HTTP standardiserade /2 , mobila redan vann . Vi pressade så långt TCP kunde ta oss

HTTP/3: Bra, , Vi' flyttar ner på lagern

Världen som skapade det

Enligt 2015, var beviset tydliga : TCP var problemet.

Google hade kört QUIC på ett försöksmässigt sätt sedan 2012. De hade datan . På mobila nätverk , förlorad WiFi, , och hög - låglektiga kopplingar, , HTTP, M SK6 via TCP hade misslyckats på sätt som inte kunde fixas, МSK7 utan att ändra transportlagret.

Men du kan – ' – inte bara – " – fixa TCP, ." – implementera den i operationssystemets kerneln. . – göra den in i varje router.

Så Google gjorde något djärvt. de byggde ett nytt transportprotokoll ovanpå UDP.

QUIC: Protokollet som erbjöd TCP (Sort Of)

QUIC ( ursprungligen | " | Vinniga UDP-internetuppkopplingar | МSK2 | nu bara QUIC implementera tillförlitlighet i userspace, där du kan upprepa snabbt.

Varför är UDP en stiftelse?

UDP är medvetet minimalt. Den lägger portnummer till IP och... det är i grunden ' Det är . inga handshakes, ,, ingen tillförlitlighet, M SK5, inget beställa, ., paketen kan komma ombord från affären. ,, duplicerad. ,, eller inte alls.., UDP bryr sig inte.

Det här är precis vad QUIC behövde.

Deploy utan kernelförändringar - det ' är bara en bibliotek
upprepa snabbt - Chrome uppdaterar nya QUIC-versioner konstant
Gå genom de flesta firewalls - UDP-port 443 fungerar oftast
Implementera egen trängselkontroll - inte fast i TCP-algoritmen

Vad QUIC gör annorlunda:

Bekymrt	TCP	QUIC
Tillförlitlighetsenhet	Anslutning		Strom
Handshake	TCP ♫ ♫ + ♫ TLS separat ♫
Enkriptioner	fakultativt TLSM SK2		Mandativt ♫	byggd ♫
HEAD blockering av linjer	Alla data blockerade	Bara påverkade flöden
Verbindningsidentitet	IP ♫ ♫ + ♫ Port ♫
Implementering	Kernel

Konnektionsidentifikationen är särskilt smart.

vägen till HTTP/3:

Precis som SPDY ledde till HTTP

Den standardiserade QUIC skiljer sig från Googles original i vissa detaljer. (, kryptohandslaget omarbetades, ,, några skriftslider format ändrades,),, men kärnans arkitektur, -, strömmar med oberoende förluster återhämta över UDP.

HTTP är HTTP över QUIC, ., det är antagandet att vi måste gå under HTTP för att fixa HTTP

Vad HTTP/3 ändrade:

QUIC över UDP ( inte TCP )
Stream-nivån förlust återhämtning (en förlorad paket bara stannar upp sin ström
snabbare anslutning (0-RTT återhämtades möjligt
Enkriptioner av rädsla (TLS 1.3 inbyggd i QUIC
Kopperingsmigrationen (överlevr IP-adressförändringar )

┌──────────────────────────────────────────┐
│              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        │
└──────────────────────────────────────────┘

Vad var kvar?

HTTP-semantik (GET, POSTM SK2 nagłówna , statuskoder
Cachinglogi
REST-mönster
Allt på applikationslayern

HTTP/3 inte, ' inte ändrade HTTP, . Det ändrade hur HTTP överlever verkligheten.

Varför spelar QUIC någon roll (Detailt)

QUIC implementerar TCP's tillförlitlighetsgarantier per ström, inte per anknytning . Detta är den viktigaste insikten som löser HTTPs fatala fel

TCPs löfte " Varje byt kommer i ordningM SK1 QUIC's löfte " varenda byt i den här strömmen kommer i ordning."

Skillnaden är varför HTTP inte kollapsar på förlorade nätverk. Låt mig förklara hur det faktiskt fungerar.

Avstånd från strömkraft

I QUIC, får varje HTTP-ansökande, /, ett eget flöde. ., Stromer är logiskt oberoende, de delar en koppling för effektivitet.,, men loss av paquet på en ström blockerar inte andra.

QUIC Connection
├── Stream 1: GET /index.html     [packets 1, 2, 3]
├── Stream 3: GET /style.css      [packets 4, 5]     ← packet 5 lost
├── Stream 5: GET /app.js         [packets 6, 7, 8]
└── Stream 7: GET /logo.png       [packets 9, 10]

Packet 5 is retransmitted. Only Stream 3 waits.
Streams 1, 5, 7 continue unaffected.

Föreställ detta med HTTP/2 över TCP: alla dessa strömmar delar en TCP byte sekvens

Verbinding migration:

TCP identifierar kopplingar genom en 4-koppling: källkods IP , källporten

Phone on WiFi → walks out of range → switches to cellular
TCP: Source IP changed. Connection dead. Full reconnect.
QUIC: Connection ID unchanged. Streams continue seamlessly.

Detta är viktigt eftersom mobila användare konstant byta nätverk. Gå ut ur ditt hus , förlora WiFi, byta till mobiltelefoniM SK3 med TCPMska4 varje koppling dörMka5 med QUICMkka6 du kanske inte ens märker det

0-RTT: s återuppbyggnad:

Den traditionella TCP + TLS kräver flera omloppsresor innan data skickas.

TCP SYN/
TLS handshake (1-2 RTT)
Slutligen: skicka din HTTP-ansökande

QUIC kombinerar transport och kryptohandrörelser. Den första kopplingen tar 1 RTT . Men för att återfå användarna med kasserade känneteckenM SK3 QUIC erbjuder ♫ 0- RTT : skicka data omedelbart med ditt första paket ♫.

First visit:    Client ──[handshake]──> Server ──[response]──> Client (1 RTT)
Return visit:   Client ──[data]──────────────────[response]──> Client (0 RTT)

0- RTT har säkerhetsinverkan. ( återuppspelningsangrepp är möjliga, ), så det är begränsat till idempotenta begärningar, ., men för de flesta sidor som laddas, M SK5, så är det ', ett signifikant latens-vinst

Att kryptera som en första medborgare

TCP var designat i 1970s. Kodeneringen kopplades upp senare via TLSM SK2 Detta betyderMSC3

TCP-kolorna är enkla text. ( alla kan se portnummern.
Mittläder kan ( och göra ) för att inspektera och modifiera TCP-trafiken
Enkription är optionell, ofta omröstad efter anslutning

QUIC krypterar nästan allt från början.

TCP packet:   [IP header][TCP header (plaintext)][TLS encrypted payload]
QUIC packet:  [IP header][UDP header][QUIC header (mostly encrypted)][encrypted payload]

Världen som behöver det

HTTP/3 är designad för världen vi faktiskt lever i

Mobila-first: Mer än hälften av webbtrafiken är mobil
Tillförlitliga nätverk: WiFi , mobiltelefoni , trängda offentliga nätverk
Globala användare: Höga latens-kopplingar till avlägsna server
Privatsphäre förväntningar: Enkriptioner är nödvändiga , inte optionellt

Protokollet matchar till slut nätverkens verklighet.

Det kostar på framsteg

HTTP/3 är inte

UDP blockeras ofta av företags-firewaller (fallback till HTTP /2 nödvändigt
Mer CPU för QUIC's gränssnittimplementering ( inte i kerneln som TCP , fast denna klyftan minskar med kernels bypass och optimerade stakar
Nya lösningsverktyg ( tcpdump visar krypterad UDP , inte läsbar HTTP
Interferens med mellanskivan ( vissa nätverk fördriver UDP oförutsägbart )

Men för mobila apparater är den första versionen som matchar hur nätverken faktiskt beter sig

Den verkliga lärdomen över alla versioner

Varje HTTP-versions förändring hände därför att omgivningen förändrades snabbare än protokolet.

Version ♫	♫ Era ♫	♫ Omgivning ♫
HTTP
HTTP
HTTP
HTTP

Pattern är klar:

Protokollet är designat för den nuvarande miljön
Omgivningen förändras ( snabbare än protokoll kan anpassa sig )
Workarounds aggregerar (CDNs, kopplingshackarM SK2 bundling )
Nya protokoll erkänner verkligheten
upprepa

Protokollet trycks hela tiden närmare nätverket.

Andra observationer:

"Stateless" är en lögn som vi säger oss själva att sova på natten . Varje sessionscookie M SK3 auth token , och kaspettern är tillståndskontroll vi
De flesta framgångar kom från lösningar, inte protokoll renhet . CDNs , kaskande tillhandahållare M SK3 anslutningspoolning MSC4 kopplingskollisiering MST5 alla kompenserar för protokollens begränsningar M st6
Saken """, enkelt, " "", fortsatte att röra sig. . "" HTTP "", /1.0 "" var enkelt. . "" Sedan behövde vi ständiga kopplingar.
Timingsfrågor. HTTP/2 skulle ha varit perfekt om den hade kommit in i 2005. På ♫ 2015, ♫ hade mobilen redan ändrat spelet ♫

Vad har inte ändrats sedan 1.0

Här är den obehagliga delen,

Frågorna misslyckas fortfarande. nätverkspartitioner. Server kraschar . Timmar uppstår. Koden behöver fortfarande prövas igen

nätverk ligger fortfarande kvar. 200 OK betyder inte ' det betyder inte att svaret är korrekt . Anslutning stängd betyder inte, ' det innebär inte att begäran inte löstes.

Caches serverar fortfarande gamla data. Cache-Control är en begäran, inte ett kommando

Klienter testar fortfarande dåligt. Användaren klickar på knappen , inget händer, klickar igen. Nu har du två begäranM SK3 Idempotensen

Att utvecklare fortfarande missförstå idempotency. GET borde vara säkert . PUT borde vara idempotent. POST är det vilda västvärlden . De flesta APIs förstår detta fel

// 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.
}

Om du inte förstår de här:

Vad jag faktiskt lärde mig

Efter att ha byggt webbapplikationer över alla dessa protocolversioner

1. Protokollet är inte din tillförlitlighetsschicht

HTTP ger dig en begäran/ respons semantik . Det garanterar ingen levereration, korrekthetM SK4 eller exaktaMska5 en gång bearbetandeMka6 att det är ditt jobbMkka8

2. Latens är fienden , inte bandbredd

De flesta hastighetsproblem är runda - trepunktsbundna, inte genomströmningsbundna

3. Alla " bästa metoder M SK2 har ett utgångsdatum

Domainstörning var nödvändigt för HTTP/1.1. Det ' är aktivt skadligt för Http/2 | ( slår sönder den enskilta M SK4 nyttan med kopplingen ). ♫ " fogar allting in i en enda file MST7 var gudomlighet Mstk8 levererar nu många små moduler över HTTP M stk9 eller Https Mstrk10 är ofta bättre M strk11 Taktiken ändras M Strk12 målet M Stk13 | Reduktion av latens | S stk14 | stannar samma | MS stk15 |

4. mätning på riktiga nätverk

Benchmarker på lokalhost bevisar ingenting. dina användare är på mobila nätverk , hotell WiFi M SK2 och fyllda caféeruppkopplingar . testa där MSC4

5. De tråkiga delarna är viktigast

Timerutbrott. Avbrott . Rutorbrytare. IdempotensenM SK3 Koppling av anslutningar~. Dessa oglamorliga detaljer bestämmer huruvida ditt system fungerar under last.

Slutsatsen

HTTP blev inte snabbare eftersom det blev smartare. nätverket var problemet.

Varje version var rätt för sin tid

HTTP/1.0 var perfekt för att plocka upp dokument
HTTP/1.1 var perfekt för bredband-webapplikationer
HTTP/2 var perfekt för låga-slösa kablare
HTTP/3 är byggd för den mobila realiteten vi faktiskt lever i

Misstaget var att tro att några av dem var permanenta lösningar.

HTTP-versioner är inte uppgraderingar i konsumentens bemärkelse.

Och ändå, ,, efter allt det där,,, är grunderna kvar.

Påträg misslyckas
nätverk ljuger
Att kassera är svårt
Idempoteens

Protokollet utvecklades.

Att bygga system som överlever misslyckanden

Att "'" är tretio år av HTTP , . är webben vi byggde, . Och under ett annat decennium kommer antagandena från Http4 och "Http5" förmodligen se lika daterade ut som de gör nu.

Fortsättning avläsning

RFC 9114: HTTP/3 - Den officiella specifikationen
RFC 9000: QUIC - Transportprotokollet
HTTP/2 förklarad - Daniel Stenberg
Högpresterande webbläsare nätverkande - Ilya Grigorik