© Alexey Kuznetsov, 123RF

HTTP/2, der aktuelle Vertreter der HTTP-Familie, bringt etliche Vorteile für Website-Betreiber und ihre Nutzer mit sich – jedenfalls dann, wenn man das Protokoll gut an die individuellen Gegebenheiten anpasst.

Das World Wide Web (WWW) basiert seit seinen Anfängen hauptsächlich auf zwei Technologien: der Hypertext Markup Language HTML und dem Hypertext Transfer Protocol HTTP. Dabei ist HTML die wesentlich bekanntere Technologie und auch die mit der turbulenteren Vergangenheit. Neben fragwürdigen technologischen Ausschweifungen wie dem Blink-Tag sind auch Konflikte zwischen den Implementierern stetige Begleiter bei der Weiterentwicklung der Sprache. Manche Weiterentwicklungen wie XHTML haben sich als technologische Sackgasse erwiesen, die in etlichen Projekten erheblichen Mehraufwand verursacht hat.

HTTP/2 im Überblick

Im Vergleich zu HTML hat sich die Weiterentwicklung von HTTP dagegen eher im Verborgenen abgespielt und war weniger von politischen Motiven oder Marketing-Maßnahmen bestimmt. Spätestens, als klar wurde, dass viele Websites rund um die Uhr verfügbar sein müssen und Ausfälle nicht nur im E-Commerce-Bereich sehr schnell sehr teuer werden können, lag der Fokus auf solider Technik und weitgehender Kompatibilität. Neuerungen setzen sich daher nur langsam durch und wurden intensiv getestet.

So ist es auch nicht weiter verwunderlich, dass heute erst rund die Hälfte der Websites HTTP/2 anbietet [1], obwohl es bereits im Mai 2015 im RFC 7540 [2] standardisiert wurde. In dem Webserver Nginx, um den es hier gehen soll, hat das Modul »ngx_http_v2_module« im September 2015 (Nginx 1.9.5) den Vorgänger »ngx_http_spdy_module« abgelöst. Seit April 2016 ist das Modul im “Stable”-Branch (Nginx 1.10.0) [3]. Finanziert wurde die Entwicklung des Nginx-Moduls übrigens durch Dropbox und Automattic (WordPress).

Insbesondere die großen Websites waren schon früh scharf auf die Vorteile, die HTTP/2 gegenüber HTTP/1.1 bietet. Für sie waren Eigenschaften wie eine bessere Komprimierung oder das Request-Multiplexing attraktiv, weil sie die Benutzererfahrung dank höherer Geschwindigkeit direkt verbessern. Heute ist HTTP/2 für Websites kein Alleinstellungsmerkmal mehr, sondern eher ein Must-have-Feature, das viele Benutzer mindestens unbewusst erwarten. HTTP/2 wird von nahezu allen aktuell genutzten Browsern unterstützt, selbst vom immer wieder problematischen Internet Explorer 11, zumindest ab Windows 10 [4].

In den verbreiteten Webservern ersetzt HTTP/2 allerdings nicht HTTP/1.1, sondern steht parallel zur Verfügung. Damit bleibt ohne zusätzliche Konfiguration die Rückwärtskompatibilität mit Clients erhalten, die HTTP/2 nicht verarbeiten können. Für den Systemadministrator vorteilhaft ist auch, dass wichtige Eigenschaften von HTTP/1.1 in HTTP/2 unverändert blieben. So sind etwa die meisten HTTP-Header und die bekannten Statuscodes (1xx, 2xx, …) dieselben, ebenso wie die Request-Methoden (»GET«, »PUT«, etc.).

Damit wird es für die Betreiber von Websites, die noch kein HTTP/2 unterstützen, höchste Zeit für die Umstellung. Wie man das mit Nginx am besten umsetzt, soll dieser Beitrag zeigen.

Nginx und HTTP/2

HTTP/2 wird in Nginx durch das bereits erwähnte Modul »ngx_http_v2_module« angeboten. Man aktiviert es für einen Server-Kontext durch die Verwendung des Parameters »http2« in der Listen-Direktive (Listing 1).

server {
  listen 443 ssl http2;
}

