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 juni 2019, kan vi räkna med att HTTP/3 introduceras som en ny, tredje generationens HTTP-standard.

Precis som med HTTP/2, kommer HTTP/3 återigen att bygga på dessa prestationer för att snabba upp webben. 🚀Click to Tweet

HTTP/3 är på ingång

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

I 2016 publicerade vi en artikel om HTTP/2, en standard som, enligt W3Techs, för närvarande har adapterats till runt 34% världen över. Och enligt Can I use stöds det också av alla moderna webbläsare. Men här är vi, och skriver en artikel om nästa version av protokollet, HTTP/3.

HTTP/2 Användning

HTTP/2 Användning

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 ett öppet organ som förenar webb-branschen och främjar diskussionen om vilken riktning internet bör gå.

För närvarande är ID-fasen för HTTP/3 den sista fasen innan förslag befordras till nivån för RFC, eller Begäran-om-Kommentarer, vilket gör det till praktiskt taget officiella internetprotokolldefinitioner. Sedan implementeras det av alla stora internetaktörer.

Detta innebär att HTTP/3 ska bli en officiell standard när utkastet löper ut senare i år (juni 2019).

Lite bakgrund – Det började med HTTP/2

På Kinsta är vi besatta av att klämma ut varje sista möjliga millisekund från vår stack, oavsett om det är att utnyttja den senaste versionen av PHP, levererar data över Google Cloud Platforms premiumnivånätverk eller cacha tillgångar på vårt HTTP/2-CDN.

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.

HTTP/2 push

HTTP/2 push

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.

Ingen pipelining vs pipelining

Ingen pipelining vs pipelining (bildkälla: Wikipedia, författare Mwhitlock)

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.

HTTP/2 HPACK-komprimering

HTTP/2 HPACK-komprimering

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.

Under det finns länklagret – den ”nakna” delen av protokollet, så att säga.

Ett övertygande argument för en fullständig förändring kan ses genom den hastighet med vilken skaparna av IPFS (interplanetary file system) lyckades få till en ICO-finansiering som gav dem 250 mil USD inom en månad.

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.

Internet Protocol (RFC791)

Internet Protocol (bildkälla: RFC791)

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 25% räknat från mars 2019.

IPv6-användning

IPv6-användning

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..

Internet Datagramsrubrik

Internet Datagramsrubrik (bildkälla: RFC791)

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.

Att ändra TCP på något väsentligt sätt är inte ett enkelt projekt, eftersom protokollet är en del av TCP/IP-stacken som funnits så länge som sedan 70-talet. Det är djupt inbäddat i operativsystem, enhetshårdvara, etc.

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 lika utbredd som TCP, är det möjligt att uppnå förbättringar utan att kräva förändring av hårdvara på alla enheter som är anslutna till internet, eller 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.

HTTP/2 stack vs HTTP/3 stack

HTTP/2 stack vs HTTP/3 stack

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).

Kämpar du med driftstopp och WordPress-problem? Kinsta är hosting-lösningen som är utformad för att spara tid! Kolla in våra funktioner

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:

Lucas Pardue om HTTP/3

Lucas Pardue om HTTP/3

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.

Google service QUIC

Google service QUIC

Cloudflare publicerade nyligen 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 tycker att, eftersom HTTP/2 standard inte antas ännu fullt ut, kan det vara för tidigt att arbeta för HTTP/3 (version tre). Detta är en giltig åsikt, men som vi nämnde har detta protokoll redan sett omfattande tester och implementeringar. Google började testa det så tidigt som 2015, liksom Facebook 2017.

Sedan dess har andra spelare gått med i standardiseringsinsatserna, som Akamai och Mozilla. Vid den senaste IETF hackathon i November 2018 visade listan över deltagare intresse för QUIC från företag som Facebook, Apple, Google, Mozilla, NetApp och LiteSpeed Tech. Det fanns några lovande tester, och det ser ut som att LiteSpeed kan vara den första stora serverleverantören med en fungerande HTTP/3-server. Cloudflare kör också QUIC i beta för närvarande.

Strax efter detta döptes QUIC om till HTTP/3 i Internetutkastet från IEFT. Det kommer att löpa ut i slutet av juni 2019, och vi kan förvänta oss RFC, eller den slutliga standarden någon gång i Juli.

Detta år kommer att bli spännande, eftersom vi kan förvänta oss att stora programvaruleverantörer börjar genomföra den nya standarden.

När kommer HTTP/3 att finnas tillgängligt på Kinsta?

Vi använder Nginx på Kinsta och måste därför vänta tills de officiellt stöder QUIC. För
närvarande arbetas det med detta och planeras för en del av Nginx 1.17-grenen. När detta har
släppts kan du garantera att Kinsta-teamet kommer att undersöka möjligheten att lägga till
stöd för det på vår plattform.

Om du tyckte om den här artikeln, då kommer du att älska Kinsta´s hosting-plattform. Effektivisera din hemsida och få support dygnet runt från vårt rutinerade team på WordPress. Vår Google Cloud-drivna infrastruktur fokuserar på auto-skalning, prestanda och säkerhet. Lås oss visa dig skillnaden med Kinsta! Kolla in våra paket