Hvad er HTTP / 3 – Fakta om den hurtige nye UDP-baserede protokol

TL;DR

I november 2018 mødtes Internet Engineering Task Force (IETF) i Bangkok, og der blev vedtaget et nyt internetudkast. QUIC-transportprotokollen, en HTTP / 2 efterfølger, blev omdøbt til HTTP/3.

HTTP/3 bygger på User Datagram Protocol (UDP) og bruges allerede af fremtrædende internetvirksomheder som Google og Facebook. Hvis du bruger Chrome og opretter forbindelse til en Google-tjeneste, bruger du sandsynligvis allerede QUIC.

Den nye version af HTTP-protokollen nyder godt af UDP-protokollens kraft, og definerer mange af de nye funktioner, der var i tidligere versioner af HTTP på TCP-laget. Dette giver mulighed for at løse begrænsninger inden for den eksisterende internetinfrastruktur.

De første resultater er lovende, og når Internet Draft af IETF udløber, i august 2021, kan vi forvente, at HTTP/3 promoveres som en ny, tredje generations HTTP-standard.

HTTP/3 fremskridt

Nogle siger, at webindustriens sult for mere fart og lavere ventetid kun matches af Google Chrome sult for mere RAM.

For et par år siden offentliggjorde vi en artikel om HTTP/2, en standard, der ifølge W3Techs nu har nået omkring en 45% verdens adoptionsrate. Og ifølge Can I Use understøttes det også af alle moderne webbrowsere. Men her er vi ved at skrive en artikel om den næste version af protokollen, HTTP/3.

HTTP/3 er på tidspunktet hvor vi skriver dette, et IETF Internet-Draft eller ID, hvilket betyder, at det for øjeblikket er under overvejelse for en kommende internetstandard af Internet Engineering Task Force – en international internetstandard, der har ansvaret for at definere og fremme aftalte internetprotokolstandarder, såsom TCP, IPv6, VoIP, Internet of Things osv.

Det er et åbent organ, der forener webindustrien og letter diskussioner om internettets retning. I øjeblikket er “Internet Draft”-fasen af ​​HTTP/3 den sidste fase, før forslag fremmes til niveauet Request-for-Comments (eller RFC’er), som vi for alt i verden kan overveje officielle internetprotokoldefinitioner.

Selvom HTTP/3 endnu ikke er en officiel internetprotokol, er mange virksomheder og projekter allerede begyndt at tilføje HTTP/3-support til deres produkter.

Webbrowsersupport til HTTP/3

På webbrowserens front har Chrome v87, Firefox v88 og Edge v87 alle HTTP/3 som standard aktiveret. For Safari-brugere blev muligheden for at aktivere HTTP/3 tilføjet til Safari Technology Preview v104. Imidlertid er HTTP/3 -understøttelse i øjeblikket ikke tilgængelig i den stabile version af Safari.

Library Support til HTTP/3

For udviklere, der ønsker at udnytte HTTP/3 -teknologier, har mange populære libraries allerede tilføjet support til HTTP/3. Da HTTP/3 stadig er i internetudkastfasen, vil du være sikker på, at du er indstillet på de nyeste opdateringer, når du arbejder med et af nedenstående libraries.

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

Infrastrukturunderstøttelse til HTTP/3

På infrastruktursiden har Cloudflare været førende med support til HTTP/3 på tværs af hele sit edge netværk. Det betyder, at websteder med Cloudflare aktiveret kan drage fordel af HTTP/3’s sikkerhed og forbedringer af ydeevnen uden ekstra arbejde.

På Kinsta er alle de websteder, vi hoster, beskyttet af vores gratis Cloudflare-integration. Ud over en firewall på virksomhedsniveau og DDoS-beskyttelse har Kinsta-kunder også adgang til HTTP/3!

For at teste, om dit websted understøtter HTTP/3, kan du bruge Geekflares HTTP/3 -testværktøj. Indtast blot dit domæne, og tryk på knappen “Check HTTP/3”, så viser værktøjet dig, om dit websted er HTTP/3-aktiveret.

Hvis dit websted understøtter HTTP/3, skal du se en meddelelse som den nedenfor. Da kinstalife.com hostes på Kinsta, understøttes HTTP/3 fuldt ud takket være vores Cloudflare-integration.

Du kan også bruge din browsers inspektør til at søge efter HTTP/3-understøttelse. I dette eksempel bruger vi den nyeste version af Google Chrome, der understøtter HTTP/3.

