Het internet staat aan de vooravond van grotere veranderingen en dat allemaal dankzij de aanstaande omarming van het nieuwe HTTP2 protocol, of beter geschreven: HTTP/2.
De meeste gebruikers zal het weinig interesseren, zij typen alleen de URL in en een paar seconden later verschijnt veelal de verwachte pagina in browser. Hoe dit precies werkt en welk HTTP protocol er gebruikt wordt, kan niet op veel interesse rekenen. Maar voor performance en security testers brengt het nieuwe HTTP/2 protocol wel de nodige uitdagingen en problemen met zich mee.
Voordat ik uit de doeken doe waar deze uitdagingen en problemen zich bevinden, is het eerst verstandig eens te kijken naar de huidige situatie. Het huidige HTTP/1.1 protocol stamt uit 1997 en had o.a. als voordeel dat er caching mogelijkheden bij zijn gekomen en het hosten van meer domeinen op 1 IP-adres was nu mogelijk. De volledige lijst met extra mogelijkheden is een stuk langer en in dit geval niet relevant.
Wat wel opmerkelijk is, is dat het HTTP/1.1 protocol uit 1997 stamt en terugdenkend aan die tijd was de impact van het internet en de verwevenheid van het internet is ons dagelijks leven totaal anders. Het browsen van het World Wide Web ging totaal anders en de interactie tussen de gebruikers en websites was toen nog zeer beperkt. Daarom is het zo verbazingwekkend dat het vervolg van HTTP/1.1 zolang op zich laat wachten.
De organisatie die zich bezig houdt met het bepalen van de nieuwe standaard is de Hypertext Transfer Protocol working group (Httpbis) van het Internet Engineering Task Force (IETF). Deze organisatie opgericht in 1986 door 21 wetenschappers, valt sinds 1993 onder een niet-gouvernementele organisatie genaamd Internet Society (ISoc) die toezicht houdt op het IETF.
Kijkend naar het HTTP/2 protocol, wat dus bijna klaar is voor algemene acceptatie, dan waren vooraf o.a. de volgende doelen gesteld:
- Een hoge mate van comptabiliteit met het huidige HTTP/1.1 protocol
- Het verlagen van de latency (de tijd tussen het ontvangen antwoord op je verstuurde request richting de webserver)
- Een onderhandelmechanisme tussen de clients en servers over het gebruik van HTTP/1.1., HTTP/2 of andere protocollen
Aan veel van de doelen is ook een potentieel goede invulling gegeven en een aantal van deze doelen zal zeker ook de performance testers direct aanspreken.
HTTP/2 heeft het door Google ontwikkelde protocol SPDY als startpunt gebruikt. SPDY kan verschillende content tegelijkertijd van 1 host binnen 1 connectie ophalen, wat in de theorie al een performance verbetering is ten opzichte van HTTP/1.1. Er hoeft nu dus maar 1 connectie te worden opgezet in plaats van meerdere tegelijk. HTTP/2 heeft dit idee gepakt waardoor het laden van webpages sneller zou moeten verlopen. Ook de extra toegevoegde push mogelijkheden biedt de webserver kans om extra content in een respons te sturen waarvan de webserver verwacht dat de client mogelijk gebruik van zal maken.
Het beste voorbeeld wat ik voorbij heb horen komen is dat je de eerste pagina van een boek opvraagt, maar dat de webserver naast het de eerste pagina ook alvast de rest van het hoofdstuk opstuurt want daar verwacht hij dat je daarna om zal gaan vragen. Hierin zal dus voor de eindgebruiker een behoorlijke snelheidswinst te behalen zijn.
Deze zaken lijken op het eerste gezicht een verbetering, maar naar verdere bestudering zitten er toch wat haken en ogen aan die vooral voor security testers en in mindere maten performance testers voor wat gefundeerde zorgen kunnen opleveren.
Vanuit het performance oogpunt kan de introductie van HTTP/2 grote gevolgen hebben voor je loadtestscript, loadverdeling tijdens de uitvoer van een test, de werking van loadtesttooling en de analyse van de resultaten van een uitgevoerde loadtest. De volledige impact voor performance testen is helaas nog niet inzichtelijk voor mij, maar dat er potentieel grote veranderingen aankomen is vrij evident.
Vanuit security oogpunt is ook veel inhoudelijke kritiek op HTTP/2. Alleen al het uitgangspunt is voor veel wetenschappers en technici een doorn in het oog. Maar ook meer inhoudelijk is er veel kritiek op HTTP/2. HTTP/2 doet bijvoorbeeld niets aan de privacy van de gebruiker, cookies zijn bijvoorbeeld nog steeds aanwezig en er is niet voor gekozen om bijvoorbeeld gebruik te gaan maken van client controlled session identifier.
Daarnaast is er ook veel kritiek op het ontbreken van verplichte encryptie. Hoewel dit voor bijvoorbeeld mobile devices een probleem zou worden, zou verplichte encryptie wel een toegevoegde waarde kunnen wezen voor de veiligheid en privacy van gebruikers.
Ook bestaat er zorgen voor pushen van niet gevraagde content. Onduidelijk is welke potentiële risico’s dit met zich meebrengt voor de privacy van de gebruiker en welke malafide toepassingen er mogelijk worden al dan niet in samenwerking met lekken in de browser.
Tevens levert het versturen van extra content waar de gebruiker niet omgevraagd heeft en mogelijk ook niet gebruikt ook nog eens tot onnodig extra belasting.
Mijns inziens zijn er nog wat hobbels te nemen voordat HTTP/2 de standaard gaat worden, maar gelukkig is de internet gemeenschap nog steeds waakzaam als het aankomt op privacy en veiligheid. Daarnaast zijn grootste browsers er nog niet volledig klaar voor en ook de bekendste software leverancier van webservers, Apache, heeft nog geen concrete plannen voor het native implementeren van HTTP/2.