Das IETF-Komitee (Internet Engineering Task Force), das sich mit der Entwicklung von Internetprotokollen und -architekturen beschäftigt, hat die RFC für das Protokoll HTTP/3.0 abgeschlossen und die zugehörigen Spezifikationen unter den Identifikatoren RFC 9114 (Protokoll) und RFC 9204 (Technologie zur Header-Kompression QPACK für HTTP/3) veröffentlicht. Die Spezifikation HTTP/3.0 hat den Status "Vorgeschlagener Standard" erhalten, wonach die Arbeit zur Erteilung des Status eines Entwurfsstandards (Draft Standard) beginnen wird. Dieser Status bedeutet faktisch eine vollständige Stabilisierung des Protokolls und die Berücksichtigung aller geäußerten Anmerkungen. Gleichzeitig wurden aktualisierte Varianten der Spezifikationen für die Protokolle HTTP/1.1 (RFC 9112) und HTTP/2.0 (RFC 9113) veröffentlicht sowie Dokumente, die die Semantik von HTTP-Anfragen (RFC 9110) und HTTP-Header für das Caching (RFC 9111) definieren.
Das HTTP/3-Protokoll definiert die Verwendung des QUIC-Protokolls (Quick UDP Internet Connections) als Transportmittel für HTTP/2. QUIC ist ein Layer über dem UDP-Protokoll, das die Multiplexierung mehrerer Verbindungen unterstützt und Methoden zur Verschlüsselung bereitstellt, die TLS/SSL entsprechen. Das Protokoll wurde 2013 von Google als Alternative zur Kombination TCP+TLS für das Web entwickelt. Es löst Probleme mit langen Zeiten für den Verbindungsaufbau und die Aushandlung in TCP und eliminiert Verzögerungen bei Paketverlusten während der Datenübertragung.
Derzeit ist die Unterstützung für QUIC und HTTP/3.0 bereits in allen gängigen Webbrowsern implementiert (in Chrome, Firefox und Edge ist die HTTP/3-Unterstützung standardmäßig aktiviert, während sie in Safari die Aktivierung der Einstellung „Erweitert > Experimentelle Funktionen > HTTP/3“ erfordert). Auf der Serverseite sind Implementierungen für HTTP/3 für nginx (in einem separaten Branch und als separates Modul), Caddy, IIS und LiteSpeed verfügbar. Auch das Content Delivery Network Cloudflare bietet Unterstützung für HTTP/3.
Hauptmerkmale von QUIC:
- Hohe Sicherheit, die der TLS entspricht (im Wesentlichen ermöglicht QUIC die Nutzung von TLS über UDP);
- Stream-Integrity-Kontrolle zur Vermeidung von Paketverlusten;
- Die Möglichkeit, sofort eine Verbindung herzustellen (0-RTT, in etwa 75 % der Fälle können Daten sofort nach dem Senden des Verbindungsaufbau-Pakets übertragen werden) und die minimalen Verzögerungen zwischen der Anfrage und dem Empfang der Antwort (RTT, Round Trip Time) zu gewährleisten;
- Verwendung einer anderen Sequenznummer bei der erneuten Übertragung eines Pakets, was Mehrdeutigkeiten bei der Bestimmung empfangener Pakete vermeidet und Zeitüberschreitungen beseitigt;
- Ein Paketverlust beeinflusst nur die Zustellung des damit verbundenen Streams und stoppt nicht die Übertragung von Daten in parallel über die aktuelle Verbindung übertragenen Streams;
- Fehlerkorrekturmaßnahmen, die Verzögerungen durch die erneute Übertragung verlorener Pakete minimieren. Einsatz spezieller Fehlerkorrekturcodes auf Paketebene zur Verringerung von Situationen, die eine erneute Übertragung verlorener Daten erfordern.
- Die Grenzen der kryptografischen Blöcke sind an die Grenzen der QUIC-Pakete angepasst, was den Einfluss von Paketverlusten auf die Dekodierung des Inhalts nachfolgender Pakete verringert.
- Keine Probleme mit der TCP-Warteschlangensperre.
- Unterstützung für eine Verbindungs-ID, die die Wiederherstellungszeit für mobile Clients verkürzt.
- Die Möglichkeit, erweiterte Mechanismen zur Überwachung der Verbindungsüberlastung zu integrieren.
- Der Einsatz von Bandbreitenvorhersagetechniken in beide Richtungen sorgt für eine optimale Paketversandintensität und verhindert das Abgleiten in einen Überlastungszustand, der zu Paketverlusten führt.
- Merklicher Leistungs- und Bandbreitenzuwachs im Vergleich zu TCP. Für Videodienste wie YouTube zeigte die Anwendung von QUIC eine Reduzierung der Pufferungsoperationen beim Video-Streaming um 30%.
In den Änderungen der HTTP/1.1-Spezifikation wird der getrennte Gebrauch des Carriage-Return-Zeichens (CR) außerhalb des Inhalts ausgeschlossen, d.h. im Protokoll kann das CR-Zeichen nur zusammen mit dem Zeilenumbruch-Zeichen (CRLF) verwendet werden. Der Algorithmus zur Aufteilung von Chunked-Anfragen wurde überarbeitet, um die Trennung von angehängten Feldern und dem Kopfbereich zu vereinfachen. Es wurden Empfehlungen zur Verarbeitung mehrdeutiger Inhalte hinzugefügt, um Angriffe der Klasse „HTTP Request Smuggling“ zu blockieren, die es ermöglichen, sich in die Inhalte anderer Benutzeranfragen im Fluss zwischen Frontend und Backend einzuklinken.
In der Aktualisierung der HTTP/2.0-Spezifikation wird die Unterstützung von TLS 1.3 ausdrücklich definiert. Das Verfahren zur Prioritätsbestimmung und die damit verbundenen Felder in den Headern wurden als veraltet eingestuft. Der bislang wenig verbreitete Mechanismus zur Verbindungsaktualisierung von HTTP/1.1 wurde für obsolet erklärt. Die Anforderungen an die Überprüfung von Feldnamen und Werten wurden reduziert. Einige zuvor reservierte Rahmenarten und Parameter wurden zur Nutzung vorgeschlagen. Verbotsfelder in Bezug auf die Verbindung wurden präziser definiert.
Quelle: opennet.ru