For at åbne inspektøren skal du højreklikke på siden og klikke på “inspect” og navigere til fanen “Netværk”. I kolonnen “Protocol” kan du se den HTTP-protocol, der bruges til forbindelsen. HTTP/2-forbindelser vises som “h2”, mens HTTP/3-forbindelser vises som “h3-XX” (XX refererer til et specifikt HTTP/3 draft). Som du kan se på billedet herunder, understøtter kinstalife.com forbindelser over “h3-29”, hvilket betyder “HTTP/3 Draft 29”.

Nu hvor vi har gået over den aktuelle status for HTTP/3, lad os tage et dybt dyk ned i nogle af forskellene mellem HTTP/2 vs HTTP/3!

En smule baggrund – Det startede med HTTP/2

HTTP/2 bragte nogle alvorlige forbedringer med ikke-blokerede downloads, pipelining og server push som har hjulpet os med at overvinde nogle begrænsninger af den underliggende TCP-protokol. Det tillod os at minimere antallet af forespørgsels-reaktionscyklusser og håndtryk.

HTTP/2 gjorde det muligt at skubbe mere end én ressource i en enkelt TCP-forbindelse – multipleksering. Vi fik også mere fleksibilitet i rækkefølgen af statiske downloads, og vores sider er nu ikke længere begrænset af en lineær progression af downloadsne.

I praksis betyder det, at en stor javascript ressource nu ikke nødvendigvis er et chokeringspunkt for alle de andre statiske ressourcer, der venter på deres tur.

Føj til disse ting til HTTP / 2’s overskrift HPACK-komprimering og standard binært format for dataoverførsel, og vi har, i mange tilfælde, en signifikant mere effektiv protokol.

Større browser implementeringer gjorde det nødvendigt for websites at implementere kryptering – SSL – for at kunne høste fordelene ved HTTP/2 – og undertiden opstod der en beregningsproces, der gjorde hastighedsforbedringer umærkelig. Der var endda nogle tilfælde, hvor brugerne rapporterede om afmatning efter overgang til HTTP / 2.

Lad os bare sige, at de tidlige dage for vedtagelsen af ​​denne version ikke var for dem der er svage i hjertet.

Nginx-implementeringen manglede også server-push-funktionen, der stod på et modul. Og Nginx-moduler er ikke dine almindelige Apache-drop-in moduler, som du bare kan kopiere – Nginx skal rekompileres med disse.

Mens nogle af disse problemer er løst nu, ser vi på hele protokollstakken, at den primære begrænsning ligger på et lavere niveau end HTTP / 2 turde vove.

For at uddybe dette vil vi dissekere dagens internetprotokolstabel fra bunden til toppen. Hvis du vil vide mere om baggrunden for HTTP / 2, skal du sørge for at tjekke vores ultimative HTTP / 2 guide.

Internet Protokol (IP)

Internet Protokol (IP) definerer bunden af ​​hele internet topologien. Det er den del af internetstakken som er, kan vi sikkert sige, virkelig ikke omsættelig uden at ændre alt, herunder at erstatte hele hardwareinfrastrukturen, fra routere til servere og endda slutbrugernes maskiner.

Så selvom protokollens overhaling kan skyldes, er en sådan vidtrækkende indsats ikke i horisonten på dette tidspunkt, primært fordi vi ikke har nået et levedygtigt, banebrydende, men stadig tilbagevendende kompatibelt alternativ.

Vi kan spore begyndelsen af ​​IP-protokollen tilbage til 1974, til et papir udgivet af Institut for Elektriske og Elektroniske Ingeniører og forfattet af Vint Cerf og Bob Cahn. Det detaljerede pakker sendes via et netværk, router dem på tværs af IP-adresser og numerisk definerede adresser af noder i et netværk. Protokollen definerede formatet af disse pakker, eller datagrammer – dets overskrifter og nyttelast.

Efter RFC 760-definitionen fra 1980 afviklede IETF den definition, der er meget anvendt til denne dag, i dens anmodning om kommentarer 791. Dette er den fjerde version af protokollen, men vi kunne sige, at det er den første produktionsversion.

Det bruger 32-bit adresser, der begrænser antallet af adresser til omkring 4 mia. Denne begrænsning er forklaringen på mysteriet om, hvorfor ikke-erhvervsmæssige internetbrugere får “dynamiske IP-adresser” af deres internetudbydere, og en statisk IP betragtes som en “merværdi” og er ofte genstand for ekstra gebyrer.

