Vad är HTTP/3 – Detaljerna om det snabba nya UDP-baserade protokollet

TL;DR

I November 2018 möttes Internet Engineering Task Force (IETF) i Bangkok, och ett nytt Internetutkast antogs. QUIC Transport Protocol, en uppföljare till HTTP/2, döptes om till HTTP/3.

HTTP/3 bygger på UDP, och används redan av framstående Internetföretag som Google och Facebook. Om du använder Chrome och ansluter till en Google-tjänst använder du förmodligen redan QUIC.

Den nya versionen av HTTP-protokollet drar nytta av det rena, nakna UDP-protokollet, och definierar många av de nya funktionerna som fanns i tidigare versioner av HTTP vid TCP-skiktet. Detta ger ett sätt att lösa begränsningar inom den befintliga Internetinfrastrukturen.

De första resultaten är lovande, och när Internetutkastet från IETF löper ut i augusti 2021, kan vi räkna med att HTTP/3 introduceras som en ny, tredje generationens HTTP-standard.

HTTP/3 Framsteg under 2024

Vissa säger att webbindustrins hunger efter mer fart och lägre latens bara matchas av Google Chromes hunger efter mer RAM.

För några år sedan publicerade vi en artikel om HTTP/2, en standard som enligt W3Techs nu har nått en adoptionsgrad på ca 45% i världen. Och enligt Can I Use, stöds det även av alla moderna webbläsare. Trots detta skriver vi redan en artikel om nästa version av protokollet, HTTP/3.

HTTP/3 är, vid skrivande stund, ett IETF Internet-utkast eller ID, vilket innebär att det för närvarande är under övervägande för en kommande Internet-standard från Internet Engineering Task Force – ett internationellt Internetstandards-organ, som ansvarar för att definiera och främja överenskomna internetprotokoll standarder, såsom TCP, IPv6 , VoIP, Internet of Things, etc.

Det är en öppen kropp som förenar webbindustrin och underlättar diskussionen om internets riktning. För närvarande är ”Internet Utkast”-fasen av HTTP/3 den sista fasen innan förslagen kommer till nivån för Request-for-Comments (eller RFC). Där kan det bli, för alla avsikter och syften, en officiell protokolldefinition för internet.

Även om HTTP/3 ännu inte är ett officiellt internetprotokoll, har många företag och projekt redan börjat lägga till HTTP/3-stöd i sina produkter.

Webbläsarsupport för HTTP/3

Webbläsarna Chrome v87, Firefox v88 och Edge v87 har HTTP/3 aktiverat som standard. För Safari-användare lades alternativ för aktivering av HTTP/3 till i Safari Technology Preview v104. HTTP/3-stöd är dock för närvarande inte tillgängligt i den stabila versionen av Safari.

Biblioteksstöd för HTTP/3

För utvecklare som vill utnyttja HTTP/3-tekniken har många populära bibliotek redan lagt till stöd för HTTP/3. Eftersom HTTP/3 fortfarande befinner sig i utkast-stadiet bör du se till att du har de senaste uppdateringarna när du arbetar med något av biblioteken nedan.

• Python – http3 och aioquic
• Rust – quiche, neqo, och quinn
• C – nghttp3 och lsquic
• Go – quicgo
• JavaScript – Node.js

Infrastrukturstöd för HTTP/3

På infrastruktursidan har Cloudflare gått i täten och har stöd för HTTP/3 över hela sitt kantnätverk. Detta innebär att webbplatser som har Cloudflare aktiverat kan dra nytta av säkerhets- och prestandaförbättringarna i HTTP/3 utan ytterligare arbete.

Alla webbplatser som hostas av Kinsta skyddas av vår kostnadsfria Cloudflare-integrering. Förutom en brandvägg på enterprise-nivå och DDoS-skydd har Kinsta’s kunder även tillgång till HTTP/3!

För att testa om din webbplats stöder HTTP/3 kan du använda Geekflares HTTP/3 testverktyg. Skriv bara in din domän och tryck på knappen ”Kontrollera HTTP/3”, så visar verktyget om din webbplats är HTTP/3-aktiverad.

Om din webbplats stöder HTTP/3 bör du se ett meddelande som det här nedanför. Eftersom kinstalife.com hostas på Kinsta stöds HTTP/3 fullt ut tack vare vår Cloudflare-integrering.

Du kan även använda webbläsarens inspektör för att söka efter HTTP/3-stöd. I det här exemplet kommer vi att använda den senaste versionen av Google Chrome som stöder HTTP/3.