Daraus ergibt sich auch schon eine wichtige Voraussetzung für die Verwendung von HTTP/2: Der Einsatz von Transport Layer Security (TLS), ehemals bekannt als SSL (Secure Sockets Layer), ist zwingend notwendig. HTTP/2 lässt sich also nur bei verschlüsselten Verbindungen zwischen Webbrowser und Webserver verwenden. Das liegt daran, dass die meisten Webbrowser HTTP/2 via ALPN (Application Layer Protocol Negotiation) nachfragen, das wiederum Bestandteil von TLS ist. Das sollte jedoch keine große Hürde darstellen, denn eine verschlüsselte Verbindung gehört heute zu den Grundvoraussetzungen für den sicheren Betrieb eines Webservers. Spätestens seit dem Start von Let’s Encrypt [5] ist das Erstellen eines weithin akzeptierten TLS-Zertifikats auch für kleinere Projekte erschwinglich geworden.

Nach erfolgreicher Konfiguration von TLS und dem Anpassen der Listen-Direktive ist HTTP/2 aktiviert. Damit könnte eigentlich schon alles erledigt sein. Wichtige HTTP/2-Features wie die Header-Komprimierung, Request-Multiplexing und Request-Pipelining stehen ohne weitere Konfiguration sofort zur Verfügung.

Ob weitere Konfigurationsoptionen notwendig sind, hängt in der Praxis von der Auslastung des Webservers ab. Muss ein Webserver nur wenige Zugriffe pro Zeiteinheit verarbeiten, kann er die Vorteile von HTTP/2 für die Benutzer anbieten, ohne dass sich das negativ auswirkt. Bei einer hohen Anzahl von Zugriffen jedoch fallen unter Umständen weitere Konfigurationsschritte an, die sich auch von den Optimierungen unterscheiden, die man aus HTTP/1.1 kennt.

Konfiguration optimieren

Um die optimale Konfiguration zu finden, ist es wichtig, die Unterschiede in der Request-Verarbeitung von HTTP/2 und den Vorgängerprotokollen zu verstehen. HTTP-Protokolle vor HTTP/2 (HTTP/1.0, HTTP/1.1) basieren grundsätzlich auf der Idee des ursprünglichen HTTP-Protokolls (HTTP/0.9). Das geht davon aus, dass ein Webbrowser pro Request (das heißt für eine HTML-Datei, ein Bild und so weiter) eine dezidierte TCP-Verbindung zum Webserver aufbaut, den Request sendet, die Response entgegennimmt und die TCP-Verbindung dann wieder schließt. Mit der Weiterentwicklung von HTML waren allerdings schnell mehrere Requests notwendig, um eine Seite im Browser vollständig darzustellen. Nicht nur viele Bilder, sondern auch zusätzliche Ressourcen wie Stylesheets, Javascript-Dateien, Zählpixel und vieles mehr werden in der HTML-Datei referenziert und wollen vom Server abgerufen werden.

Um diese Flut von Requests möglichst schnell mit möglichst wenig Latenz abzuarbeiten, haben Webbrowser bis zu acht parallele TCP-Verbindungen zum Webserver aufgebaut. Um die Anzahl der TCP-Verbindungen zu reduzieren, wurden mit HTTP/1.1 Persistent Connections eingeführt. Zudem legt das Protokoll fest, dass Webbrowser nicht mehr als zwei parallele Verbindungen zu einem Webserver aufbauen sollten (woran sich aber die Browser-Hersteller eher nicht halten).

Trotzdem war es für den Administrator in erster Linie relevant, die Konfiguration eines Webservers auf eine möglichst hohe Anzahl von gleichzeitigen Verbindungen zu optimieren. Zusätzlich wurden in Zusammenarbeit mit der Anwendungsentwicklung oft spezielle Image-Domains eingeführt (»images.example.com«), um mehr Verbindungen verarbeiten zu können. Gleichzeitig ergab sich daraus der Druck auf die Anwendungsentwicklung, die Anzahl der benötigten Ressourcen für eine Webseite zu verringern. Das hatte unter anderem den Einsatz von Bundling (zum Beispiel via Webpack) und Spriting (eine Collage von mehreren Bildern in einer Datei, die im Webbrowser wieder zerschnitten wird) zur Folge.

HTTP/2 führt Streams und Multiplexing ein, die das Konzept der Persistent Connections deutlich weiterentwickeln. Über eine einzige TCP-Verbindung zwischen Webbrowser und Webserver können jetzt beliebig viele Requests auch parallel verarbeitet werden. Die Anzahl der gleichzeitigen TCP-Verbindungen entspricht jetzt also mehr oder weniger der Anzahl der gleichzeitigen Nutzer und geht damit im Vergleich zu früheren Protokollversionen deutlich zurück. Gleichzeitig steigt aber die durchschnittliche Dauer einer TCP-Verbindung und möglicherweise auch deren Speicherplatzbedarf, da über diese eine Verbindung jetzt mehr Datenverkehr abgewickelt wird.

