Wat is HTTP/3? Inzicht in dit snelle nieuwe protocol

In november 2018 kwam de Internet Engineering Task Force (IETF) bijeen in Bangkok en werd een nieuw internet-concept goedgekeurd. Het QUIC-transportprotocol, een HTTP/2-opvolger, werd hernoemd naar HTTP/3.

HTTP/3 is gebaseerd op UDP en wordt al gebruikt door vooraanstaande internetbedrijven zoals Google en Facebook. Als je Chrome gebruikt en verbinding maakt met een Google-service, gebruik je waarschijnlijk al QUIC.

De nieuwe versie van het HTTP-protocol profiteert van het bare-metal, low-level UDP-protocol en definieert veel van de nieuwe functies die in eerdere versies HTTP op de TCP-laag aanwezig waren. Dit biedt een manier om beperkingen op te lossen binnen de bestaande internetinfrastructuur.

De eerste resultaten zijn veelbelovend en wanneer de Internet Draft van IETF in augustus 2021 afloopt, kunnen we verwachten dat HTTP/3 wordt beschouwd als een nieuwe derde-generatie HTTP standaard.

Ontwikkelingen HTTP/3

Sommigen zeggen dat de honger van de webindustrie naar meer snelheid en lagere latency alleen wordt geëvenaard door de honger van Google Chrome naar meer RAM.

Een paar jaar geleden publiceerden we een artikel over HTTP/2, een standaard die volgens W3Techs op dit moment wereldwijd een acceptatiegraad van ongeveer 45% heeft bereikt. En volgens Can I Use wordt het ondersteund door alle moderne webbrowsers. Toch zijn we hier aanbeland, een artikel over de volgende versie van het protocol: HTTP/3.

HTTP/3 is, op het moment van schrijven, een IETF Internet-Concept of ID, wat betekent dat het momenteel wordt overwogen voor een nieuwe internet-standaard door de Internet Engineering Task Force – een internationale instantie voor internet-normen, die belast is met het definiëren van en het bevorderen van overeengekomen internetprotocol-standaarden, zoals TCP, IPv6, VoIP, Internet of Things, enz.

Het is een open instantie die de webindustrie verenigt en de discussie over de richting van internet faciliteert. Momenteel is de “Internet Draft” fase van HTTP/3 de laatste fase voordat voorstellen worden gepromoveerd tot het niveau van Request-for-Comments (of RFC’s), die we in alle opzichten kunnen beschouwen als officiële internetprotocoldefinities.

Hoewel HTTP/3 nog geen officieel internetprotocol is, zijn veel bedrijven en projecten al begonnen met het inbouwen van HTTP/3-ondersteuning in hun producten.

Webbrowserondersteuning voor HTTP/3

Op het gebied van webbrowsers hebben Chrome v87, Firefox v88 en Edge v87 standaard HTTP/3 ingeschakeld. Voor gebruikers van Safari is de optie om HTTP/3 in te schakelen, toegevoegd in de Safari Technology Preview v104. Dat betekent echter wel dat ondersteuning voor HTTP/3 momenteel niet beschikbaar is in een stabiele versie van Safari.

Library ondersteuning voor HTTP/3

Voor ontwikkelaars die gebruik willen maken van HTTP/3 technologie: veel populaire library’s hebben inmiddels ondersteuning voor HTTP/3 toegevoegd. Aangezien HTTP/3 zich nog in de Internet Draft fase bevindt, moet je ervoor zorgen dat je de laatste updates gebruikt wanneer je met een van de onderstaande library’s werkt.

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

Ondersteuning infrastructuur voor HTTP/3

Wat de infrastructuur betreft, loopt Cloudflare voorop met ondersteuning voor HTTP/3 in het hele Edge netwerk. Dit betekent dat sites waarop Cloudflare is ingeschakeld, zonder iets te doen, kunnen profiteren van de beveiligings- en prestatieverbeteringen van HTTP/3.

Bij Kinsta worden alle sites die we hosten beschermd door onze gratis Cloudflare integratie. Naast een enterprise-level firewall en DDoS bescherming hebben Kinsta klanten ook toegang tot HTTP/3!

