HTTP/2: Wat is het, en wat kunnen we ervan verwachten?

Het Hypertext Transfer Protocol (HTTP) is cruciaal voor de werking van het wereldwijde web zoals we dat kennen. Zo bepaalt het bijvoorbeeld hoe een webbrowser (de cliënt) kan communiceren met een (web)server, zodat zij elkaar begrijpen en bepaalde content, zoals de inhoud van deze pagina, kunnen uitwisselen.

In eerste instantie ging dat, zoals de naam suggereert, exclusief om hypertext: gestructureerde tekst die door middel van de welbekende hyperlinks naar andere teksten kan verwijzen. Tegenwoordig maken miljarden apparaten (en mensen) gebruik van het protocol om niet alleen tekst maar ook afbeeldingen, audio, video en allerlei andere gegevens uit te wisselen.

We maken daarbij doorgaans gebruik van HTTP/1.1, de versie die sinds 1999 de standaard is. Ons huidige protocol stamt dus uit een tijd waarin mobiele telefoons nog monochrome schermen en zichtbare antennes hadden, Netscape een populaire webbrowser was, en de euro als munteenheid formeel geïntroduceerd werd.

HTTP/1.1: dienstbaar, maar verouderd

Ondanks alle ontwikkelingen die het wereldwijde web dit millennium heeft doorgemaakt, is HTTP vijftien jaar onveranderd gebleven. Dat brengt de nodige problemen met zich mee.

Waar webpagina's in 1999 nog veelal tekst en afbeeldingen bevatten van hooguit enkele tientallen kilobytes, bestaat een gemiddelde webpagina (volgens HTTP Archive) tegenwoordig uit bijna honderd elementen, en is een totale grootte van meer dan anderhalf megabyte niet ongewoon.

Elke verbinding tussen de cliënt en de server kan slechts één element tegelijk overbrengen, oftewel één afzonderlijke HTTP-transactie. Zelfs in moderne browsers, die per domeinnaam van gemiddeld 6-8 parallelle verbindingen gebruik kunnen maken, betekent dit dat een pagina die honderd elementen bevat, opgedeeld moet worden in 12-16 'sessies' waarin elk 6-8 elementen tegelijkertijd kunnen worden gedownload.

Zo ontstaat er een lange wachtrij: de browser kan immers pas beginnen met het downloaden van een nieuw element zodra er een verbinding vrij komt. Vóór HTTP/1.1 was het bovendien niet mogelijk om een verbinding te hergebruiken, en moesten de cliënt en server na elk afgehandeld verzoek de onderhandelingen weer opnieuw opstarten alvorens een volgend element uitgewisseld kon worden.

TCP, handshakes en de beperkingen van HTTP/1.1

Die onderhandelingen vinden plaats met behulp van het Transmission Control Protocol (TCP), een belangrijk protocol dat het transport van gegevens tussen twee computers in een netwerk (zoals het internet) mogelijk maakt, en er tevens voor zorgt dat daarbij geen gegevens verloren gaan.

Het aanmaken van een TCP-verbinding, waar een HTTP-verzoek gebruik van maakt, is relatief tijdrovend. Om er zeker van te zijn dat de communicatie tussen beide computers goed kan verlopen, vindt er namelijk eerst een zogeheten handshake plaats.

In deze handshake klopt de cliënt aan bij de server met een verzoek tot synchronisatie (SYN). De server reageert door eenzelfde verzoek (SYN) naar de cliënt te sturen, en laat tevens weten dat een verbinding mogelijk is (ACK, van acknowledge). De cliënt bevestigt op haar beurt het synchronisatieverzoek van de server, en de TCP-verbinding is een feit.

Dit lijkt wellicht geen tijdrovend proces, maar voor elk onderdeel van de handshake moet een pakketje gegevens van de ene naar de andere computer verstuurd worden. Hoe groter de afstand tussen beide computers, hoe langer dit duurt, een gegeven dat grotendeels beperkt wordt door de snelheid van het licht. Versies 0.9 en 1.0 van HTTP waren bovendien niet in staat om TCP-verbindingen in stand te houden (keepalive geheten), en moesten voor elk HTTP-verzoek een geheel nieuwe TCP-verbinding opzetten, om deze daarna gelijk weer af te breken.

HTTP/1.1 ondersteunt wel keepalives, waardoor TCP-verbindingen hergebruikt kunnen worden voor het verwerken van meerdere HTTP-verzoeken. Het aantal tijdrovende handshakes wordt zo tot een minimum beperkt. Het is tegenwoordig dan ook vooral het feit dat er per verbinding slechts één HTTP-verzoek tegelijk kan worden verwerkt, wat een knelpunt veroorzaakt.

Met deze beperking van HTTP wordt op allerlei creatieve wijzen omgegaan. Het aantal HTTP-verzoeken en benodigde TCP-verbindingen kan bijvoorbeeld beperkt worden door elementen samen te voegen (zoals afbeeldingen in CSS sprites), of door ze vanaf andere (sub)domeinen te laden (domain sharding) waardoor de beperking van de maximaal zes tot acht verbindingen per domeinnaam omzeild wordt.

