Software::Netzwerk
HTTP/3 vor weiteren Hürden
HTTP/3 soll im Juli als offizieller Standard veröffentlicht werden. Doch eine ganze Reihe von Faktoren könnten dafür sorgen, dass es auf längere Zeit noch keine Rolle in der Praxis spielen wird.
Mike Bishop
Von HTTP/QUIC zu HTTP/3
HTTP/3 wurde als Nachfolger des Protokolls HTTP/2 konzipiert, das seinerseits der Nachfolger von HTTP/1.1 und HTTP/1 ist. Ein Nachfolger wurde für notwendig erachtet, da die massive Steigerung der Bedeutung des WWW zu Anforderungen nach mehr Geschwindigkeit und niedrigeren Latenzen führte. Das aktuelle HTTP/2, das allerdings auch noch nicht universell verfügbar ist, lässt nur verschlüsselte Verbindungen zu und baut dazu auf TLS und TCP auf. Dadurch besitzt es aber mindestens drei Nachteile. Erstens ist das Aushandeln von TLS-Verbindungen aufwendig und erfordert mehrere Anfrage- und Antwortpakete. Zweitens beginnt TCP grundsätzlich mit einer niedrigen Übertragungsrate, um Staus zu vermeiden, und kann daher bei kürzeren Daten die Bandbreite nicht ausnutzen. Drittens kommt es bei Paketverlusten zu langen Verzögerungen, bis das fehlende Paket in einem weiteren Versuch übertragen werden kann, und diese Verzögerungen wirken sich auf alle Daten aus, die in derselben Verbindung nach dem aktuellen Objekt noch übertragen werden.
Um das Problem zu lösen, entwickelte Google das QUIC-Protokoll, dessen Standardisierung an die IETF abgegeben wurde. Die IETF benannte das Protokoll schließlich in HTTP/3 um. Die Anwendungsebene in HTTP/3, die für den zuverlässigen Transport der Datenströme sorgt, behielt aber den Namen QUIC bei. Die Arbeiten an der Standardisierung von HTTP/3 und QUIC sind beinahe abgeschlossen. Aktuell liegt Version 27 der Spezifikation vor und das Ziel ist, HTTP/3 im Juli als offiziellen Standard zu veröffentlichen.
TLS-Verschlüsselung ist in HTTP/3 fester Bestandteil von QUIC und damit verbindlich. QUIC selbst baut auf UDP auf und stellt wie TCP einen zuverlässigen, verlustfreien Transport bereit, aber ohne die genannten Nachteile von TLS TCP. UDP zu verwenden, statt ein neues Protokoll zu entwickeln, hatte sehr handfeste Gründe. Zum einen können Millionen von Geräten und Routern im Internet nur TCP und UDP gut verarbeiten oder lassen erst gar nichts anderes passieren. Zum anderen ermöglicht es UDP, dass man darauf aufbauende Protokolle außerhalb des Kernels, in der Anwendersoftware, implementiert.
Ein aktueller Artikel auf LWN fasst nun einen Vortrag von Daniel Stenberg zusammen, den dieser auf der FOSDEM gehalten hat. Stenberg, der auch als Autor von Curl bekannt ist, hatte im November 2018 ein frei verfügbares Buch zu HTTP/3 veröffentlicht. Nach einem umfassenden Überblick über HTTP/3 beleuchtet Stenberg, wie es um die praktische Einsetzbarkeit von HTTP/3 bestellt ist. Das erste Problem könnte sein, dass UDP in vielen Gateways blockiert wird. Zwischen 3 und 7 Prozent aller Verbindungsversuche dürften dadurch scheitern. Die Browser und andere Clients müssen daher die Möglichkeit haben, automatisch auf HTTP/2 oder früher zurückzufallen. Das wiederum vermindert den Druck auf die Administratoren, HTTP/3 einzuführen oder durchzulassen.
Aktuell ist QUIC in Form von Bibliotheken implementiert. Es benötigt anscheinend bis zu dreimal soviel CPU-Ressourcen wie die Vorgänger. Teil dieses Problems ist die Nutzung von UDP. Während der Linux-Kernel extrem für TCP optimiert wurde, wurde UDP vernachlässigt und besitzt auch keine Hardware-Unterstützung. Eine Implementation von QUIC im Kernel könnte zumindest einige Kontextwechsel zwischen Kernel und Anwendungen einsparen. Das würde aber auch eine neue TLS-Implementation im Kernel erfordern, da QUIC TLS anders verwendet als es bisher implementiert ist. Doch auch außerhalb des Kernels fehlt noch einiges. OpenSSL-Unterstützung ist noch in Arbeit, tcpdump unterstützt QUIC noch gar nicht. Unterstützung für QUIC existiert bereits in Wireshark, Curl und spezialisierten Werkzeugen. Firefox und Chromium beherrschen in ihren Testversionen bereits HTTP/3, auf Seiten der Webserver gibt es im Wesentlichen nur eine Testversion von Nginx. Auf die Verbesserungen, die HTTP/3 verspricht, werden die Anwender daher noch länger warten müssen.