De er rationering.

Det var ikke længe, ​​før det blev indset, at 32-bitadresser ikke er nok, og manglen var truende, så mange RFC’er blev offentliggjort, og forsøgte at håndtere dette. Selv om disse løsninger i vid udstrækning anvendes i dag og er en del af vores dagligdag, er det sikkert sikkert at sige dette vil kunne blive til hack.

Internet Protocol version 6 eller IPv6 kom som en metode til at løse disse begrænsninger på, herunder at blive gradvist vedtaget over den tidligere version. Det blev udarbejdet et udkast til standarddokument for IETF i 1998 og blev rejst til en internetstandard i 2017.

Mens IPv4-adresselokalet var begrænset af dets 32-bit adresse længde, blev IPv6-standard givet 128 bit eller 3,4 * 10 ^ 38 mulige adresser. Dette bør være nok til at holde os kørende i nogen tid.

Ifølge Google og IPv6-tilslutning blandt sine brugere er IPv6-vedtagelse lidt over 35% pr. Juni 2021.

IP er et rudimentært lag af internetstakken, der definerer de fleste grundlæggende ting uden garantier for levering, dataintegritet eller bestilling af overførte pakker. På egen hånd er det ikke til at stole på. Overskriftsformatet for IPv4 giver mulighed for hovedkontrolsum, som transmissionsnoderne bruger til at verificere headerens integritet. Dette gør det forskelligt fra IPv6-versionen, som er afhængig af linklaget under, hvilket gør det hurtigere.

At forstå rollen for TCP og UDP

Nu er det tid til at undersøge, hvor HTTP / 3 passer ind med TCP og UDP.

TCP

Mens IP er det underliggende lag af al vores online kommunikation i dag, er TCP (Transmission Control Protocol) en højere del af internetprotokolpakken, hvilket giver den pålidelighed, der er nødvendigt for internettet, mail, filoverførsel (FTP) – til applikation lag / protokoller på internettet.

Dette omfatter multi-step forbindelse etablering, med håndtryk, forsikret rækkefølge af pakker, og videresendelse af tabte pakker. Det giver feedback (Acks) af levering til afsenderen og så videre. Der er også tjeksum beregning for at registrere fejl.

Alt dette tyder på mange trin, der gør TCP til en pålidelig protokol, hvilket gør det til et fundament for de mest berygtede internettjenester, vi bruger i dag.

Dens specifikation tilbage fra 1974 (RFC 675) og 1981 (RFC 793) er ikke ændret væsentligt til denne dag.

Den pålidelighed, som TCP giver, kommer dog ikke uden omkostninger. Overliggende af alle de rundrejser, der kræves ved håndtryk, leveringsfeedbacks, bestillingsgarantier og tjeksummer, der kan betragtes som svage og overflødige. Det har gjort TCP til en flaskehals i den moderne protokolstabel. HTTP / 2 har nået et plateau af hastighedsforbedringer, der kan opnås oven på TCP.

UDP

UDP (User Datagram Protocol) er også en af delene af Internet Protocol Suite, med dens specifikation fra 1980 (RFC 768).

Det er, som navnet antyder, en datagrambaseret forbindelsesløs protokol. Hvilket betyder, at der ikke er håndtryk, og der er ingen forsikringer om bestilling eller levering. Det betyder, at eventuelle mulige trin for at sikre levering, dataintegritet og andre ting overlades til applikationslaget. Det betyder, at en applikationsbygning oven på UDP kan vælge strategier, som den vil anvende afhængigt af konkrete tilfælde, eller det kan muligvis udnytte elementer i linklaget, som checksums, for at undgå overstigning.

Fordi UDP er udbredt ligesom TCP, gør det det muligt at opnå forbedringer uden at kræve firmwareopdateringer på en lang række enheder, der er forbundet til internettet, eller væsentlige ændringer i operativsystemerne.

Implementering af nye protokoller hindres af mange firewalls, NAT’er, routere og andre mellemkasser, der kun tillader, at TCP eller UDP implementeres mellem brugere og de servere, de skal nå. – HTTP / 3 forklaret

Denne tråd på Hacker News kan hjælpe os med at begynde at forstå begrundelsen bag at opbygge den nye HTTP-version ovenpå den eksisterende netværksstak, snarere end at genopfinde den (selvom der er mere til det end som så).

UDP-pakkeformatspecifikation er ret minimal, dens header består af kildeporten, destinationsporten, længden, i bytes, pakkeoverskrift og pakkedata og checksum. Checksum kan bruges til at verificere dataintegritet både for header og data delen af pakken.

