HTTP/3 och QUIC, förklarade (och varför din webbplats känns snabbare)
Med några år får webben en ny version av HTTP, och HTTP / 3 är den största förändringen på ett tag - det kastade ut TCP helt. Vad det betyder i enkla termer och varför din telefon märker mer än ditt skrivbord.
HTTP/3 flyttar webben till QUIC, en transport byggd på UDP istället för TCP. Det löser två långvariga problem: anslutningskonfigurationen tar färre rundturer, och ett förlorat paket stannar inte längre allt bakom det. Fördelen är störst på mobila och långdistansförbindelser. Du ändrar inte din webbplats för att få det - din CDN talar det och äldre kunder faller tillbaka automatiskt.
Föreställ dig att du laddar ner en sida över en något opålitlig anslutning - ett tåg, ett upptagen café, var som helst med ett par signalstänger. Tolv filer är på flykt. Ett paket, som tillhör en enda bild, försvinner.
Under TCP stannar allt. Inte bara bilden - CSS, typsnitt, de andra elva filerna. 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 återsändningen kommer. Det är head-of-line blockering, och det är anledningen till att en sida kan frysa halvvägs genom lastning och sedan komma fram på en gång.
HTTP/2 var tänkt att lösa detta. Det lät en webbläsare multiplexera många förfrågningar över en anslutning istället för att öppna sex, som fixade huvud-av-line blockering vid HTTP lager men alla dessa strömmar fortfarande reste inuti en TCP-anslutning, så ett förlorat paket fortfarande stals dem alla på transport 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 är implementerat i operativsystemkärnor och middleboxes över hela internet, och att få dem att uppdatera är inte en plan. Så QUIC byggdes på toppen av 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 det tillhörde. Ditt saknade bildpaket stoppar den bilden. CSS och teckensnitten fortsätter att komma. 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: transport och kryptografiska handslag sker tillsammans, vanligtvis i 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. QUIC stöder 0-RTT-återupptagande, där en klient som har anslutit innan skickar sin första begäran med handskakningen snarare än efter den. Det finns ett förbehåll 0-RTT-data kan spelas upp av en angripare, så det bör bara bära idempotenta förfrågningar men för att hämta en sida är det en riktig 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
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örlust, HTTP / 3 och HTTP / 2 fungerar mycket på samma sätt. Handskakningsbesparingen är verklig men liten i absoluta termer när latensen är 10ms, 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 är marknadsföring.
Det finns också miljöer där UDP stryps eller blockeras direkt - vissa företagsnätverk, några äldre mellanlådor. Klienter hanterar detta genom att falla tillbaka till HTTP/2, vilket är anledningen till att HTTP/3 annonseras snarare än mandat: en server meddelar det via 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 genom ett CDN, det är där HTTP / 3 avslutas, och gör det möjligt är det oftast 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.
Om du vill kontrollera vad en webbläsare förhandlat, öppna DevTools, gå till fliken Nätverk och lägg till kolumnen Protokoll. h3. Observera att den allra första begäran till en domän ofta visar 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 större versionen av HTTP-protokollet, standardiserat 2022. Dess definierande förändring är att den körs över QUIC, ett transportprotokoll byggt på UDP, snarare än över TCP som HTTP/1. 1 och HTTP/2. 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 var utformat i användarutrymme snarare än operativsystemkärnan, vilket är vad som gjorde det deployable över det befintliga internet.
Är HTTP/3 snabbare än HTTP/2?
På mobila, lossy eller hög latens anslutningar, ja - märkbart. Det sparar en till två turer på anslutningsinstallation och stoppar 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 avslutar anslutningen, så det är tillräckligt att aktivera det på din CDN eller kant. 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 utvecklarverktyg, 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 svarshuvudet; 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 inte praktiskt kan ändras. TCP implementeras i operativsystemkärnor och nätverksmellanlådor över hela världen, så varje modifiering 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 handskakningar och head-of-line-blockering. Du skriver inte om någonting - du ser till att din kant talar det 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 värd - sedan han var 16. Han tog tidigt del i ett SaaS-företag och hjälpte till att växa fram till Vismas förvärv, 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.