Wichtige Konfigurationsoptionen

Bei der Konfiguration von Nginx rücken daher zwei HTTP/2-spezifische Konfigurationsdirektiven in den Vordergrund, mit denen man den Webserver sehr gut an die eigene Anwendung anpassen kann.

Die Direktive »http2_idle_timeout« gibt an, wie lange eine HTTP/2-Verbindung nach dem letzten Datenaustausch offengehalten wird. Sie ist vergleichbar mit der älteren Direktive »keepalive_timeout« für HTTP/1.1. Schon die von Nginx vorgesehenen Default-Werte – 75 Sekunden für »keepalive_timeout«, 180 Sekunden für »http2_idle_timeout« – deuten darauf hin, dass hier unterschiedliche Anwendungsfälle berücksichtigt werden. Während die 75 Sekunden eher als Mittelwert für eine potenzielle Navigation des Benutzers zur nächsten Webseite gelten dürfen, handelt es sich bei den 180 Sekunden eher um einen Maximalwert. Sie sollen sicherstellen, dass sich jede Navigation des Benutzers möglichst über die bestehende Verbindung abhandeln lässt.

Die Direktive »http2_max_requests« gibt an, wie viele Requests maximal über eine bestimmte TCP-Verbindung verarbeitet werden dürfen. Auch hier gibt es eine Parallele zu HTTP/1.1 (»keepalive_requests«), und wieder zeigen die Default-Werte (100 vs. 1000), dass sich das Optimierungsziel deutlich gewandelt hat.

Beide Direktiven sind notwendig, um die Webserver-Ressourcen zu schützen. »http2_idle_timeout« soll verhindern, dass die gleichzeitig möglichen Verbindungen zum Webserver von Clients blockiert werden, die sie gar nicht wirklich benötigen. Da der Speicherbedarf pro Verbindung mit der Anzahl der Requests für diese Verbindung wächst, soll »http2_max_requests« verhindern, dass eine Verbindung zu viel Speicher für sich beansprucht, ohne diesen tatsächlich noch zu benötigen.

Die Charakteristik einer Webanwendung

Beide HTTP/2-Direktiven haben gemeinsam, dass sie im Vergleich zu ihren älteren Gegenstücken deutlich sensibler auf die Anatomie der Website oder -anwendung reagieren. Um das zu verdeutlichen, ziehen wir zwei (extreme) Beispiele heran: einerseits die Web-Version des RFC 7540 [2], andererseits eine Webanwendung wie etwa Google Docs.

Die RFC-Seite ist geprägt durch eine minimale Anzahl an Requests zur Darstellung der Seite (das initiale HTML-Dokument und eine Grafik als Favicon), eine niedrige Wahrscheinlichkeit für eine Navigation des Nutzers (weil die Seite nur wenige Links enthält) sowie eine lange Betrachtungsdauer (weil das Dokument sehr groß ist und damit die Lesezeit eher hoch ist).

Webanwendungen haben dagegen eine ganz andere Charakteristik: Schon die Darstellung der ersten Seite erfordert Dutzende von Requests. Die vielfältigen Interaktionmöglichkeiten erhöhen die Wahrscheinlichkeit, dass der Benutzer navigiert. Hinzu kommen noch mögliche XHR-Requests, die durch das in der Seite vorhandene Javascript jederzeit ausgelöst werden können. Dies ist auch wahrscheinlich, da der Benutzer vermutlich über längere Zeit mit der Seite interagiert.

Betrachtet man diese Extreme, dann erkennt man schnell, dass korrekt gewählte Konfigurationswerte bei HTTP/2 enorm an Bedeutung gewonnen haben. Ein sehr hoher Wert für »http2_idle_timeout« ist im Fall des RFC-Abrufs direkt schädlich, weil wertvolle Verbindungen ungenutzt aufrechterhalten werden. Bei der Webanwendung verbessert ein sehr hoher Wert dagegen direkt das Nutzererlebnis, da sich die durch den Verbindungsaufbau entstehende Latenz im besten Fall vollständig vermeiden lässt.

