Die IETF (Internet Engineering Task Force), die für die Entwicklung von Internetprotokollen und -architektur verantwortlich ist, hat die Bildung eines RFC für das HTTP/3.0-Protokoll abgeschlossen und entsprechende Spezifikationen unter den Kennungen RFC 9114 (Protokoll) und RFC 9204 veröffentlicht ( QPACK-Header-Komprimierungstechnologie für HTTP/3). Die HTTP/3.0-Spezifikation hat den Status eines „Vorgeschlagenen Standards“ erhalten. Danach wird mit der Arbeit begonnen, dem RFC den Status eines Standardentwurfs (Draft Standard) zu verleihen, was eigentlich eine vollständige Stabilisierung des Protokolls und unter Berücksichtigung aller bedeutet die abgegebenen Kommentare. Gleichzeitig wurden aktualisierte Versionen der Spezifikationen für die Protokolle HTTP/1.1 (RFC 9112) und HTTP/2.0 (RFC 9113) sowie Dokumente veröffentlicht, die die Semantik von HTTP-Anfragen (RFC 9110) und HTTP-Caching-Kontrollheader definieren (RFC 9111).
Das HTTP/3-Protokoll definiert die Verwendung des QUIC-Protokolls (Quick UDP Internet Connections) als Transport für HTTP/2. QUIC ist eine Erweiterung des UDP-Protokolls, das das Multiplexen mehrerer Verbindungen unterstützt und Verschlüsselungsmethoden bereitstellt, die TLS/SSL entsprechen. Das Protokoll wurde 2013 von Google als Alternative zur TCP+TLS-Kombination für das Web entwickelt. Es löst Probleme mit langen Verbindungsaufbau- und Aushandlungszeiten in TCP und eliminiert Verzögerungen, wenn Pakete während der Datenübertragung verloren gehen.
Derzeit ist die QUIC- und HTTP/3.0-Unterstützung bereits in allen gängigen Webbrowsern implementiert (in Chrome, Firefox und Edge ist die HTTP/3-Unterstützung standardmäßig aktiviert und in Safari ist die Einstellung „Erweitert > Experimentelle Funktionen > HTTP/3“ erforderlich aktiviert werden). Auf der Serverseite stehen HTTP/3-Implementierungen für Nginx (in einem separaten Zweig und in Form eines separaten Moduls), Caddy, IIS und LiteSpeed zur Verfügung. HTTP/3-Unterstützung wird auch vom Cloudflare Content Delivery Network bereitgestellt.
Hauptmerkmale von QUIC:
- Hohe Sicherheit ähnlich wie TLS (im Wesentlichen bietet QUIC die Möglichkeit, TLS über UDP zu verwenden);
- Kontrolle der Flussintegrität, um Paketverluste zu verhindern;
- Die Fähigkeit, sofort eine Verbindung aufzubauen (0-RTT, in etwa 75 % der Fälle können Daten sofort nach dem Senden des Verbindungsaufbaupakets übertragen werden) und minimale Verzögerungen zwischen dem Senden einer Anfrage und dem Empfang einer Antwort (RTT, Round Trip Time) bereitzustellen;
- Verwendung einer anderen Sequenznummer bei der erneuten Übertragung eines Pakets, wodurch Unklarheiten bei der Identifizierung empfangener Pakete vermieden und Zeitüberschreitungen vermieden werden;
- Der Verlust eines Pakets wirkt sich nur auf die Zustellung des damit verbundenen Streams aus und stoppt nicht die Zustellung von Daten in parallelen Streams, die über die aktuelle Verbindung übertragen werden.
- Fehlerkorrekturfunktionen, die Verzögerungen aufgrund der erneuten Übertragung verlorener Pakete minimieren. Verwendung spezieller Fehlerkorrekturcodes auf Paketebene, um Situationen zu reduzieren, die eine erneute Übertragung verlorener Paketdaten erfordern.
- Kryptografische Blockgrenzen sind an den QUIC-Paketgrenzen ausgerichtet, wodurch die Auswirkungen von Paketverlusten auf die Dekodierung des Inhalts nachfolgender Pakete verringert werden.
- Keine Probleme mit der TCP-Warteschlangenblockierung;
- Unterstützung für Verbindungsidentifikatoren, wodurch die Zeit zum Herstellen einer erneuten Verbindung für mobile Clients verkürzt wird;
- Möglichkeit der Anbindung erweiterter Mechanismen zur Kontrolle von Verbindungsüberlastungen;
- Verwendet Techniken zur Vorhersage des Durchsatzes pro Richtung, um sicherzustellen, dass Pakete mit optimalen Raten gesendet werden und so verhindert wird, dass sie überlastet werden und Paketverluste verursachen.
- Deutliche Steigerung der Leistung und des Durchsatzes im Vergleich zu TCP. Bei Videodiensten wie YouTube reduziert QUIC nachweislich die Umpufferungsvorgänge beim Ansehen von Videos um 30 %.
Zu den Änderungen in der HTTP/1.1-Spezifikation gehört das Verbot der isolierten Verwendung des Wagenrücklaufzeichens (CR) außerhalb des Textkörpers mit Inhalt, d. h. In Protokollelementen kann das CR-Zeichen nur in Verbindung mit dem Zeilenumbruchzeichen (CRLF) verwendet werden. Der Chunked-Request-Layout-Algorithmus wurde verbessert, um die Trennung angehängter Felder und Abschnitte mit Headern zu vereinfachen. Empfehlungen für den Umgang mit mehrdeutigen Inhalten hinzugefügt, um „HTTP Request Smuggling“-Angriffe zu blockieren, die es uns ermöglichen, uns in den Inhalt der Anfragen anderer Benutzer im Fluss zwischen Frontend und Backend einzuschleusen.
Das HTTP/2.0-Spezifikationsupdate definiert explizit die Unterstützung für TLS 1.3. Das Priorisierungsschema und die zugehörigen Headerfelder sind veraltet. Der ungenutzte Mechanismus zur Aktualisierung der Verbindung mit HTTP/1.1 wurde für veraltet erklärt. Reduzierte Anforderungen für die Überprüfung von Feldnamen und -werten. Einige zuvor reservierte Rahmentypen und Parameter werden zur Verwendung vorgeschlagen. Die verbotenen Header-Felder im Zusammenhang mit der Verbindung werden genauer definiert.
Source: opennet.ru