Het snellere web protocol HTTP/2 gebruiken en testen

Het nieuwe web protocol HTTP/2 versnelt het uitleveren van websites. Systeembeheerders en webdevelopers kunnen die nieuwe standaard activeren zonder de content te hoeven aanpassen. Het instellen bij nginx, Apache en IIS is zo gebeurd, zoals we hier laten zien.

Als beheerder van een website doe je er alles aan om de pagina’s zo snel mogelijk bij je bezoekers af te leveren. Niemand houdt van lang wachten en bezoekers klikken al snel verder naar de webshop van een concurrent of naar een andere website. Zoekmachines houden ook rekening met de voorkeuren van bezoekers en belonen het sneller opbouwen van een pagina met een hogere positie op de zoekresultaten.

Met het nieuwe webprotocol HTTP/2 beschikken sitebeheerders over een versnellingsoptie, waarvoor ze de inhoud niet eens aan hoeven te passen. Omdat inmiddels bijna alle browsers met HTTP/2 overweg kunnen, is het de moeite waard een overstap te overwegen. Oudere browsers als Internet Explorer bij Windows 7 en 8 vallen probleemloos terug op HTTP 1.1. Je jaagt dus geen bezoekers weg met HTTP/2.

Om de opbouw te versnellen, combineert HTTP/2 verschillende technieken. Al sinds 1999, toen HTTP 1.1 ingevoerd werd, had men door dat het niet gunstig is voor de laadtijd van een webpagina om voor elk opgevraagd element een eigen TCP-verbinding te openen en daarna weer te sluiten. Dat zou dan bijvoorbeeld bij elke afbeelding of script gebeuren. HTTP 1.1 biedt daarom het zogeheten ‘keepalive’, waarbij een verbinding geopend blijft voor verdere pagina-elementen.

Maar het verwerken van alle aanvragen gebeurt per TCP-verbinding weer keurig stuk voor stuk, elke aanvraag komt terecht in een ­wachtrij. Een grote afbeelding in het begin van een reeks kan he downloaden van andere aanvragen dus afremmen (head of line blocking). Ook zogeheten ‘chunked transfer’, waarbij grote elementen gesplitst worden, lost dat probleem niet op. Browsers openen daarom vaak meerdere parallelle TCP-verbindingen. Dat zorgt met elke verbindingsopbouw echter wel voor meer belasting bij de server.

HTTP/2 omzeilt dat probleem door multiplexing. Als een client bijvoorbeeld een background.png, script.css en style.css van de server wil hebben, brengt die eerst een TCP-verbinding tot stand. Daarna verdeelt de client de aanvragen over HTTP/2-frames en wijst aan elk frame een ID toe. De frames verstuurt hij zoals het uitkomt. De server stelt de elementen samen op basis van de ID.

Als een bepaalde aanvraag compleet is, wordt die verwerkt en het resultaat verstuurd, eventueel gemengd met frames van andere elementen. De browser stelt de frames samen en kan met renderen beginnen zodra een element compleet is. Als een afbeelding pas een seconde later komt, blokkeert dat het verwerken van andere elementen niet.

Multiplexing biedt vooral voordelen als een pagina uit veel elementen bestaat. Een goed voorbeeld is de demo van de ontwikkelaars van de programmeertaal Go. Die pagina bevat een afbeelding die uit 15 bij 15 deelafbeeldingen bestaat. Dat resulteert in 255 aanvragen. Via de koppelingen boven de afbeelding kun je kiezen of de pagina met HTTP 1.1 of HTTP/2 moet worden geladen en hoe lang de server elk element vertraagt.

Met de ontwikkelaarsconsole in Chrome is goed te zien dat de afbeeldingen met HTTP 1.1 stuk voor stuk binnenkomen. Het laden van de webpagina met 255 afbeeldingen duurt bijna 6 seconden.