De komst van SPDY

Elk van de genoemde (en andere) manieren om met de beperkingen van HTTP/1.1 om te gaan, moet als noodoplossing worden beschouwd. Het knelpunt zit immers ingebed in het protocol. Om die reden is een ontwikkelteam van met name Google enkele jaren geleden begonnen met het definiëren van enkele aanpassingen aan HTTP, die de huidige nadelen zoveel mogelijk moeten opheffen.

Dit project heeft de naam SPDY gekregen, veelal uitgesproken als speedy. Het doel ervan was niet om HTTP te vervangen, maar om de manier aan te passen waarop HTTP-gegevens geëncodeerd en verzonden worden, en zodoende het internet sneller te maken. Aan het protocol, ofwel de manier van communiceren, verandert in feite dan ook niets. SPDY is een geoptimaliseerd kader voor HTTP, met drie belangrijke basiseigenschappen:

• Multiplexing

  Het gegeven dat een TCP-verbinding slechts één HTTP-verzoek tegelijk kan verwerken, wordt door SPDY opgeheven met behulp van een techniek die multiplexing heet. Een onbeperkt aantal gegevensstromen kan tegelijkertijd, en dus door elkaar heen in plaats van één voor één, verzonden en verwerkt worden, waardoor minder netwerkverbindingen benodigd zijn en eventuele overhead tot een minimum wordt beperkt.

• Prioritisering van verzoeken

  Multiplexing maakt het mogelijk om een groot aantal pagina-elementen, zoals tekst, afbeeldingen en stylesheets, tegelijkertijd en door elkaar in plaats van serieel te verzenden. Met SPDY kan de cliënt (bijvoorbeeld een webbrowser) bovendien aangeven welke van deze elementen een hogere prioriteit moeten krijgen dan anderen, en dus vroeger in de pijplijn verzonden dienen te worden.

  Zo wordt voorkomen dat iemand met een langzame of instabiele internetverbinding, zoals bij mobiel internet nog vaak het geval is, lang moet wachten alvorens de meest cruciale elementen van een webpagina, zoals tekst en stylesheets, geladen zijn. De prioriteit zal meestal deze vorm krijgen: HTML > JS, CSS > *.

• Compressie van HTTP-headers

  Om de verstuurde TCP-gegevenspakketten zo klein en efficiënt mogelijk te maken, past SPDY compressie toe op de zogeheten headers van een HTTP-transactie. In deze headers staan gegevens zoals de datum, het content-type, een status-code en andere operationele parameters. Door deze te comprimeren, kunnen in elk TCP-pakket meer gegevens verpakt worden. Dit is echter controversieel gebleken.

  Deze feature, zo bleek in 2012, zou het namelijk eenvoudiger te maken om een zogenoemde CRIME-aanval — kort voor Compression Ratio Info-leak Made Easy — uit te voeren, waarbij beveiligde internetsessies overgenomen kunnen worden. Webbrowsers die SPDY reeds ondersteunden hebben na deze ontdekking vrij snel updates uitgebracht die de gevolgen ervan grotendeels beperkt hebben. Vanuit SPDY is de originele compressiemethode zlib vervangen door HPACK, die resistent tegen CRIME zou zijn.

Encryptie is de standaard in SPDY (en HTTP/2)



SPDY werkt exclusief met HTTP Secure (HTTPS), de uitbreiding op HTTP die encryptie bij de uitwisseling van gegevens mogelijk maakt. HTTPS is in de regel trager dan HTTP omdat er een extra handshake vereist is voor het uitwisselen van certificaatgegevens, maar de ontwikkelaars van SPDY hebben hier toch toe besloten omdat ze vinden dat "de toekomst van het web afhangt van beveiligde netwerkverbindingen", schrijven ze op de projectwebsite. Bovendien zou SPDY alsnog sneller zijn dan het onbeveiligde HTTP.

Testresultaten

De belangrijkste doelstelling van het SPDY-project is om de laadtijd van webpagina's te doen afnemen. Het ontwikkelteam schrijft dat ze in gecontroleerde tests een tijdwinst tot wel 64% heeft behaald. Uit een uitgebreide benchmark van Neotys blijkt dat SPDY het wint van zowel HTTP als HTTPS, en Twitter meldde vorig jaar dat ze er eveneens veel winst mee behaald heeft.

In 2012 testte Microsoft versie 2 van SPDY, in combinatie met Apache. Het team kwam tot de gematigde conclusie (PDF) dat websites die momenteel geoptimaliseerd zijn voor HTTP/1.1, niet zoveel baat zullen hebben bij SPDY. Wel staat in de resultaten buiten kijf dat SPDY sneller is dan HTTPS.

