HTTP/3 och QUIC, förklarade (och varför din webbplats känns snabbare)
Med några års mellanrum får webben en ny version av HTTP, och HTTP/3 är den största förändringen på ett tag – den kastade ut TCP helt och hållet. Vad det betyder rent ut sagt, och varför telefonen märker mer än skrivbordet.
HTTP/3 flyttar webben till QUIC, en transport som bygger på UDP istället för TCP. Det löser två långvariga problem: anslutningskonfigurationen tar färre turer, och ett förlorat paket stoppar inte längre allt bakom det. Fördelen är störst på mobila och fjärranslutna förbindelser. Du ändrar inte din webbplats för att få den – ditt CDN talar den och äldre kunder faller tillbaka automatiskt.
Tänk dig att du laddar ner en sida över en något opålitlig anslutning – ett tåg, ett livligt kafé, var som helst med ett par signalstakar. Tolv filer är på väg. Ett paket, som tillhör en enda bild, försvinner.
Under TCP stannar allt. Inte bara bilden CSS, typsnitt, de andra elva filer. TCP garanterar leverans i ordning, så det håller allt som kom efter det saknade paketet i en buffert och vägrar att lämna något av det till webbläsaren tills vidare sändningen kommer. Det är huvudbBlockering av huvudlinjen till att en sida kan frysa halvvägs genom att ladda och sedan komma fram på en gång.
HTTP/2 var tänkt att lösa detta. Det låter en webbläsare multiplicera många förfrågningar över en anslutning istället för att öppna sex, vilket fixade huvud-av-raden blockering på skärmen. HTTP lagret – men alla dessa strömmar färdades fortfarande inuti en TCP-anslutning, så ett förlorat paket stannade fortfarande upp vid Transporter lager. HTTP/2 flyttade problemet ner en nivå i stället för att ta bort det.
Att fixa det ordentligt innebar att man ändrade transporten. Och du kan inte ändra TCP - det implementeras i operativsystemkärnor och middleboxes över hela internet, och att få dem att uppdatera är inte en plan. Så QUIC byggdes ovanpå UDP istället, i användarutrymme, där det faktiskt kan distribueras och uppdateras.
Vad QUIC gör annorlunda
Oberoende strömmar
QUIC förstår att en anslutning bär flera separata strömmar, så ett förlorat paket blockerar bara strömmen som det tillhörde. Ditt saknade bildpaket stoppar den bilden. CSS och typsnitten fortsätter att komma fram. På en ren trådbunden anslutning ändras ingenting, eftersom ingenting går förlorat. På en mobil anslutning med 2% paketförlust förändras det mycket.
Ett snabbare handslag
Att öppna en TLS-över-TCP-anslutning innebär ett TCP-handslag, sedan ett TLS-handslag – vanligtvis två till tre turer innan du kan skicka en förfrågan. QUIC sammanfogar dem: transporten och de kryptografiska handslagen sker tillsammans, vanligtvis under en rundtur. På en anslutning med 150 ms latens sparar det 150 till 300 millisekunder på varje ny anslutning.
Återkommande besökare kan göra ännu bättre ifrån sig. QUIC stöder 0-RTT-återupptagande, där en klient som har anslutit innan skickar sin första begäran med handslaget snarare än efter det. Det finns ett förbehåll 0-RTT-data kan spelas upp av en angripare, så det bör bara bära idempotent förfrågningar men för att hämta en sida är det en verklig besparing.
Anslutningsmigrering
TCP identifierar en anslutning genom kombinationen av käll-IP, källport, destinations-IP och destinationsport. Ändra någon av dem och det är en annan anslutning, vilket är anledningen till att gå ut ur ditt hus och byta från Wi-Fi till mobil dödar din nedladdning. QUIC identifierar anslutningar med ett anslutnings-ID som färdas med dem, så att samma anslutning överlever nätverksändringen och nedladdningen fortsätter.
När HTTP/3 inte hjälper mycket
Värt att säga tydligt, eftersom de riktmärken som folk postar tenderar att komma från det bästa fallet.
På en snabb, stabil, trådbunden anslutning utan paketförluster fungerar HTTP/3 och HTTP/2 på samma sätt. Handslagsbesparingen är verklig men liten i absoluta termer när latensen är 10 ms, och det finns ingen förlust för strömoberoende att hjälpa till med. Om du bara testar från ditt kontor kan du dra slutsatsen att det hela handlar om marknadsföring.
Det finns också miljöer där UDP stryps eller blockeras direkt – vissa företagsnätverk, vissa äldre mellanlådor. Klienter hanterar detta genom att gå tillbaka till HTTP/2, vilket är anledningen till att HTTP/3 annonseras istället för att vara obligatoriskt: en server meddelar det via HTTP/2. Alt-Svc header, och en klient som inte kan göra QUIC arbete helt enkelt fortsätter över TCP. Ingen blir strandsatt.
QUIC krypterar också nästan allt, inklusive de flesta transportmetadata som var synliga i TCP-huvuden. Det är bra för integriteten och milt irriterande för nätverksoperatörer som brukade felsöka genom att läsa pakethuvuden - vilket är en rättvis sammanfattning av varför antagandet tog så lång tid som det gjorde.
Vad du faktiskt måste göra
Väldigt lite. HTTP / 3 förhandlas automatiskt mellan webbläsare och server, så det praktiska steget bekräftar att det som sitter framför din webbplats erbjuder det. Om din trafik går igenom ett CDN, det är där HTTP / 3 avslutas, och gör det möjligt att det är vanligtvis en växla. Ditt ursprung kan fortsätta att tala HTTP / 1,1 till kanten och ingen bryr sig - benet som gynnar är den som korsar det offentliga internet till en telefon.
Öppna DevTools, gå till fliken Nätverk och lägg till kolumnen Protokoll om du vill kontrollera vad en webbläsare har förhandlat fram. Du letar efter h3. Observera att den allra första begäran till en domän ofta visas h2eftersom webbläsaren måste ansluta innan den kan lära sig att HTTP/3 är tillgängligt; uppgraderingen sker vid efterföljande förfrågningar.
Vanliga frågor
Vad är HTTP/3?
HTTP/3 är den tredje stora versionen av HTTP-protokollet, standardiserat år 2022. Dess definierande förändring är att det körs över QUIC, ett transportprotokoll byggt på UDP, snarare än över TCP som HTTP / 1,1 och HTTP / 2 gör. Detta tar bort transport-nivå head-of-line blockering och förkortar anslutning setup, vilket gör sidor ladda mer tillförlitligt på lossy och hög latens anslutningar.
Vad är QUIC?
QUIC är ett transportprotokoll byggt på UDP som ger pålitlighet, beställning och trängsel kontroll TCP erbjuder, men med oberoende strömmar, en kombinerad transport och TLS handskakning, och anslutning identifierare som Överleva nätverksförändringar. Det utformades i användarutrymme snarare än operativsystemkärnan, vilket gjorde det möjligt att distribuera det över hela det befintliga internet.
Är HTTP/3 snabbare än HTTP/2?
På mobila anslutningar, med förlust eller hög latens, ja – märkbart. Det sparar en till två turer vid anslutningskonfiguration och hindrar ett enda förlorat paket från att stanna varannan ström. På en snabb, stabil trådbunden anslutning utan paketförlust är skillnaden liten, eftersom inget problem uppstår. Fördelen skalas med hur opålitligt nätverket är.
Behöver jag ändra min webbplats för att stödja HTTP/3?
Nej. HTTP/3 förhandlas mellan webbläsaren och vilken server som helst avslutar anslutningen, så det är tillräckligt att aktivera den på din CDN eller edge. Din programkod, HTML- och ursprungsserver ändras inte, och ditt ursprung kan fortsätta att tala HTTP/1,1 till kanten. Webbläsare som inte kan använda HTTP/3 återgår automatiskt till HTTP/2.
Hur vet jag om min webbplats använder HTTP/3?
Öppna webbläsarens utvecklingsverktyg, gå till fliken Nätverk och aktivera kolumnen Protokoll – begäranden som visas via HTTP/3 visas som h3. Den första begäran till en domän visar ofta h2 eftersom webbläsaren måste ansluta innan den lär sig HTTP / 3 är tillgänglig, annonseras via Alt-Svc-svarhuvudet; efterföljande förfrågningar använder h3.
Varför använder QUIC UDP istället för TCP?
Inte för att UDP är snabbare, utan för att TCP praktiskt taget inte kan ändras. TCP är implementerat i operativsystemkärnor och nätverksmellanlådor över hela världen, så varje ändring skulle ta ett decennium att distribuera. Genom att bygga på UDP kan QUIC implementera sin egen tillförlitlighet och trängselkontroll i användarutrymmet, där webbläsare och servrar kan skicka uppdateringar självständigt.
HTTP/3 byter TCP mot QUIC för att åtgärda långsamma handslag och blockering av huvudlinjen. Du skriver inte om någonting – du ser till att din fördel talar för sig själv och låter kunderna förhandla. Utbetalningen landar där det betyder mest: telefoner, svaga signaler och besökare långt från ditt ursprung.
Se hur NordicCDN gör detta för din webbplats:
Mads har arbetat inom IT – mestadels som värd – sedan han var 16. Han tog tidigt del i ett SaaS-företag och hjälpte till att växa fram till förvärvet av Visma, har byggt och drivit datacenternätverk och fungerat som CTO för ett danskt datacenter. Han startade NordicCDN för att göra snabb och säker infrastruktur enkel att använda.