NLJUG – Nederlandse Java User Group NLJUG – de Nederlandse Java User Group – is opgericht in 2003. De NLJUG verenigt software ontwikkelaars, architecten, ICT managers, studenten, new media developers en haar businesspartners met algemene interesse in alle aspecten van Java Technology.
Zoals de titel doet vermoeden gaat dit artikel over versie drie (referentie 1) van het ongeveer dertig jaar oude http-protocol. In dit artikel wil ik je graag op de hoogte brengen van het bestaan van dit protocol. Dat wil zeggen, de draft daarvan, omdat er op het moment van schrijven van dit artikel nog geen details over een officiële release bekend zijn.
Echter, het daadwerkelijk gebruiken van dit protocol is dichterbij dan je misschien vermoedt. Het kan namelijk zo zijn dat je het op de achtergrond toch al hebt gebruikt in bepaalde toepassingen. Hoe dat zit, en wat dit protocol voor jou kan betekenen in de toekomst als internetgebruiker en developer, lees je hieronder.
{ Van http/1.0 naar http/1.1 }
Het http-protocol is bijna niet weg te denken als communicatiemiddel van browsers om webpagina’s mee op te halen. Dergelijke webpagina’s zijn vaak samengesteld uit vele resources zoals html, javascript en css-bestanden. Deze kunnen uiteindelijk vele Mb’s aan dataverkeer verwezenlijken. Met de internetsnelheden en -bundels van tegenwoordig is dit meestal niet meer merkbaar, en niet direct een probleem. Maar onder de motorkap van een browser is dit niet altijd efficiënt qua geheugen- en throughput-optimalisatie, wat in bepaalde situaties niet wenselijk is.
Dit geldt zeker in het geval wanneer het originele http/1.0 protocol gebruikt wordt. Http definiëert de API die onder andere de GET en POST methoden bevat. Onderliggend wordt het tcp-protocol gebruikt om daadwerkelijk de data over de lijn te transporteren. Op basis van het aantal op te halen resources, dient ook hetzelfde aantal tcp-connecties geopend te worden. De evolutie van http/1.0 naar http/1.1 gooit daar al een efficiëntieslag overheen door middel van de “keep alive”-feature. Hierdoor wordt het aantal te initiëren connecties beperkt wanneer mogelijk. Daarmee waren we er echter nog niet, en dus is men doorgegaan met het nog efficiënter maken van het http-protocol.
{ Verbeteringen met http/2 }
In 2015 werd het http/2-protocol gereleased, gebaseerd op het experimentele SPDY-protocol van Google (referentie 2). Hoewel de API van het http-protocol niet wijzigde, veranderde er onder de motorkap van het protocol wel heel wat. Dit waren enkele minder significante aanpassingen, zoals efficiëntere headers. Het paradepaardje van http/2 was echter om resources efficiënter op te halen. Door gebruik te maken van multiplexing konden deze voortaan zoveel mogelijk gebundeld worden in één tcp-connectie. Hiermee kunnen deze kostbare connecties efficiënter gebruikt worden, omdat tweerichtingsverkeer van data over een connectie veel minder blokkeert. Hierdoor werden in beperkte mate de blocking-issues opgelost die inherent zijn aan het gebruik van tcp.
Zelfs voor de release van http/2 werd er al veel met het SPDY-protocol geëxperimenteerd, in bijvoorbeeld de Chrome-browser. Dit heb je als eindgebruiker waarschijnlijk niet direct gemerkt. Mocht je geïnteresseerd zijn in te zien wanneer Chrome een SPDY- of http/2-connectie gebruikt dan kun je hiervoor een plugin installeren die dit weergeeft (referentie 3). Plaatje 1 geeft op basis daarvan een indruk hoe detectie van een SPDY- of http/2-connectie er uitziet bij het openen van een webpagina.
{ Http, maar dan “QUIC” }
Zoals gezegd is men bezig met efficiëntieslagen voor het http-protocol, waarbij http/3 voortborduurt op http/2. Ook met de komst van http/3 is de API van het originele http-protocol niet gewijzigd. Wat je misschien in eerste instantie niet verwacht, is dat in http/3 het fundament van het http-protocol compleet vervangen is. In deze versie is namelijk het onderliggende tcp-protocol vervangen door een nieuw protocol dat beter geschikt lijkt te zijn.
De natuur van tcp waarmee in bepaalde gevallen nog steeds efficiëntieverlies kan optreden, wordt opgelost door toepassing van het QUIC-protocol (Quick UDP Internet Connections). Dit spreek je natuurlijk uit als “quick”, een aardige woordspeling. QUIC past op een slimme manier het gebruik van de multiplexed-connecties van http/2 toe, in combinatie met het onderliggende udp-protocol in plaats van tcp. Dit voorkomt head-of-line-blocking en is efficiënter qua resource-gebruik. Wil je hier alle technische details over weten, neem dan een kijkje op (referentie 4).
Hoewel de http/3-standaard in verschillende browsers al als preview is geïmplementeerd, heb ik op het moment van schrijven helaas nog geen concrete output of bewijs kunnen vinden van calls die hier daadwerkelijk mee uitgevoerd worden.
Wel kun je zien in plaatje 2 dat de eerder genoemde Chrome-plugin voor het detecteren van SPDY- en http/2-connecties aangeeft dat h3-29 wordt gebruikt. Dit is Googles werkversie van de implementatie van het QUIC-protocol. Opmerkelijk – en ingenieus – wordt QUIC dus momenteel al min of meer ‘on the fly’ gebruikt. Alleen dan in combinatie met http/2, als vervanging van het onderliggende tcp-protocol hiervan. Er is dan ook overwogen om dit concept als http-over-QUIC te definiëren. Deze term werd echter niet als een logische definitie voor de evolutie van het http-protocol gezien, daarom is uiteindelijk gekozen voor de term http/3.
{ Conclusie }
De definitie van http heeft zich intussen wel bewezen als een zeer goed idee, dat dertig jaar na dato nog steeds standhoudt. In de libraries die je gebruikt om te communiceren met andere services over http, zul je in bijna alle gevallen nog connecties opzetten die gebaseerd zijn op het http/1.1-protocol. Daar is helemaal niets mis mee, zeker niet als je simpelweg om een enkele resource vraagt van een andere service. Dit is veelvoorkomend gedrag in bijvoorbeeld een microservicesarchitectuur. Mocht je toch de behoefte aan een http/2-client in java hebben: deze is sinds java 11 beschikbaar in de JDK (referentie 5). Je hebt dus de keuze om de juiste versie van http te gebruiken voor het juiste doel. Tot nu toe lijkt het er op dat er alleen maar voordelen zitten aan de evolutie van http. Mocht iemand toch ooit een nadeel ontdekken, dan ben ik graag de eerste die het hoort.
Bio
Edwin Derks is Principal Software Architect en Codesmith bij Ordina en heeft een passie voor alles wat met java en cloud-driven development te maken heeft. Hij is ook contributor voor de Jakarta EE en MicroProfile-communities, naast spreker op conferenties en schrijver van artikelen.