Om te testen of je site HTTP/3, ondersteunt, kun je de HTTP/3 testtool van Geekflare gebruiken. Typ eenvoudig je domein in en druk op de knop “Check HTTP/3” en de tool laat je weten of je site HTTP/3 compatibel is.

Als je site HTTP/3 ondersteunt, zie je een bericht zoals hieronder. Omdat kinstalife.com wordt gehost op Kinsta, wordt HTTP/3 volledig ondersteund dankzij onze Cloudflare integratie.

U kunt ook de inspector van je browser gebruiken om te checken of HTTP/3 wordt ondersteund. In dit voorbeeld gebruiken we de nieuwste versie van Google Chrome die HTTP/3 ondersteunt.

Om de Inspector te openen, klik je met de rechtermuisknop op de pagina en klik je op “Inspect”, en navigeer je naar het tabblad “Network”. In de kolom “Protocol” zie je het HTTP protocol dat voor de verbinding is gebruikt. HTTP/2 verbindingen worden weergegeven als “h2” terwijl HTTP/3 verbindingen verschijnen als “h3-XX” (XX verwijst naar een specifieke HTTP/3 draft). Zoals je in de onderstaande afbeelding kan zien, ondersteunt kinstalife.com verbindingen via “h3-29”, wat “HTTP/3 Draft 29” betekent.

Nu we de huidige status van HTTP/3, hebben doorgenomen, gaan we dieper in op enkele verschillen tussen HTTP/2 en HTTP/3!

Een beetje achtergrondinformatie — Het Begon met HTTP/2

HTTP/2 bracht enkele serieuze verbeteringen met niet-blokkerende downloads, pipelining en server-push, wat ons heeft geholpen een aantal beperkingen van het onderliggende TCP-protocol te overwinnen. Hierdoor konden we het aantal cycli voor verzoeken, antwoorden en handshakes minimaliseren.

HTTP/2 maakte het mogelijk om meer dan één bron in één TCP-verbinding te duwen – multiplexing. We kregen ook meer flexibiliteit bij het aanvragen van statische downloads en onze pagina’s worden nu niet langer beperkt door een lineaire voortgang van downloads.

In de praktijk betekent dit dat nu één grote javascript-resource niet noodzakelijk gelijk staat aan een knelpunt voor alle andere statische bronnen die op hun beurt moeten wachten.

Voeg daar de HTTP/2 header HPACK-compressie en standaard binair formaat van gegevensoverdracht aan toe en we hebben in veel gevallen een aanzienlijk efficiënter protocol.

Voor grote browser-implementaties was het een vereiste voor websites om versleuteling te implementeren – SSL – om de voordelen van HTTP/2 te kunnen benutten – en soms had dit als resultaat een rekenoverhead die snelheidsverbeteringen onmerkbaar maakte. Er waren zelfs enkele gevallen waarin gebruikers een vertraging rapporteerden na de overgang naar HTTP/2.

Laten we zeggen dat de eerste dagen van goedkeuring van deze versie niet voor bangeriken was.

In de Nginx-implementatie ontbrak ook de server-push-functie, deze vertrouwde op een module. En Nginx-modules zijn niet de gebruikelijke Apache drop-in-modules die je gewoon kunt kopiëren – NGINX moet hiervoor opnieuw worden gecompileerd.

Hoewel sommige van deze problemen nu zijn opgelost, als we naar de volledige protocol-stack kijken, zien we dat de primaire beperking op een lager niveau ligt dan HTTP/2 aandurfde.

Om dit uit te leggen, zullen we de internetprotocol-stack van vandaag de dag ontleden vanuit de onderste laag naar de bovenste. Als je meer wilt weten over de achtergrond van HTTP/2, kan je onze ultieme HTTP/2-handleiding raadplegen.

Internet Protocol (IP)

Het internetprotocol (IP) definieert het onderste deel van de volledige internet-topologie. Het is het deel van de internet-stack dat, en dit kunnen we gerust zeggen, echt niet onderhandelbaar is zonder alles te moeten veranderen, inclusief het vervangen van de volledige hardware-infrastructuur, van routers tot servers en zelfs de machines van eindgebruikers.

