Das Protokoll HTTP/3.0 erhielt den Status eines vorgeschlagenen Standards.

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 fertiggestellt und die damit verbundenen Spezifikationen unter den Identifikationsnummern RFC 9114 (Protokoll) und RFC 9204 (Technologie zur Komprimierung von Headern QPACK für HTTP/3) veröffentlicht. Die Spezifikation HTTP/3.0 erhielt den Status "Vorgeschlagener Standard", nach dem die Arbeiten zur Erlangung des Status eines Entwurfstandards (Draft Standard) beginnen, was faktisch eine vollständige Stabilisierung des Protokolls und die Berücksichtigung aller geäußerten Anmerke bedeutet. Gleichzeitig wurden aktualisierte Versionen 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 die HTTP-Caching-Header (RFC 9111) definieren.

Das Protokoll HTTP/3 definiert die Verwendung des Protokolls QUIC (Quick UDP Internet Connections) als Transport für HTTP/2. QUIC ist eine Erweiterung des UDP-Protokolls, die die Multiplexierung mehrerer Verbindungen unterstützt und Verschlüsselungsmethoden bietet, die TLS/SSL entsprechen. Das Protokoll wurde 2013 von Google als Alternative zur Kombination TCP+TLS für das Web entwickelt, um die Probleme mit der langen Zeit zur Herstellung und Aushandlung von Verbindungen in TCP zu lösen und Verzögerungen beim Verlust von Paketen während der Datenübertragung zu beseitigen.

Derzeit wird die Unterstützung für QUIC und HTTP/3.0 bereits in allen gängigen Webbrowsern realisiert (in Chrome, Firefox und Edge ist die Unterstützung für HTTP/3 standardmäßig aktiviert, während sie in Safari die Aktivierung der Einstellung „Erweitert > Experimentelle Funktionen > HTTP/3“ erfordert). Auf der Serverseite sind Implementierungen von HTTP/3 für nginx (in einem separaten Branch und in Form eines separaten Moduls), Caddy, IIS und LiteSpeed verfügbar. Auch das Content Delivery Network Cloudflare unterstützt HTTP/3.

Die Hauptmerkmale von QUIC:

• Hohe Sicherheit, vergleichbar mit TLS (im Grunde ermöglicht QUIC die Verwendung von TLS über UDP);
• Kontrolle der Integrität des Datenstroms, um Paketverluste zu verhindern;
• Die Möglichkeit, sofort eine Verbindung herzustellen (0-RTT, in etwa 75 % der Fälle können Daten sofort nach dem Senden des Verbindungsaufbaupakets übertragen werden) und minimalen Verzögerungen zwischen dem Senden der Anfrage und dem Empfang der Antwort (RTT, Round Trip Time) zu gewährleisten;
• Verwendung einer anderen Sequenznummer für die erneute Übertragung eines Pakets, wodurch Mehrdeutigkeiten beim Bestimmen empfangener Pakete vermieden werden und Zeitüberschreitungen eliminiert werden;
• Paketverluste beeinflussen nur den damit verbundenen Datenstrom und stoppen nicht die Datenübertragung in parallel über die aktuelle Verbindung gesendeten Datenströmen;
• Fehlerkorrekturmaßnahmen, die Verzögerungen aufgrund der erneuten Übertragung verlorener Pakete minimieren. Verwendung spezieller Fehlerkorrekturcodes auf Paketeebene, um Situationen zu reduzieren, die eine erneute Übertragung der Daten des verlorenen Pakets erfordern.
• Die Grenzen der kryptografischen Blöcke sind an die Grenzen der QUIC-Pakete angepasst, was die Auswirkungen von Paketverlusten auf die Dekodierung der Inhalte nachfolgender Pakete verringert;
• Keine Probleme mit der Blockierung von TCP-Warteschlangen;
• Unterstützung einer Verbindungs-ID, die die Zeit für die Wiederherstellung einer Verbindung für mobile Clients reduziert;
• Die Möglichkeit, erweiterte Mechanismen zur Überlaststeuerung der Verbindung zu integrieren;
• Einsatz von Bandbreitenvorhersagetechniken in jede Richtung, um die optimale Intensität der Paketsendung sicherzustellen und ein Abrutschen in einen Überlastzustand, der Paketverluste zur Folge hat, zu verhindern;
• Deutlicher Leistungs- und Bandbreitenschub im Vergleich zu TCP. Für Video-Streaming-Dienste wie YouTube hat der Einsatz von QUIC eine Reduzierung der Puffervorgänge beim Video-Streaming um 30 % gezeigt.

Zu den Änderungen in der Spezifikation HTTP/1.1 gehört das Verbot der isolierten Verwendung des Carriage Return (CR) außerhalb des Inhalts, das heißt, im Protokollelement kann das CR-Symbol nur zusammen mit dem Zeilenumbruchsymbol (CRLF) angewendet werden. Der Algorithmus zur Segmentierung von chunked-Anfragen wurde überarbeitet, um die Trennung von angehängten Feldern und dem Header-Bereich zu erleichtern. 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 von Anfragen anderer Benutzer im Datenstrom zwischen Frontend und Backend einzumischen.

In der Aktualisierung der HTTP/2.0-Spezifikation wurde die Unterstützung für TLS 1.3 ausdrücklich definiert. Die alte Methode zur Priorisierung und damit verbundene Felder in den Headern wurde als veraltet erklärt. Der weniger verbreitete Mechanismus zur Aktualisierung der Verbindung zu HTTP/1.1 wurde ebenfalls für obsolet erklärt. Die Anforderungen an die Überprüfung von Feldnamen und Werten wurden reduziert. Einige zuvor reservierte Rahmen- und Parameterarten wurden zur Nutzung vorgeschlagen. Verbotene Headerfelder in Bezug auf die Verbindung wurden präziser definiert.

Quelle: opennet.ru