HTTP/3, gebaseerd op UDP, is de nieuwste versie van het HTTP-protocol. De IETF (Internet Engineering Task Force) is in november 2018 in Bangkok bijeengekomen om dit nieuwe internetconcept goed te keuren. Op het moment van schrijven (mei 2021) had het HTTP/3-protocol nog steeds de Draft-status, maar bedrijven zoals Google, Microsoft en Facebook gebruiken het nieuwe protocol al een tijdje om het webverkeer te versnellen. Volgens W3Techs-gegevens over het gebruik van HTTP/3 bieden momenteel al circa 19% van alle websites ondersteuning voor HTTP/3.
Wat is HTTP/3?
Het HTTP/3-protocol is de nieuwste versie van het HyperText Transfer Protocol (HTTP). Deze versie is gebaseerd op het UDP-protocol. HTTP/3 was eerder bekend onder de naam HTTP-over-QUIC. Het QUIC-netwerkprotocol is oorspronkelijk door Google ontwikkeld en zal in de plaats komen van HTTP/2. De ontwikkeling van HTTP/3 is al jaren geleden gestart, met als doel de laadsnelheid op het internet te versnellen door middel van belangrijke veranderingen in de manier waarop gegevens worden overgedragen.
HTTP/3 maakt gebruik van de functies van het UDP-protocol en bevat definities voor veel functies die in eerdere HTTP-versies nog in de TCP-laag werden geïmplementeerd. Hierdoor kunnen bepaalde beperkingen uit de infrastructuur van het internet worden opgeheven. Terwijl HTTP/1.1 en HTTP/2 in de transportlaag werkten met TCP, maakt HTTP/3 gebruik van QUIC om een van de grootste problemen van HTTP/2 op te lossen: het lineaire verloop van de downloads.
Hoewel HTTP/2 dankzij multiplexing een gedeeltelijke oplossing biedt voor het ‘head-of-line’ blokkeringsprobleem, blijft TCP een beperkende factor. Het is in HTTP/2 weliswaar mogelijk een unieke TCP-verbinding te gebruiken voor meerdere transmissies, maar zodra één van de transmissies pakketverlies lijdt, wordt de hele verbinding geblokkeerd om te wachten tot het verloren pakket opnieuw is verzonden door TCP. HTTP/3 heeft geen last meer van dit blokkeringsprobleem, doordat het is geïntegreerd met het verbindingsloze UDP-protocol.
Dankzij de native ondersteuning voor multiplexing zorgt QUIC ervoor dat verloren pakketten alléén nog de transmissies beïnvloeden waarin data verloren zijn gegaan. Nieuwe streams binnen een QUIC-verbinding hoeven dus niet meer te wachten tot alle andere klaar zijn. Bovendien wordt de overhead als gevolg van de TCP-handshake geëlimineerd, waardoor de latentie afneemt. Op het gebied van betrouwbaarheid mist QUIC enkele functies van het TCP-protocol, maar dit wordt bóven de UDP-laag gecompenseerd door middel van ondersteuning voor verschillende functies, zoals het sorteren en opnieuw zenden van pakketten.
Transportlaag: TCP en UDP
TCP: Transport Control Protocol
TCP is een acroniem voor Transport Control Protocol. Dit protocol bevindt zich bovenop de IP-laag (Internet Protocol). TCP is de basis voor heel veel internetprotocollen en -services en vervult onder andere deze taken:
- De betrouwbaarheid waarborgen voor webverkeer, bestandsoverdracht en andere vormen van dataverkeer.
- Getrapte verbindingen tot stand brengen en daarbij de juiste volgorde van de pakketten garanderen en verloren pakketten zo nodig opnieuw verzenden.
- Een checksum-berekening uitvoeren om fouten te detecteren.
Maar het TCP-protocol brengt ook een belangrijke beperking met zich mee: de overhead van alle heen en weer gestuurde pakketjes die nodig zijn om correcte aflevering van alle informatie te garanderen. Daardoor is TCP een flessenhals geworden die hogere internetsnelheden in de weg staat. Dit is ondanks de verbeteringen die in HTTP/2 zijn aangebracht, zoals we verderop zullen uitleggen.
De specificatie van het TCP-protocol stamt nog uit 1974 en 1981 (respectievelijk RFC 675 en RFC 793). Sindsdien heeft het protocol geen ingrijpende veranderingen ondergaan, omdat het diep is verankerd in besturingssystemen, firmware en andere systeemonderdelen, waardoor wijzigingen heel moeilijk zijn door te voeren.
UDP: User Datagram Protocol
UDP is een acroniem voor User Datagram Protocol. UDP is een verbindingsloos protocol op basis van zogeheten datagrammen, zonder garanties voor correcte aflevering. De aflevering van de informatie, de integriteit van de gegevens en andere functies worden gedelegeerd naar de applicatielaag. Het UDP-protocol wordt vooral gebruikt voor toepassingen zoals VoIP, DNS, DHCP en BOOTP. De specificaties van UDP-pakketten zijn heel summier. De header van een UDP-pakket bestaat uit:
- Bron- en bestemmingspoort
- Lengte (in bytes) van de pakketheader en de pakketgegevens
- Checksum voor verificatie van de gegevensintegriteit (optioneel voor IPv4 en verplicht voor IPv6).
De specificatie van het UDP-protocol dateert uit 1980 (RFC 768) en ook dit protocol wordt nog altijd veel gebruikt. Elke substantiële verbetering zou daarom ook belangrijke veranderingen noodzakelijk maken in de besturingssystemen en de firmware van alle met het internet verbonden apparaten.
QUIC-netwerkprotocol
QUIC is een acroniem voor Quick UDP Internet Connections. QUIC is in 2012 bij Google ontworpen door Jim Roskind. Het is een netwerkprotocol bovenop de UDP-transportlaag. De QUIC-versie van Google was alleen gericht op HTTP-transport en maakte gebruik van de syntaxis van HTTP/2. De IETF gaat echter een stap verder voor de standaardisering van QUIC.
Met QUIC worden de grenzen van netwerklagen, communicaties en betrouwbaarheids- en beveiligingskenmerken in de ‘gebruikersruimte’ opnieuw gedefinieerd. Op deze manier wordt vermeden dat de kernels van internetbrede systemen moeten worden aangepast. Maar het gebruik van UDP heeft zowel voor- als nadelen voor QUIC en HTTP/3. Een van de uitdagingen is de CPU-belasting bij gebruik van QUIC, die volgens sommige ramingen dubbel zo hoog kan worden als bij HTTP/2. Dit is te wijten aan het feit dat besturingssystemen en software niet zijn geoptimaliseerd voor het gebruik van UDP (omdat lange tijd TCP het belangrijkste protocol is geweest).
Bovendien is het gebruik van TLS verplicht voor QUIC-verbindingen om te voorkomen dat tussenliggende apparaten het dataverkeer kunnen detecteren of manipuleren. QUIC-streams bevatten een ID die aangeeft wie de transmissie heeft gestart. Deze datastreams worden verzonden over uni- of bidirectionele QUIC-verbindingen.
De implementatie van HTTP/3 die door de IETF wordt gepromoot, omvat ook de eerdere versies om achterwaartse compatibiliteit te waarborgen. Zoals in RFC 7838 is gedefinieerd, bevat de header niet alleen poortgegevens, maar ook informatie voor de client over de beschikbaarheid van HTTP/3.
Implementatie van HTTP/3
In mei 2021 boden de browsers Google Chrome, Firefox, Safari en Microsoft Edge al ondersteuning voor HTTP/3, althans in experimentele vorm, in afwachting van formele standaardisering. Hetzelfde geldt voor servers zoals Litespeed Web Server, HAProxy 2.3 en Caddy Webserver.
Bovendien zijn er enkele open source bibliotheken met implementaties van HTTP-over-QUIC, zoals: neqo van Mozilla, Cronet van Google, proxygen van Facebook, lsquic van LiteSpeed, aioquic, quic-go of nghttp3. Op GitHub staat een complete lijst van de beschikbare bibliotheken, ontwikkeld met verschillende programmeertalen (C, C++, Rust, Python…).
HTTP-versies
De eerste versie van HTTP werd in 1991 uitgebracht als HTTP/0.9. HTTP/1.0 en HTTP/1.1 volgden respectievelijk in 1996 en in 1999. Parallel aan de ontwikkeling van het internet en het web is het protocol voortdurend verder verbeterd om de gegevensoverdracht over het netwerk te optimaliseren. Maar tot de release van HTTP/2 in 2015 waren er nog geen ingrijpende veranderingen geweest. Met deze versie werd de gegevensoverdracht verbeterd, waardoor de laadsnelheid van webpagina’s aanzienlijk toenam. En nu is HTTP/3 de volgende versie, waarvan wordt verwacht dat deze de internetsnelheid nog verder zal verbeteren.
Verbeteringen in HTTP/2
Het HTTP/2-protocol had al een aantal waardevolle verbeteringen toegevoegd, zoals:
- Oplossing van enkele beperkingen van het TCP-protocol door verbeteringen zoals niet-blokkerende downloads, pipelines en server pushing.
- Minder verzoek/respons-cycli, waardoor de laadsnelheid toenam.
- Multiplexing: meerdere resources kunnen worden verzonden via één unieke TCP-verbinding.
- Meer flexibiliteit bij het downloaden van statische resources en eliminatie van het lineaire verloop van downloads. Hierdoor hoeft een grote JavaScript-resource niet langer nadelige gevolgen te hebben voor het laden van andere statische resources.
Aan dit lijstje moeten we ook nog de HPACK-compressie van de HTTP/2-header en het standaard binaire formaat voor gegevensoverdracht toevoegen. Hierdoor werd de efficiëntie van het protocol sterk verbeterd.
Om optimaal te profiteren van HTTP/2, hebben de belangrijkste browsers bovendien het gebruik van SSL verplicht gesteld. Daardoor werden de snelheidsverbeteringen in sommige gevallen minder belangrijk.
Samengevat: de doorontwikkeling van essentiële protocollen zoals HTTP is onmisbaar in de snel veranderende context van het internet en het web. Voor de invoering van de nieuwe versie van dit protocol zijn er verschillende benaderingen. Sommigen denken dat het misschien nog te vroeg is om een nieuwe versie te introduceren, omdat de HTTP/2-standaard nog altijd niet volledig is goedgekeurd.
Maar het succes van de tot nu toe uitgevoerde HTTP/3-tests is bemoedigend, omdat het nieuwe protocol voor alle gebruikers grote voordelen met zich meebrengt. Zoals gezegd ondersteunen de belangrijkste browsers nu al HTTP/3 en bedrijven zoals Google, Mozilla, Facebook en Akamai werken al jaren met het nieuwe protocol.