Een blik in de ontwikkelaarsconsole van de browser is daarbij zeker de moeite waard. We gebruiken hier Chrome, maar bij andere browsers werkt dat vergelijkbaar. Open de console met F12 (of met een rechter muisklik en ‘Inspecteren’). Ga naar het tabblad ‘Network’ en klik op de rode opnameknop. Laad de pagina dan via de links met de verschillende proto­collen. In de kolom ‘Waterfall’ zie je hoe efficiënt HTTP/2 werkt in vergelijking met de voorganger.

Met HTTP/2 laadt dezelfde inhoud in 0,75 seconden omdat de afbeeldingen elkaar niet afremmen.

Google Chrome verbergt de belangrijkste informatie aanvankelijk. Klik met de rechtermuisknop op de kolomkop en activeer de kolom ‘Protocol’. Dan zie je vrij eenvoudig of een site HTTP/2 al gebruikt. Een ‘h2’ in de kolom ‘Protocol’ wijst op het nieuwe protocol. Bij grotere websites zie je vaak dat niet alle elementen via hetzelfde protocol geleverd worden. Dat kan bijvoorbeeld komen doordat afbeeldingen of reclame van een andere server moeten worden geladen.

Een andere testtool op de commandline is tot nu toe voorbehouden aan Linux- en Mac-gebruikers. Windows 10 heeft daar nog geen variant van. Je kunt curl dwingen alleen met HTTP/2 te werken:

curl –http2 https://www.google.nl

Als die opdracht geen data oplevert, werkt de server alleen met HTTP 1.1 of 1.0.

De nieuwe standaard heeft nog een truc in huis, die tijdens het standaardiseringsproces flink werd bekritiseerd. Het karakter van het protocol verandert daar namelijk mee. Bij HTTP/2 kan een server namelijk elementen pushen nog voordat een client ze opvraagt. Daarmee kan de server bijvoorbeeld styles.css en background.png versturen zodra een client om index.htm vraagt. De websitebeheerder moet dat wel expliciet configureren. Een andere vernieuwing in HTTP/2 is dat de header ook gecomprimeerd wordt, wat weer extra milli­seconden bespaart.

Heb je een webhostingpakket bij een provider, dan kun je zelf weinig doen. Als je provider HTTPS biedt, moet je dat activeren (en niet alleen omdat het vereist is voor HTTP/2). Controleer met de ontwikkelaarsconsole van Chrome of de website via ‘h2’ wordt geleverd (bij Firefox zie je ‘http/2’). Zo niet, dan is de enige remedie de helpdesk te bellen.

Heb je zelf controle over de hosting, dan moet je eerst alle betrokken web­servers identificeren. Het heeft weinig zin een webserver om te zetten naar HTTP/2 als die achter een HTTP 1.1-loadbalancer staat. We gaan als voorbeeld dan ook even uit van een enkele server. Voorwaarde is dat HTTPS met TLS al actief is. Let’s Encrypt kan daar een gratis certificaat voor leveren. Hoe je dat instelt bij Apache, nginx en IIS, hebben we eerder al eens beschreven. Voor bezoekers die je website oproepen via HTTP moet je een redirect naar HTPPS instellen.

Bij een nginx-server is het configureren zo gebeurd. Update hem eerst, minimaal naar versie 1.95. Open het configuratiebestand voor de website en zoek dan naar het blok ­server{…}. Daar hoef je achter listen 443 alleen http2 toe te voegen. Het blok kan er dan zo uitzien:

server {
listen 443 ssl http2;
server_name example.com;
ssl_certificate example.crt;
ssl_certificate_key example.key;
[…]
}

Je kunt de encryptiealgoritmes na ssl_­ciphers meteen controleren en alleen degene activeren die momenteel nog veilig zijn. Richtlijnen daarvoor staan op GitHub. Voor andere servers dan nginx vind je hier meer over ciphers overnemen. Na een herstart van nginx, bijvoorbeeld met sudo systemctl restart nginx, moet Chrome bij het oproepen van de website het nieuwe protocol aangeven in de ontwikkelaarsconsole.