Für »http2_max_requests« ist im RFC-Beispiel ein hoher Wert vermutlich nicht schädlich, weil die Verbindung sehr wahrscheinlich beendet wird, bevor die maximale Anzahl der Requests erreicht ist. Im Fall der Webanwendung lassen sich die Vorteile von HTTP/2 jedoch nur dann ausschöpfen, wenn der Wert so hoch eingestellt ist, dass zumindest der initiale Seitenaufbau und die ersten Nutzerinteraktionen vollständig über eine Verbindung abgehandelt werden können, sodass eben kein neuer Verbindungsaufbau notwendig ist.

Diese Beispiele zeigen zweierlei: Erstens kann HTTP/2 sein volles Potenzial kaum ausschöpfen, wenn der Administrator bei der Konfiguration eher konservativ auf mittlere Werte setzt. Zweitens hängt die Konfiguration bei HTTP/2 sehr eng mit der tatsächlichen Anwendung zusammen – Website ist nicht gleich Website.

Außerdem kann man daraus durchaus ableiten, dass Bundling und Spriting deutlich weniger Einfluss auf die Geschwindigkeit einer Website haben. Daher sieht eine Aufwand-Nutzen-Abwägung mit HTTP/2 anders aus als mit HTTP/1.1. Gerade bei neuen Projekten kann man sich gegebenenfalls das Einrichten einer Bundling-Pipeline sparen. Auch die Grafikabteilung lässt sich durch den Verzicht auf Spriting entlasten.

Lieber messen als raten

Mit HTTP/2 gewinnt es an Bedeutung, die passende Konfiguration durch Messungen zu ermitteln. Dies ist zum Glück gar nicht so schwer. Alle modernen Browser bieten eine mehr oder weniger ausgefeilte Entwicklerkonsole an, die tiefe Einblicke in die Anatomie der eigenen Website erlaubt. Im Folgenden kommen als Beispiel die Chrome-Entwickler-Tools zum Einsatz.

Um die Anzahl der Requests für eine übliche Nutzerinteraktion zu ermitteln, hilft der Tab Network. Hier wählt man Preserve Log und Disable Cache und schränkt dann über das Suchfeld noch auf die Domain ein, die man untersuchen will – beispielsweise mit »domain:www.linux-magazin.de«. Nun lädt man die Website und nimmt typische Nutzeraktionen vor. In der Fußzeile kann man jederzeit die Zahl der abgearbeiteten Requests ablesen (Abbildung 1).

Abbildung 1: Analyse des Web-Traffics mit den Chrome-Entwickler-Tools.

Ob man schon HTTP/2 einsetzt, lässt sich in der Spalte Protocol ablesen, die eventuell durch einen Rechtsklick auf die Spaltenüberschriften eingeblendet werden muss. Steht dort h2, ist HTTP/2 im Einsatz. Wenn man schon HTTP/2 einsetzt, kann man auch die Spalte Connection ID einblenden: Dort erscheint dann die ID der TCP-Verbindung. Damit lässt sich herausfinden, wann der Browser eine neue TCP-Verbindung herstellt.

Um einen Eindruck von der Verweildauer der Benutzer zu bekommen, lohnt eine Rückfrage in der Marketing-Abteilung. Die üblichen Analysetools, wie etwa Google Analytics, liefern hierzu gute Anhaltspunkte. Dabei sollte man sich allerdings nicht durch niedrige durchschnittliche Werte täuschen lassen: Möglicherweise gilt es, das Segment der Power-User separat zu betrachten.

Nach der Pflicht kommt die Kür: Server Push

HTTP/2 bietet außerdem ein weiteres Feature, das das Benutzererlebnis deutlich verbessert: Server Push. Damit löst HTTP/2 das Problem, dass sich aus Sicht der Webanwendung durchaus vorhersagen lässt, welche Ressourcen (Bilder, Javascript, und so weiter) der Client benötigen wird, um eine Webseite vollständig darzustellen.

Dazu genügt im ersten Schritt ein Blick in den Header einer HTML-Datei: Hier tummelt sich üblicherweise eine bunte Mischung aus CSS- und Javascript-Ressourcen. Diese Information steht auch dem Webbrowser zur Verfügung, allerdings erst, nachdem er das initiale HTML-Dokument heruntergeladen und geparst hat. Erst dann sendet er einen Request für die zusätzlichen Ressourcen an den Server und muss einen zusätzlichen Netzwerk-Roundtrip abwarten, bevor die Antworten bei ihm ankommen.

