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å UDP, og bruges allerede af fremtrædende internetfirmaer som Google og Facebook. Hvis du bruger Chrome og har 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 internetudkastet fra IETF udløber, kan vi i juni 2019 forvente, at HTTP/3 fremmes som en ny, tredje generation af HTTP-standard.

Ligesom med HTTP/2 vil HTTP / 3 igen bygge videre på disse resultater for at hjælpe med at fremskynde internettet. 🚀Click to Tweet

HTTP/3 kommer

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

I 2016 offentliggjorde vi en artikel om HTTP / 2, en standard, der ifølge W3Techs, i øjeblikket har omkring en 34% verdens adopteringsrate. Og ifølge Can I Use, understøttes det også af alle moderne browsere. Men her er vi, skriver en artikel om den næste version af protokollen, HTTP / 3.

HTTP/2 brug

HTTP/2 brug

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 en åben krop, der forener webindustrien og letter diskussionen om retningen af internettet.

I øjeblikket er ID-fasen af HTTP/3 den sidste fase, inden forslagene fremmes til niveauet for RFC-s eller Request-for-Comments, som vi i al væsentlighed kan overveje officielle internetprotokoldefinitioner. Så implementeres derefter af alle de store internet spillere.

Det betyder, at HTTP / 3 skal blive en officiel standard, når udkastet udløber senere i år (juni 2019).

En smule baggrund – Det startede med HTTP/2

På Kinsta er vi besatte af at klemme hvert sidste millisekund fra vores stak, om det udnytter den nyeste version af PHP, leverer data via Google Cloud Platforms premium tier netværk eller caching-aktiver på vores HTTP / 2 CDN.

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.

HTTP/2 push

HTTP/2 push

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.

Ingen rørledning vs rørledning

Ingen rørledning vs rørledning (Billedkilde: Wikipedia, Forfatter Mwhitlock)

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.

HTTP/2 HPACK kompression

HTTP/2 HPACK kompression

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.

Under det er der link lag – den del af protokollen, der er “rent metal” så at sige.

På en sidebesked kan en overbevisende sag for en fuldstændig revision ses fra den hastighed, hvormed skabere af IPFS (interplanetære filsystem) lykkedes at lukke en ICO-finansiering, der støttede dem med 250 mil. USD inden for en måned.

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.

Internet Protokol (RFC791)

Internet Protokol (Billedkilde: RFC791)

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 25% pr. Marts 2019.

IPv6 adoption

IPv6 adoption

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.

Internet Datagram Header

Internet Datagram Header (Billedkilde: RFC791)

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.

At ændre TCP’en på nogen væsentlig måde er ikke en let indsats, fordi protokollen er som en del af TCP / IP-stakken, der går helt tilbage til 70’erne. Den er dybt integreret i operativsystemer, enhedens firmware osv.

UDP

UDP (User Datagram Protool) 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 bred ændring af firmware på alle enheder, der er tilsluttet 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.

HTTP / 2 stack vs HTTP / 3 stack

HTTP / 2 stack vs HTTP / 3 stack

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

Kæmper med nedetid og WordPress-problemer? Kinsta er hostingløsningen designet til at spare din tid! Tjek vores funktioner

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:

Lucas Pardue på HTTP / 3

Lucas Pardue på HTTP / 3

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 håndtryk.

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.

Google service QUIC

Google service QUIC

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 tror, ​​at HTTP / 2-standarden ikke bliver vedtaget endnu, det kan være for tidligt at skubbe til HTTP / 3 (version tre). Dette er et gyldigt punkt, men som vi nævnte, har denne protokol allerede set omfattende test og implementeringer. Google begyndte at teste det så tidligt som 2015, samt Facebook i 2017.

Siden da har andre spillere tiltrådt standardiseringsindsatsen, som Akamai og Mozilla. På den sidste IETF hackathon i november 2018 viste listen over deltagere interesse for QUIC, af virksomheder som Facebook, Apple, Google, Mozilla, NetApp og LiteSpeed ​​Tech. Der var nogle lovende tests, og det ser ud til, at LiteSpeed ​​kan være den første store serverleverandør med en fungerende HTTP / 3-server. Cloudflare kører også QUIC i beta.

Kort efter blev QUIC omdøbt til HTTP / 3 i IETFs Internet Draft. Det udløber i slutningen af ​​juni 2019, og vi kan forvente RFC, eller den endelige standard engang i juli.

I år bliver det spændende, da vi kan forvente at se overgangen fra store softwareleverandører til at implementere den nye standard.

Hvornår vil HTTP / 3 være tilgængelig hos Kinsta?

Vi bruger Nginx hos Kinsta og er derfor nødt til at vente, indtil de officielt understøtter QUIC. I øjeblikket arbejdes der på dette og planlægges for en del af Nginx 1.17-grenen. Når dette er frigivet, kan du garantere, at Kinsta-teamet ser på at tilføje support til det på vores platform.


Hvis du godt kunne lide denne artikel, så vil du elske Kinstas WordPress hostingplatform. Boost dit website og få 24/7 support fra vores WordPress-ekspertteam. Vores Google Cloud-drevne infrastruktur fokuserer på automatisk skalering, ydeevne og sikkerhed. Lad os vise dig Kinsta-forskellen! Tjek vores planer