För att öppna inspektören högerklickar du på sidan och klickar på ”Inspektera” och navigerar till fliken ”Nätverk”. I kolumnen ”Protokoll” kan du se det HTTP-protokoll som används för anslutningen. HTTP/2-anslutningar visas som ”h2”, medan HTTP/3-anslutningar visas som ”h3-XX” (XX refererar till ett specifikt HTTP/3-utkast). Som du kan se i bilden nedan stöder kinstalife.com anslutningar över ”h3-29”, vilket betyder ”HTTP/3 Utkast 29”.

Nu när vi har gått igenom den aktuella statusen för HTTP/3, låt oss djupdyka i några av skillnaderna mellan HTTP/2 vs HTTP/3!

Lite bakgrund – Det började med HTTP/2

HTTP/2 förde med sig några viktiga förbättringar med icke-blockerande nedladdningar, pipelining och server push som har hjälpt oss att övervinna vissa begränsningar i det underliggande TCP-protokollet. Det gjorde det möjligt för oss att minimera antalet begäran-svar-cykler och handskakningar.

HTTP/2 gjorde det möjligt att driva mer än en resurs i en enda TCP-anslutning – multiplexering. Vi fick också mer flexibilitet vid beställning av statiska nedladdningar, och våra sidor begränsas nu inte längre av nedladdningarnas linjära progression.

I praktiken betyder det att en stor JavaScript-resurs nu inte nödvändigtvis motsvarar en kvävningspunkt för alla andra statiska resurser som väntar på sin tur.

Lägg till dessa saker HTTP/2:s HPACK-komprimering och standardiserade  binära format för dataöverföring, och vi har, i många fall, ett betydligt effektivare protokoll.

Större webbläsarimplementeringar gjorde det ett krav för webbplatser att använda kryptering – SSL – för att kunna utnyttja fördelarna med HTTP/2-och ibland uppstod ett beräkningsoverhead som gjorde hastighetsförbättringar obemärkliga. Det fanns även vissa fall där användare rapporterade långsammare hastigheter efter övergång till HTTP/2.

Låt oss bara säga att den första tiden för denna version inte var för de svagsinta.

Nginx-implementeringen saknade också server-push-funktionen, och förlitade sig på en modul. Och Nginx-moduler är inte dina vanliga Apache drop-in-moduler som du bara kan kopiera – Nginx måste kompileras om med dessa.

Medan några av dessa problem nu är lösta; om vi tittar på hela protokollstacken ser vi att den primära begränsningen ligger på en lägre nivå än HTTP/2 vågade sig på.

För att utveckla detta kommer vi att dissekera dagens internetprotokollstack från grunden till toppen. Om du vill veta mer om bakgrunden till HTTP/2, se till att kolla in vår ultimata HTTP/2 guide.

Internet Protocol (IP)

Internet Protocol (IP) utgör den nedre delen av hela Internet-topologin. Det är den del av Internet-stacken som, kan vi säkert säga, verkligen inte är förhandlingsbar utan att ändra allt, inklusive att ersätta hela hårdvaruinfrastrukturen, från routrar till servrar och till och med slutanvändarnas maskiner.

Så, medan det kan vara dags för en protokolländring, är ett sådant långtgående projekt ännu inte på horisonten, främst för att vi inte har kommit fram till ett livskraftigt, banbrytande, men bakåtkompatibelt alternativ.

Vi kan spåra början av IP-protokollet tillbaka till 1974, till en rapport som publicerades av Institute of Electrical and Electronics Engineers och författades av Vint Cerf och Bob Cahn. Denna rapport detaljerade datapaket som skickas över ett nätverk, dirigeras över IP-adresser, och numeriskt definierade adresser av noder i ett/flera nätverk. Protokollet definierade formatet för dessa paket, eller datagram – dess rubrik och nyttolast.

Efter RFC 760-definitionen från 1980 slutade IETF med den definition som används i dag, i sin Begäran Om Kommentarer 791. Detta är den fjärde versionen av protokollet, men vi kan säga att det är den första produktionsversionen.

Den använder 32-bitarsadresser, vilket begränsar antalet adresser till cirka 4 miljarder. Denna begränsning är förklaringen till mysteriet om varför icke-affärsmässiga Internetanvändare får ”dynamiska IP-adresser” av sina Internetleverantörer, och en statisk IP anses vara ett ”mervärde” och ofta kostar extra.