Dus, hoewel de herziening van het protocol mogelijk is, is zo’n uitgebreide onderneming op dit moment niet aan de orde, vooral omdat we geen haalbaar, baanbrekend en toch achterwaarts compatibel alternatief hebben.

We kunnen de start van het IP-protocol terug herleiden naar 1974, er werd een paper gepubliceerd door het Institute of Electrical and Electronics Engineers geschreven door Vint Cerf en Bob Cahn. Het weergaf gedetailleerd pakketten weer die via een netwerk verzonden konden worden, deze werden doorgegeven via IP-adressen en numeriek gedefinieerde adressen van knooppunten in een netwerk/netwerken. Het protocol definieerde ook het formaat van deze pakketten of datagrammen – de headers en payload.

Na de RFC 760 definitie in 1980, stelde de IETF de definitie die tot op de dag van vandaag wordt gebruikt vast in de Request For Comments 791. Dit was de vierde versie van het protocol, maar we kunnen wel stellen dat dit de eerste productieversie is.

Het maakt gebruik van 32-bits adressen, waardoor het aantal adressen beperkt wordt tot ongeveer 4 miljard. Deze beperking is de verklaring voor het mysterie waarom niet-zakelijke internetgebruikers “dynamische IP-adressen” krijgen van hun ISPs. Een statische IP wordt beschouwd als een “toegevoegde waarde” en heeft vaak extra kosten.

Ze zijn op rantsoen.

Het duurde niet lang voordat men zich realiseerde dat 32-bits adressen niet genoeg waren en er een tekort aankwam. Hierdoor werden er veel RFC’s gepubliceerd die hiermee om probeerden te gaan. Hoewel deze oplossingen tegenwoordig veel worden gebruikt en deel uitmaken van ons dagelijks leven, is het veilig om te zeggen dat dit neerkomt op hacks.

Internetprotocol versie 6 of IPv6 ook bekend als IPv6 kwam als een manier om deze beperkingen aan te pakken, onder meer door geleidelijk te worden overgenomen ten opzichte van de vorige versie. Er werd in 1998 een Draft Standard-document door de IETF gemaakt en werd in 2017 verhoogd naar een internet-standaard.

Hoewel de IPv4-adresruimte werd beperkt door de 32-bits adreslengte, kreeg de IPv6-standaard 128 bits of 3,4 * 10 ^ 38 mogelijke adressen. Dit zou genoeg moeten zijn om ons geruime tijd van dienst te zijn.

Volgens Google en de IPv6 connectiviteit tussen haar gebruikers, is de adoptie van IPv6 iets meer dan 35% (gemeten juni 2021).

IP is een rudimentaire laag van de internet-stack, die de meest elementaire dingen definieert, zonder garanties van aflevering, gegevensintegriteit of de volgorde van verzonden pakketten. Op zichzelf staand is het onbetrouwbaar. Het header-formaat van IPv4 voorziet in een header-controlesom, die de knooppunten gebruiken om de integriteit van de header te verifiëren. Dit maakt het anders dan de IPv6-versie, die afhankelijk is van de onderliggende link-laag, waardoor deze sneller kan zijn.

Begrijpen van de rollen TCP en UDP

Nu is het tijd om te onderzoeken hoe HTTP/3 past binnen de TCP en UDP

TCP

Hoewel IP tegenwoordig de onderliggende laag is van al onze online communicatie, is TCP (Transmission Control Protocol) een onderdeel van het internetprotocol-pakket op een hoger niveau, dat betrouwbaarheid biedt die nodig is voor internet, e-mail, bestandsoverdracht (FTP) – voor toepassing lagen/protocollen van het internet.

Dit omvat het opzetten van verbindingen in meerdere stappen, met handshakes, een gegarandeerde volgorde van pakketten en her-versturing van verloren pakketten. Het geeft feedback (Acks) van aflevering aan de afzender en nog meer. Er is ook checksum-berekening om fouten op te sporen.

Al deze dingen duiden op veel stappen die TCP een betrouwbaar protocol maken, waardoor het een fundament is van de internetdiensten die wij tegenwoordig gebruiken.