Om nog een paar milliseconden te winnen, kun je vervolgens server-push nog activeren. Dat is op een server alleen zinvol als de webdeveloper en serverbeheerder dat goed afstemmen. Anders probeert de server bijvoorbeeld het bestand ‘style.css’ te pushen terwijl de ontwikkelaar dat heeft hernoemd naar ‘newstyle.css’. Voor het pushen voldoet de toevoeging http2_push in een location-blok. In het volgende voorbeeld moeten de stijlen, het script en de achtergrond gepusht worden. Dat bespaart tijd bij het opvragen, en browser kan sneller beginnen met renderen:

location = /index.html {
http2_push /style.css;
http2_push /background.png;
http2_push /script.js;
}

Het resultaat kun je in de ontwikkelaarsconsole zien in de kolom ‘Initiator’. Daar moet dan ‘push /index.htm’ opduiken. Als je als webdeveloper zelf server-push wilt activeren zonder dat de beheerder dat in het configuratiebestand aangeeft, kun je de header Link: zelf aanpassen. Daarvoor moet je bij de op de website gebruikte programmeertaal de functie gebruiken de het configureren van headers. Bij PHP krijg je dan bijvoorbeeld:

header(“Link: </style.css>;
rel=preload; as=style”, false);

Daarbij zijn geldige waarden voor de parameter as= behalve style ook image en script.

Apache-gebruikers hebben een recente versie nodig, minimaal 2.2.24, daar zit dan de module mod_http2 in. Die zit bij Debian Stretch in de pakketbronnen, bij Ubuntu vanaf 17.10. Als je een andere distributie hebt, moet je een up-to-date Apache-­archief gebruiken.

Activeer de module vanaf de commandline:

a2enmod http2
apachectl restart

Open het configuratiebestand waarin ook HTPPS is ingesteld. Zoek naar de sectie VirtualHost en voeg de volgende regel toe:

Protocols h2 http/1.1

Na een herstart met apachectl restart probeert de server met de client HTTP/2 af te stemmen. Als dat niet lukt, valt hij terug op HTTP 1.1.

Als je Internet Information Services (IIS) van Windows gebruikt, heb je voor de afwisseling ditmaal het minste werk. IIS 10, dat sinds Windows Server 2016 wordt meegeleverd, probeert zonder verdere configuratie om elke met HTTPS versleutelde website automatisch met HTTP/2 te leveren. Installeer een certificaat, forceer een redirect naar HTTPS en klaar ben je.

Bij IIS is HTTP/2 automatisch actief als TLS geactiveerd is. Bij Windows Server 2019 kun je het nieuwe protocol ook uitschakelen.

Je website (of in elk geval de testomgeving ervan) werkt nu met HTTP/2, maar de code van de site moet nog onderhanden worden genomen. Als het probleem van vertragende afbeeldingen tot nu toe werd opgelost met asynchrone aanvragen in Java­Script, moet je de afbeeldingen voor het testen op de standaardmanier invoegen en de tijd controleren die puur met HTTP/2 gehaald wordt.

Omdat het altijd nog kan gebeuren dat een client alleen HTTP 1.1 ondersteunt, kun je voor die bezoekers een noodoplossing inbouwen. Aan de client-kant kan met JavaScript de waarde van performance.timing.nextHopProtocol worden opgevraagd. Is dat niet h2, dan kan de oude oplossing gebruikt worden. Om aan de serverkant goed te reageren op de verschillende protocollen, heb je al naargelang de programmeertaal diverse opties. In PHP geeft bijvoorbeeld de inhoud van $_SERVER[“SERVER_PROTOCOL”] aan waarmee de client een aanvraag heeft gedaan. De combinatie van Apache en PHP werkt echter niet zonder meer, tenminste niet bij gebruik van mod-php/MPM prefork (wel met php-fm/MPM event).

Problemen met HTTP/2 zijn verder zeldzaam. Gebruikers van F5 hardware-loadbalancers meldden problemen in combinatie met de ontwikkelaarsversie van Chromium. Inzet in eenvoudige omgevingen gaat echter probleemloos. Je hoeft daarbij dus niet bang te zijn om over te stappen.

(Jan Mahn, c’t magazine)