De ransonerar.

Det gick inte länge tills man insåg att 32-bitars adresser inte räcker, och bristen var hotande, så många RFC publicerades för att försöka hantera detta. Även om dessa lösningar används i stor utsträckning idag, och är en del av vårt dagliga liv, är det förmodligen säkert att säga dessa leder till hackningar.

Internet Protocol version 6 eller IPv6 kom som ett sätt att ta itu med dessa begränsningar, inklusive att gradvis användas istället för den tidigare versionen. Det gjordes ett utkast till standarddokument för IETF 1998 och upphöjdes som internetstandard 2017.

Medan IPv4-adressutrymmet begränsades av sin 32-bitars adresslängd, fick IPv6-standarden 128 bitar, eller 3,4*10^38 möjliga adresser. Detta borde räcka länge.

Enligt Google och IPv6 är IPv6-användningen lite drygt 35% räknat från juni 2021.

IP är ett rudimentärt lager av Internet-stacken, som definierar de mest grundläggande saker, utan garantier för leverans, dataintegritet eller beställning av överförda datapaket. På egen hand är det opålitligt. Rubrikformatet för IPv4 innehåller rubrikkontrollsumma, som överföringsnoderna använder för att verifiera integriteten i rubriken. Detta gör det annorlunda än IPv6-versionen, som bygger på länkskiktet under, vilket gör det möjligt att bli snabbare..

Förstå TCP och UDP:s roll

Nu är det dags att utforska var HTTP/3 passar in med TCP och UDP.

TCP

Medan IP är det underliggande lagret av alla våra online-kommunikation idag är TCP (Transmission Control Protocol) på en högre nivå av Internet protocol suite, vilket ger tillförlitlighet som behövs för webben, mail, filöverföring (FTP) – för applikationslager/protokoll på internet.

Detta inkluderar flerstegs-anslutningsetablering, med handskakningar, säker beställning av datapaket, och återsändning av förlorade paket. Det ger feedback (Acks) för leverans till avsändaren och så vidare. Det finns också kontrollsummaberäkning för att upptäcka fel.

Alla dessa saker indikerar många steg som gör TCP till ett tillförlitligt protokoll, vilket gör det till en grund för de mest kända internettjänster vi använder idag.

Dess specifikation som går tillbaka till 1974 (RFC 675) och 1981 (RFC 793) har inte förändrats väsentligt till denna dag.

Tillförlitligheten som TCP tillhandahåller kommer dock inte utan kostnad. Overhead av alla roundtrips som krävs för handskakningar, leveransfeedback, beställningsgarantier och kontrollsummor som kan betraktas som svaga och redundanta. Det har gjort TCP till en flaskhals i den moderna protokollstacken. HTTP/2 har nått en mängd hastighetsförbättringar som kan uppnås ovanpå TCP.

UDP

(UDP) User Datagram Protocol är också en av delarna av Internet Protocol Suite, med en specifikation som går tillbaka till 1980 (RFC 768).

Det är, som namnet antyder, ett datagram-baserat anslutningslöst protokoll. Vilket innebär att det inte finns några handskakningar och det finns inga garantier för beställning eller leverans. Detta innebär att eventuella steg för att säkerställa leverans, dataintegritet och andra saker lämnas till applikationsskiktet. Det innebär att en applikation som byggs ovanpå UDP kan välja de strategier som den kommer att använda beroende på det konkreta fallet, eller eventuellt utnyttja element i länkskiktet, som kontrollsummor, för att undvika overhead.

Eftersom UDP är utbrett precis som TCP är det möjligt att uppnå förbättringar utan att ett brett utbud av enheter som är anslutna till internet kräver firmwareuppdateringar. Det krävs inte heller betydande förändringar i operativsystemen.

Utplacering av nya protokoll hämmas av många brandväggar, NATs, Routrar och andra mellanlådor som bara tillåter att TCP eller UDP distribueras mellan användare och de servrar de behöver nå. – HTTP/3 förklarat

Denna tråd på Hacker News kan hjälpa oss att börja förstå resonemanget bakom att bygga den nya HTTP-versionen ovanpå den befintliga nätverksstacken, snarare än att återuppfinna den (även om det finns mer än det).

UDP paketformats-specifikation är ganska minimal, dess rubrik består av källporten, destinationsport, längd, byte, paketrubrik och paketdata, och kontrollsumma. Kontrollsumma kan användas för att verifiera dataintegritet både för rubrik och datadel av paketet.