De specificatie die teruggaat naar 1974 (RFC 675) en 1981 (RFC 793) is tot op de dag van vandaag niet aanzienlijk veranderd.

De betrouwbaarheid die TCP biedt, is echter niet kosteloos. De overheadkosten van alle roundtrips die vereist zijn voor handshakes, afleverings-feedback en controlesommen die als zwak en overbodig kunnen worden beschouwd. Dit heeft van TCP een knelpunt gemaakt in de moderne protocol-stack. HTTP/2 heeft een aantal snelheidsverbeteringen die bovenop TCP konden worden bereikt.

UDP

User Datagram Protocol (UDP) is ook een van de onderdelen van de Internet Protocol Suite, waarvan de specificaties teruggaan tot 1980 (RFC 768).

Het is, zoals de naam al doet vermoeden, een datagram-gebaseerd verbinding-loos protocol. Wat betekent dat er geen handshakes zijn en er geen garanties zijn voor de volgorde of aflevering. Dit betekent dat alle mogelijke stappen voor het garanderen van levering, gegevensintegriteit en andere dingen worden overgelaten aan de applicatielaag. Dit betekent dat een applicatie die bovenop UDP bouwt, strategieën kan kiezen die specifiek zijn voor het concrete geval, of het kan elementen van de verbindingslaag gebruiken, zoals checksums, om overhead te vermijden.

Omdat UDP wijdverbreid is, net als TCP, is het mogelijk om verbeteringen door te voeren zonder dat er firmware-updates nodig zijn op een breed scala aan apparaten die op internet zijn aangesloten, of dat er significante wijzigingen in de besturingssystemen nodig zijn.

De implementatie van nieuwe protocollen wordt belemmerd door veel firewalls, NAT’s, routers en andere middle-boxes die alleen TCP of UDP toestaan tussen gebruikers en de servers die zij moeten bereiken. – HTTP/3 uitgelegd

Deze thread op Hacker News kan ons helpen de redenering achter het bouwen van de nieuwe HTTP-versie boven op de bestaande netwerkstack te begrijpen, in plaats van het opnieuw uit te vinden (hoewel er meer is dan dat).

De specificatie van het UDP-pakketformaat is tamelijk minimaal, de header bestaat uit de bronpoort, de bestemmingspoort, lengte, in bytes, pakket-header- en gegevens en checksum. De checksum kan worden gebruikt om de gegevensintegriteit te controleren, zowel voor de header- als het gegevensgedeelte van het pakket.

De checksum is optioneel wanneer de onderliggende protocol-laag IPv4 is en verplicht wanneer dit IPv6. Tot nu toe is UDP gebruikt voor zaken als computersystemen kloksynchronisatie (NTP),VoIP-toepassingen, videostreaming, DNS-systemen en het DHCP-protocol.

QUIC en HTTP/3

QUIC (Quick UDP Internet Connections) werd voor het eerst ingezet door Google in 2012. Het herdefinieert de grenzen van netwerklagen, vertrouwt op een lager niveau UDP-protocol, herdefinieert handshakes, betrouwbaarheidskenmerken en beveiligingsfuncties in de ‘user-space’, waardoor het de noodzaak voor het upgraden van kernels van internet-brede systemen omzeilt.

Net als met HTTP/2, zal een vooruitgang die werd aangevoerd door Googles SPDY of Speedy, HTTP/3 opnieuw voortbouwen op deze prestaties.

Hoewel HTTP/2 ons multiplexing heeft gegeven en head-of-line-blokkering heeft beperkt, wordt het beperkt door TCP. Je kunt een enkele TCP-verbinding gebruiken voor meerdere streams gemultiplexed om gegevens over te dragen, maar wanneer een van die streams een pakketverlies lijdt, wordt de hele verbinding (en al zijn streams) als het ware gegijzeld totdat TCP zijn ding doet (het verloren pakket opnieuw verzenden).

