In den nächtlichen Builds von Firefox sowie in der Beta-Version ist die Unterstützung des Protokolls HTTP/3 standardmäßig aktiviert. In der stabilen Version ist die Einführung von HTTP/3 für das geplante Release von Firefox 88 am 20. April vorgesehen.
Die Unterstützung von HTTP/3 in Firefox basiert auf dem von Mozilla entwickelten Projekt neqo, das eine Client-Implementierung für das Protokoll QUIC bereitstellt. Server Die Codekomponenten zur Unterstützung von HTTP/3 und QUIC sind in Rust geschrieben. Zur Steuerung der Aktivierung von HTTP/3 gibt es in about:config die Option „network.http.http3.enabled“. Auch in Client-Software ist die experimentelle Unterstützung von HTTP/3 bereits in Chrome und curl hinzugefügt worden, während sie Server in nginx verfügbar ist, sowohl als nginx-Modul als auch in Form eines Testservers von Cloudflare. Mehrere Testwebseiten wurden eingerichtet, um die Funktionalität von HTTP/3-Clients zu überprüfen.
Das HTTP/3-Protokoll befindet sich derzeit in der Entwurfsphase und ist noch nicht endgültig in der IETF standardisiert. HTTP/3 definiert die Verwendung des QUIC-Protokolls als Transport für HTTP/2. Das QUIC-Protokoll (Quick UDP Internet Connections) wird seit 2013 von Google als Alternative zur Kombination von TCP+TLS für das Web entwickelt. Es löst Probleme mit langen Verbindungsaufbauzeiten und der Aushandlung von Verbindungen in TCP und beseitigt Verzögerungen bei Paketverlusten während der Datenübertragung. QUIC ist eine Erweiterung des UDP-Protokolls, die das Multiplexing mehrerer Verbindungen unterstützt und Verschlüsselungsmethoden bietet, die TLS/SSL entsprechen. Während der Entwicklung des Standards in der IETF wurden Änderungen am Protokoll vorgenommen, was zur Entstehung von zwei parallel existierenden Zweigen führte, einem für HTTP/3 und einem von Google unterstützten (Chrome unterstützt beide Varianten).
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;
- Es ermöglicht, eine Verbindung sofort herzustellen (0-RTT, in etwa 75 % der Fälle können Daten sofort nach dem Senden des Verbindungsaufbaupakets übertragen werden) und sorgt für minimale Verzögerungen zwischen dem Senden einer Anfrage und dem Erhalten einer Antwort (RTT, Round Trip Time);
- 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.
- Deutliche Leistungs- und Bandbreitensteigerung im Vergleich zu TCP. Für Video-Streaming-Dienste wie YouTube hat die Anwendung von QUIC eine Reduzierung der Pufferoperationen beim Ansehen von Videos um 30 % gezeigt.
Quelle: opennet.ru