Kontrollsumma är valfritt när det underliggande protokollskiktet är IPv4 och obligatoriskt med IPv6. Hittills har UDP använts för saker som datorsystem klocksynkronisering (NTP), VoIP-applikationer, videostreaming, DNS-system och DHCP-protokoll.

QUIC och HTTP/3

QUIC (Quick UDP Internet Connections) distribuerades först av Google i 2012. Det omdefinierar gränserna för nätverkslager, förlitar sig på UDP-protokoll på lägre nivå, omdefinierar handskakningar, tillförlitlighetsfunktioner och säkerhetsfunktioner i ”användarutrymme”, vilket undviker behovet av att uppgradera kärnor i Internet-omfattande system.

Precis som med HTTP/2, en utveckling som främst drevs av Googles SPDY eller Speedy, kommer HTTP/3 återigen att bygga på dessa prestationer.

Medan HTTP/2 gav oss multiplexering, och mildrande av head-of-line-blockering, begränsas det av TCP. Du kan använda en enda TCP-anslutning för flera strömmar multiplexerade tillsammans för att överföra data, men när en av dessa strömmar lider av en paketförlust hålls hela anslutningen (och alla dess strömmar) gisslan så att säga, tills TCP gör sin grej (omöverför det förlorade paketet).

Det innebär att alla paket, även om de redan överförs och väntar blockeras i bufferten i destinationsnoden tills det förlorade paketet omöverförs. Daniel Stenberg i sin bok på http/3 kallar detta en ”TCP-baserad head-of-line-blockering.” Han hävdar att användarna, med 2% paketförlust, kommer att klara sig bättre med HTTP/1, med sex anslutningar för att skydda mot denna risk.

QUIC begränsas inte av detta. Med QUIC-byggnad på det anslutningsfria UDP-protokollet bär anslutningarna inte begränsningarna hos TCP och misslyckanden i en ström behöver inte påverka resten.

Som Lucas Pardue från Cloudflare säger:

Med fokus på UDP-strömmar uppnår QUIC multiplexering utan att behöva rida på en TCP-anslutning. QUIC bygger sin anslutning på en högre nivå än TCP. Nya strömmar inom QUIC-anslutningar tvingas inte vänta på att de andra ska avsluta. QUIC-anslutningar drar också nytta av att göra sig av med TCP-handskakningsoverhead, vilket minskar latens.

Folk på Cisco gjorde en intressant video som förklarar TCP:s 3-vägs-handskakning.

Medan QUIC gör sig av med TCP-tillförlitlighetsfunktioner, gottgör det för detta ovanför UDP-skiktet, vilket ger omöverföring av paket, beställning och så vidare. Google Cloud Platform introducerade QUIC-stöd för sina lastbalanserare 2018 och såg en förbättring av genomsnittlig sidladdningstid med 8% globalt och upp till 13% i regioner där latensen är högre.

Genom Google Chrome, YouTube, Gmail, Googles sökning och andra tjänster kunde Google distribuera QUIC på en bra bit av internet utan att vänta på IETF. Googles ingenjörer hävdar att i 2017 drevs 7% av internettrafiken redan över QUIC.

Googles version av QUIC var inriktad på bara HTTP-transport, med hjälp av HTTP/2-syntax. Folk från IETF (de som ansvarar för standardisering QUIC) bestämde att IETF-versionen av QUIC borde kunna transportera mer än bara HTTP. För närvarande är dock allt arbete på icke-HTTP-protokoll över QUIC på is.

En sak som IETF:s arbetsgrupp bestämde är att den standardiserade versionen kommer att använda TLS 1.3-kryptering istället för Googles anpassade lösning. TLS 1.3, jämfört med de äldre versionerna, bidrar också till protokollhastigheten, eftersom dess handskakning kräver färre rundresor. Kinsta stöder TLS 1.3 på alla våra servrar och vår Kinsta CDN.

Just nu fortsätter Google att använda sin egen version av QUIC i sin produkt, samtidigt som de riktar sina utvecklingsinsatser mot IETF-standarderna. De flesta andra internetspelare bygger på IETF-versionen (de två skiljer sig åt i några andra aspekter förutom kryptering).

Om vi öppnar Chrome Dev Tools och laddar några av Googles produkter, som Gmail ser vi, i protokollkolumnen på fliken Nätverk, många resurser som laddas via Googles version av QUIC-protokollet. Detta är också fallet för Googles produkter som Analytics, Google Tag Manager, etc.