Dit betekent dat alle pakketten, zelfs als deze al zijn verzonden en wachten, in de buffer van het bestemmingsknooppunt worden geblokkeerd totdat het verloren pakket opnieuw wordt verzonden. Daniel Stenberg noemt dit in zijn boek over HTTP/3 een “op TCP gebaseerde head of line block”. Hij beweert dat gebruikers met 2% packet loss beter af zijn met HTTP/1, met zes connecties om dit risico af te dekken.

QUIC heeft deze beperking niet. Omdat QUIC voortbouwt op het verbindingloze UDP-protocol, heeft het concept van verbinding niet de beperkingen van TCP en hoeven storingen in één stream de rest niet te beïnvloeden.

Zoals Lucas Pardue van Cloudflare het stelde:

Met de focus op UDP-streams, bereikt QUIC multiplexing zonder op één TCP-verbinding mee te liften. QUIC bouwt zijn verbinding op een hoger niveau dan TCP. Nieuwe streams binnen QUIC-verbindingen hoeven niet te wachten tot de anderen klaar zijn. QUIC-verbindingen profiteren ook van het afschaffen van handshake via TCP, wat de latency vermindert.

Mensen bij Cisco hebben een interessante video gemaakt over de 3-weg-handshake van TCP:

Hoewel QUIC de TCP-betrouwbaarheidskenmerken wegneemt, maakt dit het goed via de UDP-laag, waardoor pakketten opnieuw worden verzonden, volgordes worden gemaakt enzovoort. Google Cloud Platform introduceerde QUIC-ondersteuning voor hun load balancers in 2018 en zag een verbetering van de gemiddelde laadtijd van pagina’s met 8% wereldwijd en tot 13% in regio’s waar de latency hoger is.

Tussen Google Chrome, YouTube, Gmail, Google’s zoek- en andere diensten kon Google QUIC op een groot stuk internet implementeren, zonder op IETF te moeten wachten. De ingenieurs van Google beweren dat in 2017 7% van het internetverkeer al via QUIC werd uitgevoerd.

Google’s versie van QUIC was gericht op alleen HTTP-transport, met behulp van de HTTP/2-syntaxis. Mensen van IETF (die verantwoordelijk zijn voor het standaardiseren van QUIC), besloten dat de IETF-versie van QUIC meer dan alleen HTTP zou moeten kunnen transporteren. Voorlopig staat werk met niet-HTTP-protocollen via QUIC echter in de wachtstand.

IETF’s werkgroep besloot nog een keer dat de gestandaardiseerde versie TLS 1.3 versleuteling gaat gebruiken in plaats van de aangepaste oplossing van Google. TLS 1.3 draagt, vergeleken met de oudere versies, ook bij aan de protocol-snelheid, omdat de handshakes minder roudtrips vereisen. Kinsta ondersteunt TLS 1.3 op al onze servers en onze Kinsta CDN.

Op dit moment blijft Google zijn eigen versie van QUIC gebruiken in zijn product, terwijl hij zijn ontwikkelingsinspanningen richt op de IETF-normen. De meeste andere internetspelers bouwen bovenop de IETF-versie (de twee verschillen in een aantal andere aspecten naast versleuteling).

Als we Chrome Dev Tools openen en een aantal producten van Google, zoals Gmail, in de kolom Protocol van het tabblad Netwerk laden, zien we dat veel bronnen worden geladen via de Google-versie van het QUIC-protocol. Dit is ook het geval voor Google-producten zoals Analytics, Google Tag Manager, enz.

Cloudflare heeft onlangs een zeer uitgebreide update gepubliceerd over het proces van de standaardisatie.

Hoewel UDP QUIC en HTTP/3 weliswaar enkele voordelen biedt, brengt het ook enkele uitdagingen met zich mee.

TCP is al jaren het mainstream-protocol, terwijl UDP dat niet is, dus besturingssystemen en de softwarestack daarvoor zijn over het algemeen niet zo geoptimaliseerd. Als gevolg is er een veel hogere CPU-belasting/ -vereisten voor QUIC, volgens sommige schattingen, tweemaal zoveel als voor HTTP/2.

Optimalisaties gaan diep in op de kernel van besturingssystemen en verschillende routers en firmware van apparaten. Deze Red Hat tuning handleiding kan meer informatie bieden over het onderwerp voor diegenen die meer technisch onderlegd zijn.