Checksum er valgfrit, når det underliggende protokol-lag er IPv4 og obligatorisk med IPv6. Hidtil har UDP er blevet brugt til ting som computersystemer ursynkronisering (NTP), VoIP-applikationer, video streaming, DNS-system og DHCP-protokol.

QUIC og HTTP / 3

QUIC (Quick UDP Internet Connections) blev først implementeret af Google i 2012. Det omdefinerer grænser for netværkslag, afhængig af UDP-protokollen på lavere niveau, omdefinering af håndtryk, pålidelighedsfunktioner og sikkerhedsfunktioner i “brugerrum”, hvilket undgår behovet for opgradering af kerner af internet-brede systemer.

Ligesom med HTTP / 2, vil et fremskridt, der blev spydt ud af Googles SPDY eller speedy, vil HTTP / 3 igen bygge på disse resultater.

Mens HTTP / 2 gav os multipleksering og afbøde hovedlinks-blokering, er det begrænset af TCP. Du kan bruge en enkelt TCP-forbindelse til flere streams multiplexet sammen for at overføre data, men når en af disse strømmer lider et tab af pakker, holdes hele forbindelsen (og alle dens strømme) i gidsler, så at sige, indtil TCP gør dens ting (genudsender den tabte pakke).

Det betyder, at alle pakkerne, selvom de allerede er transmitteret og venter i bufferen i destinationsknudepunktet, blokeres, indtil den forsvundne pakke genudsendes. Daniel Stenberg i sin bog om http / 3, kalder dette et “TCP-baseret linjeblok.” Han hævder, at med 2% pakke tab vil brugerne kunne gøre det bedre med HTTP / 1, med seks forbindelser til afdækning af denne risiko.

QUIC er ikke begrænset af dette. Med QUIC-bygningen på den forbindelsesløse UDP-protokol er konceptet af forbindelse ikke begrænset til TCP, og fejl fra en strøm behøver ikke at påvirke resten.

Som Lucas Pardue fra Cloudflare sætte det:

Med fokus på UDP-strømme opnår QUIC multiplexing uden at skulle ride på en TCP-forbindelse. QUIC bygger sin forbindelse på et højere niveau end TCP. Nye strømme inden for QUIC-forbindelser er ikke tvunget til at vente på, at de andre skal afslutte. QUIC-forbindelser har også gavn af at gøre afkald på TCP-håndtryk, hvilket reducerer ventetiden.

Folk på Cisco lavede en interessant video, der forklarede TCPs 3-vejs handshake:

Mens QUIC går væk fra TCP-pålidelighedsfunktioner, gør den op for det overfor UDP-laget, der giver retransmittering af pakker, bestilling og så videre. Google Cloud Platform introducerede QUIC-støtte til deres belastningsbalancer i 2018 og oplevede en forbedring af den gennemsnitlige sidelastningstid med 8% globalt og op til 13% i regioner, hvor ventetiden er højere.

Mellem Google Chrome, YouTube, Gmail, Googles søgning og andre tjenester kunne Google distribuere QUIC på en god del af internettet uden at vente på IETF. Googles ingeniører hævder at i 2017 var 7% af internettet allerede gennemført over QUIC.

Googles version af QUIC var fokuseret på kun HTTP-transport ved hjælp af HTTP / 2-syntaks. Folk fra IETF (de ansvarlige for standardisering af QUIC) besluttede, at IETF-versionen af ​​QUIC skulle kunne transportere mere end blot HTTP. I øjeblikket er ethvert arbejde på ikke-HTTP-protokoller over QUIC i venteposition.

Endnu en ting, som IETFs arbejdsgruppe har valgt, er, at den standardiserede version skal bruge TLS 1.3-kryptering i stedet for Googles tilpassede løsning. TLS 1.3, sammenlignet med de ældre versioner, bidrager også til protokollhastigheden, da håndtrykkene kræver færre rundrejser. Kinsta understøtter TLS 1.3 på alle vores servere og vores Kinsta CDN.

I øjeblikket fortsætter Google med at bruge sin egen version af QUIC i sit produkt, samtidig med at den styrer sin udviklingsindsats over for IETF-standarderne. De fleste af de andre internet-spillere bygger oven på IETF-versionen (de to adskiller sig i nogle andre aspekter ved siden af ​​kryptering).