Cloudflare publicerade en mycket omfattande uppdatering om standardiseringsutvecklingen.

Medan UDP ger QUIC och HTTP/3 några inneboende fördelar, ger det också vissa utmaningar.

TCP har varit det vanliga protokollet i flera år, men inte UDP, så operativsystem och mjukvarustacken för det är i allmänhet inte lika optimerad. Följaktligen finns det mycket högre CPU-belastning/krav med QUIC, enligt vissa uppskattningar, dubbelt så mycket som med HTTP/2.

Optimeringar går djupt ner till kärnan i operativsystem, och olika routrar och enhetshårdvara. Denna Red Hat guide kan kasta mer ljus på ämnet för de mer tekniskt kunniga.

Vi kan säga att QUIC försöker omkonstruera TCP-funktioner ovanpå ett mer minimalt och mer flexibelt protokoll.

QUIC-anslutningar, som vi nämnde tidigare, kombinerar TLS och transporthandskakningar. När de väl har fastställts identifieras de av unika Cids (anslutnings-ID). Dessa ID kvarstår över IP-ändringar och kan bidra till att säkra oavbrutna nedladdningar vid, till exempel, ett byte från 4G till WiFi. Detta är relevant, särskilt eftersom allt mer Internettrafik utförs på mobila enheter. Frågor kan uppstå om detta element är tänkt av Google att underlätta bättre användarspårning mellan olika anslutningar och Internetleverantörer.

TLS är obligatoriskt, och är tänkt att göra det svårt för enheter i mitten att manipulera det, eller avläsa trafiken. Det är därför det inte är ovanligt att se brandväggsleverantörer och leverantörer som Cisco se UDP-protokollet som ett problem och att ge sätt att inaktivera det. Det är svårare för mellanhänder att inspektera och övervaka eller filtrera QUIC-trafik.

QUIC-strömmar skickas över QUIC-anslutningar, enkelriktad eller dubbelriktad. Strömmar har ID, som identifierar instigatorn , och om strömmen är enkelriktad eller dubbelriktad, och även tjänar som flödeskontroll i strömmen.

Medan QUIC är ett transportlagerprotokoll är HTTP skiktet ovanför det, ett programlagerprotokoll eller applikationsprotokoll.

Eftersom bakåtkompatibilitet är av yttersta vikt, kommer det IETF-främjade genomförandet av HTTP/3 inkludera den gamla versionen (HTT1 eller HTTP/2) i svaret. Det kommer att innehålla en rubrik som informerar klienten om att HTTP/3 är tillgänglig, tillsammans med port/värdinformation, som beskrivs i RFC 7838.

Detta skiljer sig från HTTP/2, där transport kan förhandlas inom TLS-handskakningen. Men eftersom IETF i princip har antagit QUIC-baserade HTTP/3 som nästa standard, kan vi förvänta oss webbklienter att ordna HTTP/3-support mer och mer. Det är möjligt för klienter att cacha data från tidigare HTTP/3-anslutningar, och att ansluta direkt (noll-rundresa, eller 0-RTT) på efterföljande besök till samma värd.

Sammanfattning

Det finns de som anser att i och med att HTTP/2-standarden ännu inte har antagits fullt ut kan det vara för tidigt att göra en utbredd kampanj för HTTP/3. Detta är en rimlig fundering, men som vi nämnde tidigare har detta protokoll redan genomgått storskaliga tester och implementeringar. Google började testa detta redan 2015, Facebook 2017.

Under 2024 har vi HTTP/3-stöd från stora webbläsare som Google Chrome och Brave. På infrastruktur-fronten har webbservrar som Litespeed och Nginx fungerande implementeringar av HTTP/3, medan nätverksleverantörer som Cloudflare redan har distribuerat fullt stöd för HTTP/3.

För närvarande är HTTP/3 fortfarande i utkast-fasen och den senaste revideringen kommer att upphöra i augusti 2021. Detta år kommer att bli spännande, eftersom vi kan förvänta oss att även de stora programvaru-leverantörerna implementerar den nya standarden.

Tonino Jankov

Tonino är en entreprenör, Linux- och OSS-entusiast, utvecklare och teknisk utbildare. Han har över tio års erfarenhet av utveckling och har varit i blockchain-området i 3+ år. När han inte kodar skriver han för SitePoint och Alibaba Cloud, tittar på de senaste skönlitterära verken på Netflix och utforskar nya resmål.

• Twitter