We zouden kunnen zeggen dat QUIC probeert de TCP-functies opnieuw te ontwerpen bovenop een minimaler en flexibeler protocol.

QUIC-verbindingen, die we eerder noemden, combineren TLS en transport-handshakes. Nadat ze zijn vastgesteld, worden ze geïdentificeerd door unieke CID’s (verbindings-id’s). Deze ID’s blijven behouden bij IP-wijzigingen en kunnen helpen bij het veiligstellen van ononderbroken downloads tijdens, bijvoorbeeld, een overstap van 4G naar WiFi. Dit is relevant, vooral omdat steeds meer internetverkeer wordt uitgevoerd op mobiele apparaten. Er kunnen vragen ontstaan of dit element door Google is ontworpen om betere gebruikersregistratie over verschillende verbindingen en internetproviders mogelijk te maken.

TLS is verplicht, en bedoeld om het voor apparaten moeilijk te maken in het midden te knoeien met, of het verkeer af te luisteren. Daarom is het niet zeldzaam dat firewall providers en -leveranciers zoals Cisco het UDP-protocol als een probleem zien en manieren bieden om dit uit te schakelen. Het is voor tussenpersonen moeilijker om QUIC-verkeer te inspecteren, te controleren of te filteren.

QUIC-streams worden verzonden via QUIC-verbindingen, uni-directioneel of bi-directioneel. Streams hebben ID’s, die de initiator identificeren, controleren of de stream uni-directioneel of bi-directioneel is, en ook als in-stream flow-control fungeren.

Hoewel QUIC een transportlaag-protocol is, is HTTP de laag daarboven, een toepassingslaag-protocol of toepassingsprotocol.

Omdat achterwaartse compatibiliteit van het grootste belang is, zal de IETF de implementatie van HTTP/3 de oude versie (HTT1 of HTTP/2) in de respons opnemen. Het bevat een header die de client informeert dat HTTP/3 beschikbaar is, samen met poort-/host-informatie, zoals beschreven in RFC 7838.

Dit verschilt van HTTP/2, waarbinnen transport kan worden onderhandeld binnen de TLS-handshake. Maar omdat IETF bijna QUIC-gebaseerde HTTP/3 als de volgende standaard heeft overgenomen, kunnen we verwachten dat web-clients steeds vaker op HTTP/3-ondersteuning anticiperen. Het is mogelijk voor clients om gegevens van eerdere HTTP/3-verbindingen te cachen en direct verbinding te maken (zero-round-trip, of 0-RTT) bij latere bezoeken aan dezelfde host.

Samenvatting

Er zijn mensen die denken dat het, nu de HTTP/2standaard nog niet volledig is aangenomen, misschien te vroeg is om een wijdverbreide push voor HTTP/3 te maken. Dit is een geldig punt, maar zoals we al zeiden, heeft dit protocol al grootschalige tests en implementaties ondergaan. Google begon het al in 2015, te testen, evenals Facebook in 2017.

In 2023 zien we dat de grotere browsers als Google Chrome en Brave HTTP/3 ondersteunen. Wat infrastructuur betreft hebben webservers zoals Litespeed en Nginx beide werkende implementaties van HTTP/3, en ook netwerkproviders als Cloudflare hebben al volledige ondersteuning voor HTTP/3 geïmplementeerd.

Op dit moment bevindt HTTP/3 zich nog in de Internet Draft fase en de meest recente revisie ervan loopt af in augustus 2021. Dit jaar wordt spannend, omdat we kunnen verwachten dat grote softwareleveranciers deze nieuwe standaard gaan implementeren.

Tonino Jankov

Tonino is een ondernemer, Linux & OSS enthousiasteling, developer en tech-educator. Hij heeft meer dan tien jaar ervaring in development en is al meer dan 3 jaar actief in de blockchain-wereld. Als hij niet aan het coderen is, schrijft hij voor SitePoint en Alibaba Cloud, kijkt hij de nieuwste fictie op Netflix en verkent hij nieuwe reisbestemmingen.

• Twitter