Hvis vi åbner Chrome Dev Tools og indlæser nogle af Googles produkter, som Gmail, i protokollens kolonne på fanen Netværk, ser vi mange ressourcer, der lastes via Googles version af QUIC-protokollen. Dette gælder også for Googles produkter som Analytics, Google Tag Manager osv.

Cloudflare offentliggjorde for nylig en meget omfattende opdatering om standardiseringsprocessen.

Mens UDP giver QUIC og HTTP / 3 nogle iboende fordele, giver det også nogle udfordringer.

TCP har været den almindelige protokol i årevis, mens UDP ikke har, så operativsystemer og software stacken for det er generelt ikke optimeret. Derfor er der meget højere CPU-belastning / krav med QUIC, ved nogle estimater, dobbelt så meget som med HTTP / 2.

Optimeringer går dybt ned til kernen i operativsystemer, og forskellige routere og enheder fastware. Denne Red Hat tuning guide kan kaste mere lys på emnet for de mere teknisk tilbøjelige.

Vi kan sige, at QUIC forsøger at genkonstruere TCP-funktioner på toppen af ​​en mere minimal og mere fleksibel protokol.

QUIC-forbindelser, som vi nævnte tidligere, kombinerer TLS og transporterer håndtryk. Når de er etableret, identificeres de af unikke CID’er (forbindelses-id’er). Disse id’er fortsætter over IP-ændringer og kan bidrage til at sikre uafbrudte downloads på f.eks. en switch fra 4G til WiFi. Dette er relevant, især fordi mere og mere internettrafik udføres på mobile enheder. Der kan opstå spørgsmål, om dette element er udtænkt af Google for at lette bedre brugersporing på tværs af forskellige forbindelser og internetudbydere.

TLS er obligatorisk og er beregnet til at gøre det svært for enheder i midten, at manipulere med eller snuse trafikken. Derfor er det ikke sjældent at se firewalludbydere og -leverandører som Cisco at se UDP-protokollen som et problem, og at give måder at deaktivere den. Det er sværere for mellemmænd at inspicere og overvåge eller filtrere QUIC trafik.

QUIC-streams sendes over QUIC-forbindelser, ensretning eller tovejs. Strømme har ID’er, der identificerer initiatoren, og om strømmen er ensrettet eller tovejs og tjener også strømstyring i strømmen.

Mens QUIC er en transportlagprotokol, er HTTP laget oven over det, en applikationslagsprotokol.

Da back-kompatibilitet er af største vigtighed, vil IETF’et, der fremmer implementering af HTTP / 3, indeholde den gamle version (HTT1 eller HTTP / 2) i svaret. Det vil indeholde en overskrift, der informerer klienten om, at HTTP / 3 er tilgængelig sammen med port / værtinformation, som beskrevet i RFC 7838.

Dette er forskelligt fra HTTP / 2, hvor transport kan forhandles inden for TLS-håndtrykket. Men da IETF kun har vedtaget QUIC-baseret HTTP / 3 som den næste standard, kan vi forvente, at webklienter forventer HTTP / 3-support mere og mere. Det er muligt for klienter at cache data fra tidligere HTTP / 3-forbindelser og til at forbinde direkte (null-rundtur eller 0-RTT) ved efterfølgende besøg på samme vært.

Resumé

Der er dem, der mener, at HTTP/2 standarden endnu ikke er vedtaget fuldt ud, kan være for tidligt at foretage et udbredt skub for HTTP/3. Dette er et gyldigt punkt, men som vi nævnte, har denne protokol allerede set store tests og implementeringer. Google begyndte at teste det allerede i 2015 samt Facebook i 2017.

Vi har HTTP/3-support fra store browsere som Google Chrome og Brave. På infrastrukturfronten har webservere som Litespeed og Nginx begge fungerende implementeringer af HTTP/3, mens netværksudbydere som Cloudflare allerede har implementeret fuld support til HTTP/3.

På nuværende tidspunkt er HTTP/3 stadig i internet draft fase, og den seneste revision udløber i august 2021. I år bliver det spændende, da vi kan forvente at se de store softwareleverandørers bevægelse til at implementere den nye standard.

Tonino Jankov

Tonino er en iværksætter, Linux & OSS entusiast, udvikler og teknisk underviser. Han har over ti års erfaring med udvikling og har været i blockchain-området i 3+ år. Når han ikke koder, skriver han for SitePoint og Alibaba Cloud, overvåger de nyeste skønlitterære værker på Netflix og udforsker nye rejsedestinationer.

• Twitter