De methoden die vandaag de dag toegepast worden om de beperkingen van HTTP/1.1 te omzeilen, zoals het eerder genoemde domain sharding, kunnen de voordelen die SPDY brengt op de korte termijn tegenwerken, schrijft ook Guy Podjarny (Akamai) op zijn weblog. Dat ligt dus niet zozeer aan het SPDY alswel aan de manier waarop website-eigenaren zich hebben aangepast aan HTTP/1.1.

Het moment waarop de tijd rijp is om van optimalisatie voor HTTP/1.1 over te stappen naar optimalisatie voor SPDY danwel HTTP/2.0, wordt grotendeels bepaald door de adoptie en ondersteuning van het protocol door ontwikkelaars van webservers, webbrowsers en andere software.

Ondersteuning in browsers en webservers

Voor de meest populaire webservers, zoals Apache (mod_spdy) en nginx (http_spdy_module), zijn reeds modules beschikbaar waarmee SPDY kan worden ingeschakeld. Of Microsoft het protocol ooit zal ondersteunen in IIS, is niet bekend. Dat geldt ook voor de status van Speed+Mobility (S+M), een revisie van SPDY waarmee het bedrijf zich in de discussie rondom HTTP/2.0 wilde mengen.

Even belangrijk voor het succes van SPDY zijn de webbrowsers. Dat Google Chrome en de Android Browser het protocol al enige tijd ondersteunen, zal voor niemand een verrassing zijn. Mozilla Firefox biedt echter ook ondersteuning sinds versie 13.0 (juni 2012), en Opera sinds versie 12.10 (november 2012).

Achterblijvers zijn met name Apple Safari, die in iOS noch OS X ondersteuning biedt, en Microsoft Internet Explorer, die het ondersteunt in versie 11.0, maar alleen voor gebruikers van Windows 8.1 of nieuwer; gebruikers van IE 11.0 onder Windows 7 vallen buiten de boot.

Adoptie van SPDY anno 2014

Omdat webservers die SPDY aanbieden altijd kunnen terugvallen op HTTPS, staat het gebrek aan ondersteuning vanuit enkele webbrowsers de adoptie van het protocol door websites niet in de weg. Twitter was na Google één van de eerste grote spelers die SPDY implementeerde. Even later volgde Wordpress.com. In 2013 heeft Facebook het protocol geadopteerd, en in februari van dit jaar sloot ook CloudFlare zich aan.

SPDY als startpunt voor HTTP/2

SPDY begon als een onderzoeksproject maar vormt inmiddels ook de basis voor versie 2 van HTTP. Een voorstel voor deze langverwachte opvolger van HTTP/1.1 wordt momenteel ontwikkeld door een werkgroep van de Internet Engineering Task Force (IETF), die de naam Hypertext Transfer Protocol Bis (httpbis) draagt.

HTTP/2 zal voortborduren op de successen van SPDY, maar naar verwachting ook een aantal verbeteringen aanbrengen. Voorstellen voor verbeteringen van het voorstel kunnen nog tot april van dit jaar worden ingediend. Naar verwachting zal HTTP/2.0 in november als nieuwe standaard ter beoordeling worden ingestuurd naar de Internet Engineering Steering Group (IESG), die het aan een laatste technische blik zal onderwerpen alvorens het als definitieve standaard te erkennen.

De weg vrij voor HTTP/3?

Als de invoering van HTTP/2.0 voorspoedig verloopt, is het niet ondenkbaar dat de ontwikkeling van het protocol in een stroomversnelling zal raken. Mark Nottingham, voorzitter van httpbis, schrijft dat "mensen nu graag HTTP/2 'uit de deur' willen hebben", en "een aantal geavanceerde (en experimentele) functies en eigenschappen daarom voorlopig weggelaten zijn".

Vanaf de invoering van HTTP/2.0 zullen de versienummers waarschijnlijk niet meer gebruik maken van onderversies, en zal de opvolger niet HTTP/2.1 maar HTTP/3 worden, volgens Brian Raymor van Microsoft.

Hoe de toekomst van SPDY eruit zal zien nadat HTTP/2 als standaard is erkend, is niet helemaal duidelijk. Versie 4 van SPDY is beter afgestemd op het voorstel voor HTTP/2.0, dus de kans is aanwezig dat de twee protocollen na verloop van tijd zullen samensmelten tot enkel HTTP/2.

Meer weten?

Ilya Grigorik, werkzaam in het Make The Web Fast team bij Google, publiceerde onlangs High-Performance Browser Networking, waarin hij ingaat op SPDY en HTTP/2.0, maar ook op vele andere factoren die de snelheid van het internet beïnvloeden. Het boek is als paperback te koop (±25 EUR), maar ook gratis online te lezen.

Tweeten

Reacties (0)

Er zijn nog geen reacties geplaatst.

Reageren

Reacties worden direct gepubliceerd. We vertrouwen er dan ook op dat je reactie relevant is, geen reclame-uitingen bevat, en de algemeen geldende fatsoensregels niet overschrijdt. Je e-mailadres wordt niet gepubliceerd.

Verzenden