Wat is HTTP/3 en hoe verhoudt het protocol zich tot zijn voorgangers?

Timo, 6 oktober 2020

Hypertext Transfer Protocol 3 (HTTP/3) is een opkomende 3de versie van HTTP die op dit moment door IETF (Internet Engineering Task Force) doorontwikkeld wordt om als nieuwe standaard te dienen. Terwijl HTTP/2 nog niet overal ondersteund wordt, is er dus al een 3de versie in omloop die een aantal fundamentele problemen bij zijn voorganger moet wegnemen.

Hoewel IETF nog niet klaar is met de standaardisering van het protocol, is de kans groot dat je HTTP/3 al gebruikt wanneer je op het web surft. Grote sites als Google en Facebook ondersteunen het protocol namelijk al. Sterker nog, Google is de grondlegger van het protocol dat nu doorontwikkeld wordt.

HTTP-over-QUIC: In 2012 is Google van start gegaan met een intern project dat ‘HTTP over QUIC’ heette. Met dit project wilde ze de snelheid van hun eigen Chrome-browser en de snelheid van hun eigen zoekmachine verbeteren. Later hebben ze het project overgedragen aan IETF zodat het protocol verder ontwikkeld wordt voor standaardisering. 

Samenstelling HTTP

Om uit te leggen wat er zo fundamenteel anders is aan HTTP/3 kijken we eerst naar de samenstelling van het internetprotocolframework waar eerdere versies van HTTP gebruik van maken.

HTTP(S)-verzoek over TCP

Applicatielaag

Wanneer je een webpagina bezoekt maakt jouw webbrowser (b.v. Safari, Google Chrome) contact met de server waarop een website staat. Het verzoek dat je webbrowser stuurt, zal afgehandeld worden door een webserver. Zowel jouw webbrowser als de webserver noemen we webapplicaties. De (computer)taal waarmee beide applicaties communiceren heet HTTP en de communicatie tussen beide vind plaats op de applicatielaag.

Beveiligingslaag

Deze laag ligt boven op de transportlaag (zie beschrijving hieronder) om ervoor te zorgen dat data veilig en versleuteld heen een weer gaat. SSL-certificaten maken het mogelijk om deze extra beveiligingslaag aan te brengen. Na installatie kan iemand een website via HTTPS (dat staat voor HTTP-Secure) bezoeken.

Transportlaag

Wanneer een browser en webserver met elkaar communiceren, wisselen ze kleine datapakketjes uit. In die pakketjes staan instructies en de data die uiteindelijk opgebouwd wordt tot de websitepagina die je opvraagt. Dit dataverkeer vind plaats op de transportlaag. Het transportprotocol dat doorgaans bij HTTP/1 en HTTP/2 wordt gebruikt heet ‘Transmission Control Protocol’ (TCP).

Internetlaag

Op de internetlaag is het ‘internetprotocol’ van toepassingen. Doormiddel van IP-adressen kan achterhaalt worden waar bepaalde apparaten en servers gevonden worden. Op deze laag bepaalt jouw webbrowser dus met welke webserver hij contact maakt voor het ophalen van de opgevraagde webpagina.

Netwerklaag

Denk hierbij aan de WiFi- of LAN-verbinding die nodig is om data uit te wisselen.

Wil je weten hoe snel jouw website is?

Vraag gratis onze snelheidcheck aan! Binnen één werkdag krijg je een uitgebreid snelheidsrapport van ons terug.

De voordelen van HTTP/2

Als opvolger van het eerste HTTP-protocol heeft HTTP/2 een aantal significante verbetering gebracht. Denk aan het comprimeren van HTTP-headers, Het implementeren van ‘server push’ en het introduceren van multiplexing. Voor een uitgebreide uitleg over de voordelen van HTTP/2 lees je dit artikel.

HTTP-headers comprimeren

door headers te comprimeren worden verzoeken tot wel de helft in bestandsgrootte teruggebracht. Hoe minder data er in een verzoek verpakt zit, hoe sneller hij afgehandeld en verstuurd wordt.

Server Push

bij serverpush stuurt de webserver al verzoeken naar de webbrowser waarvan hij verwacht dat ze opgevraagd worden. Hij hoeft daarmee dus niet eerst te wachten op verzoeken die (hoogstwaarschijnlijk) gaan binnenkomen.

Multiplexing

Deze techniek zorgt ervoor dat het rangschikkingsprobleem van pipelining (geïntroduceerd in HTTP/1.1) is opgelost. Pipelining maakt het mogelijk om meerdere verzoeken over één TCP-verbinding te sturen. Bij het initiële HTTP/1 protocol moest namelijk voor ieder verzoek een nieuwe TCP-verbinding opgezet worden.

Het nadeel van pipelining is dat alle verzoeken op volgorde van aanvraag worden afgehandeld (zie afbeelding hieronder). Alle verzoeken gaan over één TCP-verbinding en moeten  stapsgewijs worden afgehandeld. Een groot Javascript-bestand dat lang laadt, zal hierdoor de rest ophouden. Multiplexing maakt het mogelijk om de verzoeken gelijktijdig en zonder vaste volgorde af te handelen. Daarmee is deze techniek stukken sneller.

Multiplexing pipelining HTTP

De nadelen van HTTP/2 over een TCP-verbinding

Hoewel HTTP/2 significante (snelheids)voordelen met zich meebrengt, zijn er een aantal factoren die het protocol beperken. Deze beperkingen zijn vooral toe te schrijven aan de manier waarop TCP werkt.

Teveel overhead