Mit Server Push in HTTP/2 kann man diese zusätzlichen Ressourcen direkt der Response für die initiale HTML-Datei hinterherschicken – noch bevor der Browser überhaupt weiß, dass er sie benötigen wird. Der Browser nimmt die zusätzlichen Responses entgegen und legt sie im Browser-Cache ab. Wird beim Parsen dann ein Request für eine bestimmte Ressource nachgefragt, kommt die Antwort sofort und mit hoher Geschwindigkeit aus dem lokalen Cache; der Netzwerk-Roundtrip zum Server entfällt also.

Daraus ergibt sich direkt eine Anforderung an die Ressourcen, die per Server Push gesendet werden sollen: Sie müssen pufferbar sein. Der Browser muss aus den Response-Headern, die beim Server Push genauso funktionieren wie bei einem normalen Request, ablesen können, dass die Response eine Zeitlang gültig bleibt. Dies erfolgt in Nginx mit der üblichen Konfigurationsdirektive »expires«. Hat man sie gesetzt, kann man mit der Direktive »http2_push« einzelne Dateien an den Client pushen. In Beispiel aus Listing 2 werden die Dateien »styles.css« und »scripts.js« direkt mit der Response zu einem Request für »index.html« mitgeschickt.

location /index.html {
  http2_push /css/styles.css;
  http2_push /js/scripts.js;
}

Das kann man zum Beispiel mithilfe der Chrome-Entwickler-Tools verfolgen, indem man die Spalte Initiator betrachtet. Sofern Disable Cache aktiviert ist, lässt sich dort am Eintrag Push / … ablesen, dass die Datei per HTTP/2-Push beim Browser angekommen ist. Doch Vorsicht: Nicht alle Dateien, die der Server per Push gesendet hat, erscheinen hier. Enthielt die aktuelle HTML-Seite (bisher) gar keinen Request für eine Datei, dann taucht sie auch nicht in der Liste auf. Sobald aber ein solcher Request erfolgt, taucht sie auch in der Liste auf.

Allerdings führt Disable Cache in den Entwickler-Tools auch dazu, dass sich der Browser nicht so verhält wie der eines normalen Benutzers. Alternativ bemüht man deshalb das Nginx-Access-Log, um zu prüfen, ob der Server Push korrekt funktioniert. Die per Server-Push gesendeten Dateien tauchen im Access-Log zunächst als ganz normale Requests auf. Ergänzt man allerdings die Nginx Log-Ausgabe um das Schlüsselwort »$msec« (Listing 3), kann man sehen, dass alle Requests zur exakt gleichen Zeit verarbeitet wurden (Listing 4). Dies deutet auf den Push hin.

log_format  http2 '$time_iso8601 $msec$status $connection $http2 "$request"';

2020-11-22T12:01:10+01:00 1606042870.567 200 605 h2 "GET /index.html HTTP/2.0"
2020-11-22T12:01:10+01:00 1606042870.567 200 605 h2 "GET /css/styles.css HTTP/2.0"
2020-11-22T12:01:10+01:00 1606042870.567 200 605 h2 "GET /js/scripts.js HTTP/2.0"

Wenn man das Verhalten von Nutzern auf der eigenen Seite sehr gut kennt, dann kann man auch durchaus in Betracht ziehen, schon direkt die am häufigsten aufgerufene Folgeseite selbst zu pushen (Listing 5). Folgt der Benutzer tatsächlich diesem Navigationspfad, bedient der Browser den entsprechende Request für »/naechste-seite.html« praktisch ohne Zeitverzögerung aus dem lokalen Cache.

location /index.html {
  http2_push /css/styles.css;
  http2_push /js/scripts.js;
  http2_push /naechste-seite.html;
}

Bei all dem gilt es jedoch zu beachten, dass Nginx sich nicht merkt, welche Ressourcen schon an einen Client gesendet wurden und dort höchstwahrscheinlich im Cache liegen. Bei Konfigurationsfehlern kann es daher durchaus dazu kommen, dass Nginx Ressourcen sendet, die beim Client schon vorliegen, und somit Netzwerkbandbreite verschwendet. Insbesondere bei Ressourcen mit sehr unterschiedlichen Cache-Dauern sollte man hier sehr genau aufpassen.

Nginx als Proxy

Wenn Nginx als Proxy vor einem Application-Server arbeitet, ist es kaum praktikabel, die Nginx-Konfiguration für den HTTP/2-Push in allen Details an die Webanwendung anzupassen. An dieser Stelle hilft die Direktive »http2_push_preload« (Listing 6).

