Alles over het nieuwe internetprotocol HTTP/3
Geen enkele internetgebruiker kan buiten het http-protocol. Dat ligt immers aan de basis van de datacommunicatie binnen het wereldwijde web en ook op lokale netwerken zoals een intranet. Intussen is dit protocol aan versie 3 toe en de ondersteuning hiervoor neemt gestaag toe.
Http staat voor hypertext transfer protocol, een applicatieprotocol dat vanaf 1989 werd ontwikkeld onder aanvoering van Tim Berners-Lee, de ‘vader’ van het wereldwijde web. Het is een client-serverprotocol bedoeld om digitale bronnen op te halen
als html-documenten, maar ook afbeeldingen en video, door middel van afzonderlijke berichten in een request-response-structuur. Aanvankelijk was het bedoeld om over een al dan niet met tls-versleutelde tcp-connectie (Transmission Control Protocol) te worden verstuurd, maar ook andere transportprotocollen zijn mogelijk, zoals in http/3.
Om goed te begrijpen wat mogelijkheden van http/3 zijn, moet je eigenlijk weten hoe het http-protocol is geëvolueerd.
1991: Tim Berners-Lee stelde het initiële http-protocol voor (pas later http/0.9 genoemd). Het ging om een simpel protocol, waarbij de verbinding tussen server en client na elk request werd afgesloten. 1996: Http/1.0 was een broodnodige uitbreiding op het eerste ontwerp. waarbij het response object niet langer tot hypertext is beperkt, maar bijvoorbeeld ook een afbeelding kon zijn (hypermedia transfer protocol zou eigenlijk logischer zijn). 1999: Versie http/1.1 focuste zich vooral op het optimaliseren van de snelheid, met functies als keepalive-connecties en extra caching-mechanismen. 2015: Eindelijk werd opvolger http/2 geïntroduceerd. Dit protocol werd initieel gemodelleerd op Googles spdy en beoogde vooral kortere latentietijden, onder meer door efficiënte headercompressie, ondersteuning voor server push en request-prioritering, en request en response multiplexing. 2018: De IETF erkent de naam http/3. Dit protocol is gebaseerd op een eerder rfc-concept: http via quic. De belangrijkste verschuiving is het gebruik van het (snellere) udp in plaats van tcp. Quic implementeert tevens een eigen cryptolaag.
De eerste definitieve publicatie van het http/1.0-protocol dateert alweer van 1996. In deze versie werd voor elke request-response-uitwisseling tussen client en server een nieuwe tcp-connectie gemaakt. Deze werkwijze betekende echter flink wat latency (vertraging) aangezien elk verzoek door een tcp- (en tls-)handshake werd voorafgegaan. Meer zelfs, aangezien tcp absoluut opstoppingen wil vermijden, wordt er bij de initialisatie van zo’n connectie een ‘slow start’-mechanisme ingelast, wat voor verdere vertraging zorgt.
Http/1.1 trachtte dit latency-probleem enkele jaren later aan te pakken door middel van ‘keep-alive’-connecties. In deze revisie kon eenzelfde connectie namelijk verschillende keren worden hergebruikt om afbeeldingen, stijlbladen en scripts te downloaden nadat de webpagina was doorgestuurd. Dat was geen ideale oplossing, aangezien alle afzonderlijke verzoeken nog altijd na elkaar moesten worden uitgevoerd.
Eerst http/2
Het duurde nog meer dan tien jaar er beterschap kwam, met de komst van Googles spdy-experiment (lees als ‘speedy’) en naderhand met http/2. Die zorgden er namelijk voor dat verschillende requests parallel over een enkele tcp-verbinding kon worden verstuurd (multiplexing). Dat leverde vooral voordeel op wanneer een webpagina uit heel wat elementen was opgebouwd. Dit vind je bijvoorbeeld mooi geïllustreerd op https://http2.golang.org/gophertiles.
Een ander voordeel van http/2 is de ondersteuning van push responses. Hierbij kan een server proactief bepaalde pagina-elementen naar de client(cache) sturen, zodat de server hiervoor niet op expliciete requests hoeft te wachten. Volgens zeer recente cijfers van W3Techs zou circa 43 procent van de websites http/2 ondersteunen: een stijging van zo’n 30 procent in één jaar tijd.
Toch lost ook http/2 niet alle problemen op. Immers, ook wanneer er slechts bij één request dataverlies optreedt, bijvoorbeeld ten gevolge van netwerkopstopping, heeft dat een impact op alle request/responses binnen diezelfde tcp-connectie.
Quick Udp Internet Connections / Quic
Precies het feit dat tcp diverse mechanismen opzet voor een betrouwbare transmissie, maakt het in deze tijden van multimediaal internet niet het meest geschikte transportmiddel voor http. Daarom ook zet http/3 in op een nieuw internet transportprotocol, bedacht door Google: quic (Quick Udp Internet Connections).
Quic-datastreams maken gebruik van dezelfde verbinding zodat er geen extra handshakes of slow starts nodig zijn. Bovendien worden deze streams onafhankelijk van elkaar doorgestuurd, zodat dataverlies bij de ene stream doorgaans geen impact op de andere streams heeft.
©PXimport
De ‘magie’ achter deze techniek is eigenlijk simpel: quic-pakketten worden bovenop udp-datagrammen ingekapseld. Udp op zich mag dan een minder betrouwbaar protocol zijn dan tcp, het feit dat er nauwelijks controlemechanismen zitten ingebouwd maakt het protocol wel merkbaar sneller.
Komt daarbij dat de quic-implementaties, inclusief de (beperkte) opstopping-controle-algoritmen, zich in ‘user space’ bevinden. Dit maakt het makkelijker om het quic-protocol te updaten, zonder dat het onderliggende besturingssysteem betrokken wordt – wat wel het geval is bij tcp. Verder combineert quic de typische tcp-handshake met die van tls 1.3, waardoor authenticatie en encryptie standaard voorzien zijn en bovendien minder vertraging veroorzaken dan via tls/tcp.
Hearder-compressie
Je zou je natuurlijk de vraag kunnen stellen waarom men een nieuwe http-revisie nodig achtte en niet gewoon http/2 (dat al ondersteuning biedt voor multiplexing) bovenop quic inzette. Dat heeft vooral te maken met de header-compressie. Deze zorgt ervoor dat er minder bytes vereist zijn om headers te versturen, met allerlei relevante informatie voor client en server.
In http/2 wordt hiervoor het hpack-formaat gebruikt en de werking hiervan steunt grotendeels op een specifieke volgorde van http-requests en -responses. In tegenstelling tot hpack garandeert de header-compressie van quic (qpack genoemd) geen vaste volgorde tussen de verschillende streams. Qpack is dus niet zomaar compatibel met http/2, wat heeft geleid tot een nieuwe http-revisie. Daarbij komt dat sommige eigenschappen van http/2 (zoals flowcontrole per stream) al in quic zelf zitten ingebouwd, zodat ze uit de eigenlijke http/3-specificatie konden worden weggehaald.
Actuele status
De naam http/3 werd al in november 2018 door het IETF (Internet Engineering Task Force) goedgekeurd en is momenteel nog een rfc-draft, op weg dus naar een definitieve rfc-status. Volgens cijfers van W3Techs ondersteunt op het moment van schrijven circa 4,7 procent van alle websites dit nieuwe protocol. Dat lijkt weinig, maar de trend lijkt onomkeerbaar: op 1 januari van dit jaar bijvoorbeeld was dat nog geen 2,3 procent.
Heel wat grote sites ondersteunen het protocol inmiddels al, waaronder Google, YouTube en Facebook. geekflare.com/http3-test kun je terecht voor twee online tests waarmee je nagaat of een bepaalde site al ondersteuning biedt – probeer het bijvoorbeeld uit met facebook.com. Ontvang je graag een e-mailnotificatie wanneer nog andere bekende sites overstag gaan, dan kun je je hiervoor inschrijven via de site van W3Techs.
Ook op clientniveau zit er duidelijk beweging. Zo ondersteunen Google Chrome (sinds september 2019 in de Canary-build en sinds december 2019 in Chrome 79) evenals Firefox vanaf versie 72.0.1 het nieuwe http-protocol. In deze laatste moet je de functie weliswaar zelf nog even activeren. Dat doe je als volgt. Tik about:config in en zoek naar network.http.http3.enabled. Klik op de knop Omschakelen om de functie op True in te stellen.