Wanneer een webbrowser en webserver met elkaar communiceren over TCP vind er ongelofelijk veel data-uitwisseling plaats. Er is veel zogenaamde ‘overhead’. Hiermee worden de verzoeken en antwoorden bedoelt die beide applicaties met elkaar uitwisselen om met elkaar te ‘praten’. Dit begint al bij het opzetten van de TCP-verbinding waarbij beide applicaties ‘kennis’ met elkaar maken.

TCP is vooral ingericht op de zekerheid dat alle datapakketten bij de ontvanger aankomen. Iedere keer dat een pakket verstuurd wordt, is het noodzakelijk dat de ontvanger in een antwoord terug laat weten dat de data is aangekomen. Is een data-pakket tijdens de overdracht verloren gegaan, dan blijft het antwoord vanuit de ontvanger uit. De verzender rekent echter wel op dit antwoord en stuurt daarom bij het uitblijven hiervan het datapakket opnieuw op.

Al deze communicatie neemt bandbreedte in beslag. Dat wil zeggen dat het een deel van de snelheid opeist waarmee anders paginabestanden (waaruit een webpagina is opgebouwd) over een weer gaan.

Head-of-line blocking TCP

Hoewel multiplexing verschillende verzoeken bundelt en op één TCP-verbinding afhandelt, kleeft er een groot nadeel aan het gebruik van TCP. Iedere bundel van verzoeken kan namelijk pas afgesloten worden nadat alle verzoeken verwerkt zijn. Wanneer er bij de dataoverdracht een pakketje verloren gaat, blijven de verzoeken die al afgehandeld zijn in een buffer hangen totdat het laatste verzoek ook klaar is. Bij hoge latency of bij een verzoek dat herhaaldelijk blijft falen, kan het enorm lang duren voordat een pagina laadt.

Head of line blocking HTTP

Hoe werkt HTTP/3?

Er zijn een aantal fundamentele verschillen in hoe het framework onder HTTP/3 is opgebouwd. Zo maakt het op de transportlaag geen gebruik van TCP, maar van UDP en QUIC.

Quic protocol HTTP/3

UDP is een veel simpeler transportprotocol. Het kan ‘verbindingloos’ (zonder sessie) data sturen naar de ontvanger. Het maakt daarbij geen gebruik van bevestigingscommunicatie. Simpel gezegd: het protocol houdt er geen rekening mee of data daadwerkelijk aankomt bij de ontvanger. Daarmee verdwijnt het ‘Head-of-line blocking’ probleem van TCP. Er wordt namelijk geen verbinding opgezet die afgehandeld dient te worden. Doordat er significant minder overheadcommunicatie is, gaat data sturen ook stukken sneller.

QUIC als controleur en beveiliger

Simpelweg data over UDP sturen bij het uitserveren van webpagina’s is niet verstandig. Als onderweg essentiële datapakketten verloren gaan, kan een pagina onvolledig (of helemaal niet) laden. Daarom neemt QUIC de functionaliteit van TCP over om controle uit te oefenen op het dataverkeer. Blijkt er een datapakket te ontbreken? Dan vraagt QUIC met een apart verzoek het opnieuw aan. Hierdoor kunnen andere verzoeken zonder oponthoud afgehandeld worden omdat UDP zich niets aantrekt van sessies die voltooid moeten worden.

HTTP/3 is daarnaast ook zo slim ingericht dat essentiële paginabestanden over UDP vaak tegelijkertijd twee keer verstuurd worden. Gaat er één pakketje verloren, dan is de kans nog steeds groot dat de twee wel aankomt. Oponthoud door dataverlies wordt daarmee een stuk kleiner.

QUIC versleutelt standaard alle data die verzonden wordt. Het roept hierbij de functionaliteiten van TLS 1.3 aan die binnen de applicatie zijn opgenomen. Het uitwisselverzoek van encryptiesleutels (d.mv. de SSL-handshake) wordt tegelijktijdig met het opvraagverzoek van de webpagina verstuurt. Omdat UDP sessieloos werkt, kunnen al deze verzoeken tegelijktijdig de deur uit. Enorm tijdbesparend, want bij HTTP/2 moet eerst de SSL-handshake afgerond zijn voordat een beveiligde TLS-verbinding ontstaat. Daarna kan pas data uitgewisseld worden. QUIC zorgt ervoor dat na de eerste kennismaking ‘round-trip’ websitedata direct uitgewisseld wordt.

Handshakes

Wil je weten hoe snel jouw website is?

Vraag gratis onze snelheidcheck aan! Binnen één werkdag krijg je een uitgebreid snelheidsrapport van ons terug.

Conclusie

HTTP/2 heeft ten opzichte van zijn voorganger veel verbeteringen met zich meegebracht. Toch blijft het protocol beperkt in zijn kunnen door de problemen die TCP met zich meebrengt. HTTP/3 omzeilt dit slim door gebruik te maken van UDP en QUIC. UDP zorgt voor razendsnel verbindingloos dataverkeer. QUIC zorgt op zijn manier ervoor dat de voordelen van TCP en TLS niet verloren gaan.

De verwachting is dat het nog minimaal een jaar duurt voordat IETF HTTP/3 als nieuwe standaard introduceert. Bij Savvii volgen we deze ontwikkelingen op de voet. Onze filosofie is dat we alleen ‘mainline stable packages’ installeren op onze serverstack. Een losse HTTP/3 patch installeren, die nog vol bugs zit, past niet bij de kwaliteit de we leveren. We staan voor betrouwbaarheid en daarbij hoort een stabiele hostingstack. Zodra IETF HTTP/3 als nieuwe standaard introduceert, start bij ons de implementatie.

Reageer