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 det betyder i enkle vendinger, og hvorfor din telefon bemærker mere end dit skrivebord.
HTTP/3 flytter internettet til QUIC, en transport bygget på UDP i stedet for TCP. Det løser to langvarige problemer: Tilslutningsopsætningen tager færre ture, og en tabt pakke stopper ikke længere alt bag det. Fordelen er størst på mobil- og langdistanceforbindelser. Du ændrer ikke dit websted for at få det - din CDN taler det, og ældre klienter 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 barer af signal. Tolv filer er på flugt. 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 head-of-line blokering, og det er grunden til, at en side kan fryse halvvejs gennem indlæsning og derefter ankomme på én gang.
HTTP / 2 skulle løse dette. Det lod 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 vandløb stadig rejste inden for en TCP-forbindelse, så en tabt pakke stadig gået i stå dem alle på transport lag. HTTP / 2 flyttede problemet ned et niveau i stedet for at fjerne det.
At ordne det korrekt betød at ændre transporten. Og du kan ikke ændre TCP - det er implementeret i operativsystemkerner og midterbokse på tværs af hele internettet, og at 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 QUIC gør anderledes
Uafhængige streams
QUIC forstår, at en forbindelse bærer flere separate strømme, så en tabt pakke blokerer kun den strøm, den tilhørte. Din manglende billedpakke stopper det billede. CSS og skrifttyperne bliver ved med at ankomme. På en ren kablet forbindelse æ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 rundrejser, før du kan sende en anmodning. QUIC fusionerer dem: transport og kryptografiske håndtryk sker sammen, normalt i en rundtur. På en forbindelse med 150 ms ventetid sparer det 150 til 300 millisekunder på hver ny forbindelse.
QUIC understøtter 0-RTT genoptagelse, hvor en klient, der har tilsluttet før sender sin første anmodning med håndtrykket i stedet for 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 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.
HTTP/3 hjælper ikke meget
Værd at sige klart, fordi benchmarks folk post tendens til at komme fra den bedste sag.
På en hurtig, stabil, kablet forbindelse uden pakketab, HTTP / 3 og HTTP / 2 udføre meget ens. Håndtryksbesparelsen er reel, men lille i absolutte termer, når latensen er 10 ms, og der er ingen tab for stream 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. Klienter håndterer dette ved at falde tilbage til HTTP / 2, hvilket er grunden til, at HTTP / 3 annonceres i stedet for mandat: en server annoncerer det via HTTP / 2. Alt-Svc header, og en klient, der ikke kan gøre QUIC arbejde simpelthen fortsætter over TCP. Ingen bliver strandet.
QUIC krypterer også næsten alt, herunder de fleste transportmetadata, der var synlige i TCP-overskrifter. Det er godt for privatlivets fred og mildt irriterende for netværksoperatører, der plejede at fejlfinde ved at læse pakkeoverskrifter - hvilket er en retfærdig oversigt over, hvorfor vedtagelsen tog så lang tid som det 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 en skifte. Din oprindelse kan blive ved med at tale HTTP/1. 1 til kanten og ingen sind - det ben, der gavner, er den, der krydser det offentlige internet til en telefon.
Hvis du vil kontrollere, hvad en browser forhandlede, skal du åbne DevTools, gå til fanen Netværk og tilføje kolonnen Protokol. h3Bemærk, at den allerførste anmodning til et domæne ofte viser h2, fordi browseren skal forbinde før den kan lære, at HTTP / 3 er tilgængelig; opgraderingen sker på 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 indlæses mere pålideligt på lossy og high-latency forbindelser.
Hvad er QUIC?
QUIC er en transport protokol 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 i stedet for 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, lossy eller high-latency forbindelser, ja - mærkbart. Det sparer en til to rundture på forbindelse opsætning og stopper en enkelt tabt pakke fra stalling hver anden strøm. På en hurtig, stabil kablet forbindelse uden pakketab er forskellen lille, fordi der ikke opstår noget problem. Fordelen skaleres med, hvor upålidelige netværket er.
Skal jeg ændre min hjemmeside 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 over HTTP/3, vises som h3. Den første anmodning til et domæne viser ofte h2, fordi browseren skal oprette forbindelse, 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 swaps TCP til QUIC at fastsætte langsomme håndtryk og hoved-af-line blokering. Du omskriver ikke noget - du sørger for, at din kant taler 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 i IT - for det meste hosting - 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, sikker infrastruktur enkel at bruge.
