HTTP/3 og QUIC, forklaret (og hvorfor dit websted føles hurtigere)
Hvert par år får internettet en ny version af HTTP, og HTTP/3 er den største ændring i et stykke tid - det kastede TCP helt ud. Hvad betyder det rent ud sagt, og hvorfor din telefon lægger mærke til mere end dit skrivebord?
HTTP/3 flytter internettet til QUIC, en transport, der er bygget på UDP i stedet for TCP. Det løser to langvarige problemer: Tilslutningsopsætningen tager færre ture, og én pakke, der er gået tabt, stopper ikke længere alt bag den. Fordelen er størst på mobile forbindelser og langdistanceforbindelser. Du ændrer ikke dit websted for at få det - dit CDN taler det, og ældre kunder falder automatisk tilbage.
Forestil dig, at du downloader en side over en lidt upålidelig forbindelse – et tog, en travl café, hvor som helst med et par signalstænger. Tolv filer er undervejs. En pakke, der tilhører et enkelt billede, forsvinder.
Under TCP stopper alt. Ikke bare billedet CSS, skrifttyper, de andre elleve filer. TCP garanterer levering i orden, så det holder alt, der ankom efter den manglende pakke i en buffer og nægter at aflevere noget af det til browseren, indtil retransmissionen ankommer. Det er hovedblokering af hovedlinjen til, at en side kan fryse halvvejs gennem indlæsning og derefter komme frem på én gang.
HTTP/2 skulle løse dette problem. Det lader en browser multiplex mange anmodninger over en forbindelse i stedet for at åbne seks, som fast hoved-af-line blokering på HTTP lag men alle disse strømme stadig rejste inden for en TCP-forbindelse, så en tabt pakke De er alle sammen gået i stå i transportmidler at fjerne det.
Det betød, at transporten blev ændret. Og du kan ikke ændre TCP det er implementeret i operativsystem kerner og middleboxes på tværs af hele internettet, og få dem alle til at opdatere er ikke en plan. Så QUIC blev bygget oven på UDP i stedet, i brugerplads, hvor det faktisk kan implementeres og opdateres.
Hvad QIC gør anderledes
Uafhængige streams
QUIC forstår, at en forbindelse bærer flere separate streams, så en tabt pakke kun blokerer strømmen, den tilhørte. Din manglende billedpakke stopper det billede. CSS og skrifttyperne bliver ved med at ankomme. På en ren kabelforbindelse ændrer dette intet, fordi intet går tabt. På en mobil forbindelse med 2% pakketab ændrer det sig meget.
Et hurtigere håndtryk
Åbning af en TLS-over-TCP-forbindelse betyder et TCP-håndtryk, derefter et TLS-håndtryk – typisk to til tre rundture, før du kan sende en anmodning. QUIC smelter dem sammen: Transporten og de kryptografiske håndtryk sker sammen, normalt på én rundtur. På en forbindelse med 150 ms ventetid sparer du 150 til 300 millisekunder ved hver ny forbindelse.
Tilbagevendende besøgende kan gøre det endnu bedre. QUIC understøtter 0-RTT genoptagelse, hvor en klient, der har tilsluttet før sender sin første anmodning med håndtrykket snarere end efter det. Der er en advarsel 0-RTT-data kan afspilles af en angriber, så det bør kun bære idempotente anmodninger men for at hente en side er det en reel besparelse.
Migrering af forbindelse
TCP identificerer en forbindelse ved hjælp af kombinationen af kilde-IP, kildeport, destinations-IP og destinationsport. Skift nogen af dem, og det er en anden forbindelse, hvilket er grunden til at gå ud af dit hus og skifte fra Wi-Fi til mobil dræber din download. QUIC identificerer forbindelser ved hjælp af et forbindelses-id, der rejser med dem, så den samme forbindelse overlever netværksændringen, og overførslen fortsætter.
Når HTTP/3 ikke hjælper meget
Værd at sige klart, fordi benchmarks folk indlæg tendens til at komme fra den bedste sag.
På en hurtig, stabil og kabelbaseret forbindelse uden pakketab fungerer HTTP/3 og HTTP/2 meget på samme måde. Håndtryksbesparelsen er reel, men lille i absolutte tal, når latensen er 10 ms, og der er intet tab for strømmens uafhængighed at hjælpe med. Hvis du kun tester fra dit kontor, kan du konkludere, at det hele er markedsføring.
Der er også miljøer, hvor UDP er kvælet eller blokeret direkte - nogle virksomhedsnetværk, nogle ældre midterbokse. Kunderne håndterer dette ved at vende tilbage til HTTP/2, hvilket er grunden til, at HTTP/3 annonceres i stedet for at have et mandat: en server annoncerer det via HTTP/2. Alt-Svc header, og en klient, der ikke kan få QUIC til at fungere, fortsætter ganske enkelt over TCP. Ingen bliver strandet.
QUIC krypterer også næsten alt, herunder de fleste transportmetadata, der var synlige i TCP-headere. Det er godt for privatlivets fred, og mildt irriterende for netværksoperatører, der plejede at debug ved at læse pakkeoverskrifter - hvilket er en retfærdig oversigt over, hvorfor vedtagelsen tog så lang tid som den gjorde.
Hvad du rent faktisk skal gøre
Meget lidt. HTTP/3 forhandles automatisk mellem browser og server, så det praktiske trin bekræfter, at det, der sidder foran dit websted, tilbyder det. Hvis din trafik går gennem et CDN, er det her, HTTP / 3 afsluttes, og det er normalt muligt at aktivere det som et skifte. Din oprindelse kan holde taler HTTP / 1,1 til kanten og ingen sind benet, der gavner er den, der krydser det offentlige internet til en telefon.
Åbn DevTools for at se, hvad en browser har forhandlet, ved at gå til fanen Netværk og tilføje kolonnen Protokol. Du søger efter h3. Bemærk, at den allerførste anmodning til et domæne ofte vises h2fordi browseren skal oprette forbindelse, før den kan lære, at HTTP/3 er tilgængelig; opgraderingen sker ved efterfølgende anmodninger.
Ofte stillede spørgsmål
Hvad er HTTP/3?
HTTP/3 er den tredje store version af HTTP-protokollen, standardiseret i 2022. Dens definerende ændring er, at den kører over QUIC, en transportprotokol bygget på UDP, snarere end over TCP som HTTP / 1,1 og HTTP / 2 gør. Dette fjerner transport-niveau head-of-line blokering og forkorter forbindelse opsætning, hvilket gør sider belastning mere pålideligt på lossy og high-latency forbindelser.
Hvad er QUIC?
QUIC er en transportprotokol bygget på UDP, der giver pålidelighed, bestilling og overbelastning kontrol TCP tilbyder, men med uafhængige vandløb, en kombineret transport og TLS håndtryk, og forbindelse identifikatorer, der Overlev netværksændringer. Det blev designet i brugerplads snarere end operativsystemets kerne, hvilket gjorde det muligt at implementere det på tværs af det eksisterende internet.
Er HTTP/3 hurtigere end HTTP/2?
På mobile, tabsgivende eller høj latency forbindelser, ja – mærkbart. Det sparer dig for en til to runder ved opsætning af forbindelsen, og det forhindrer en enkelt pakke i at gå i stå på alle andre tidspunkter. På en hurtig, stabil kabelforbindelse uden pakketab er forskellen lille, fordi der ikke opstår noget problem. Fordelen skaleres med, hvor upålidelige netværket er.
Skal jeg ændre mit websted for at understøtte HTTP/3?
Nej. HTTP/3 forhandles mellem browseren og uanset hvilken server der afslutter forbindelsen, så det er tilstrækkeligt at aktivere det på din CDN eller kant. Din programkode, HTML- og oprindelsesserver ændres ikke, og din oprindelse kan fortsætte med at tale HTTP / 1,1 til kanten. Browsere, der ikke kan bruge HTTP/3, falder automatisk tilbage til HTTP/2.
Hvordan kan jeg se, om mit websted bruger HTTP/3?
Åbn din browsers udviklerværktøjer, gå til fanen Netværk, og aktiver kolonnen Protokol – anmodninger, der vises via HTTP/3, vises som h3. Den første anmodning til et domæne viser ofte h2, fordi browseren skal forbinde, før den lærer HTTP / 3 er tilgængelig, annonceret gennem Alt-Svc svar header; efterfølgende anmodninger bruger h3.
Hvorfor bruger QUIC UDP i stedet for TCP?
Ikke fordi UDP er hurtigere, men fordi TCP praktisk talt ikke kan ændres. TCP er implementeret i operativsystemkerner og netværksmiddleboxes over hele verden, så enhver ændring ville tage et årti at implementere. Ved at bygge på UDP kan QUIC implementere sin egen pålidelighed og overbelastningskontrol i brugerplads, hvor browsere og servere kan sende opdateringer uafhængigt.
HTTP/3 bytter TCP ud med QUIC for at rette langsomme håndtryk og blokering af hovedlinjen. Du skriver ikke noget om igen – du sørger for, at din fordel siger det, og lader kunderne forhandle. Udbetalingen lander, hvor det betyder mest: telefoner, svage signaler og besøgende langt fra din oprindelse.
Se, hvordan NordicCDN gør dette for dit websted:
Mads har arbejdet med IT – mest som vært – siden han var 16. Han tog tidligt ejerskab i en SaaS-virksomhed og var med til at udvide den til Visma, har opbygget og drevet datacenternetværk og fungeret som CTO for et dansk datacenter. Han startede NordicCDN for at gøre hurtig og sikker infrastruktur enkel at bruge.