location /proxy/ {
  proxy_pass http://applicationserver/;
  http2_push_preload
 on;
}

Diese Direktive verarbeitet Link-Header der Upstream-Ressourcen und sendet mit »rel=preload« gekennzeichnete Ressourcen automatisch, also immer dann, wenn eine Response vom Applikationsserver diesen Header mitschickt. Bei folgender Anweisung sendet Nginx beispielsweise automatisch und zusätzlich zu der eigentlichen Response die Ressource »/css/styles.css« als Push an den Client:

link: </css/styles.css>; rel=preload; as=style

Mit diesem Mechanismus lässt sich das Push-Verhalten direkt von der Webanwendung steuern. Da die Webanwendung vermutlich über ein State-Management verfügt, ist es an dieser Stelle auch viel einfacher, unnötige Push-Vorgänge zu vermeiden. So lassen sich zum Beispiel nur bei Session-Beginn Ressourcen per Push senden.

Listing 7 zeigt beispielhaft eine Nginx-Konfiguration für HTTP/2 und kann als Ausgangspunkt für eigene Experimente dienen.

http {
  log_format http2 '$time_iso8601 $msec $status $connection $http2 "$request"';
  server {
    listen 443 ssl http2; # TLS und HTTP/2
    http2_idle_timeout 3m;
    http2_max_requests 1000;
    access_log  /usr/local/var/log/nginx/http2.log http2;
    ssl_certificate /test.crt;
    ssl_certificate_key /test.key;
    root /var/www/html;
    # Notwendig für Server Push:
    location /css/ {
      expires 3h;
    }
    location /js/ {
      expires 3h;
    }
    location /index-2.html {
      expires 3h;
    }
    # Beispiel für Server Push
    # Aufruf: GET /
    location /index.html {
      # Diese Dateien werden per push gesendet,
      # wenn der Client /index.html aufruft:
      http2_push /css/styles.css;
      http2_push /js/scripts.js;
      # voraussichtliches nächstes Navigationsziel:
      http2_push /index-2.html;
    }
    # Beispiel für Nginx als Proxy mit http2_push_preload.
    # Der (simulierte) Applikationsserver steht weiter unten.
    # Aufruf: GET /applicationserver/
    location /applicationserver/ {
      proxy_pass http://localhost:1025/;
      # Link header mit rel=preload verarbeiten:
      http2_push_preload on;
    }
  }
  # Simulation Applikationsserver:
  server {
    listen 1025;
    root /var/www/html;
    location ~ .html$ {
      # Hinweise für http2_push_preload:
      add_header Link "</css/styles.css>; rel=preload; as=style";
      add_header Link "</js/scripts.js>; rel=preload; as=script";
    }
  }
}

Fazit

Schon ohne besondere Konfiguration bringt das Aktivieren von HTTP/2 einen Geschwindigkeitsvorteil für die Benutzer. Mit sorgfältigem Tuning der maximalen Requests und Idle-Zeiten pro Connection kann man die Belastung des eigenen Servers senken. Durch Nutzen der Push-Mechanismen lässt sich zudem die vom Benutzer wahrgenommene Geschwindigkeit erheblich verbessern. In der Praxis erfordert das die Mitarbeit der Software-Entwicklungsabteilung, die aber im Gegenzug perspektivisch die Aufwände für Bundling und Spriting reduzieren kann.

Insgesamt zeigt die Entwicklung von HTTP/2 deutlich, dass in der engeren Abstimmung zwischen der Software-Entwicklung und der Webserver-Infrastruktur erhebliche Optimierungspotenziale liegen. Mit dem Erscheinen des ersten Drafts von HTTP/3 im November 2020 wurde auch deutlich, dass solche Investitionen sich lohnen. HTTP/3 wird wohl hauptsächlich die mit HTTP/2 eingeführten Multiplexing-Mechanismen im Hinblick auf die darunterliegende Netzwerkschicht optimieren. Man darf also davon ausgehen, bei sinnvoller Nutzung von HTTP/2-Mechanismen demnächst direkt von den zu erwartenden Optimierungen durch HTTP/3 zu profitieren. Daher erscheint der Einsatz von HTTP/2 schon heute als lohnende Optimierung, die man jedem Webserver-Betreiber nur dringend ans Herz legen kann. (jcb/jlu)