In den Nachbauversionen von Firefox sowie in der Beta-Version ist die Unterstützung für das HTTP/3-Protokoll standardmäßig aktiviert. In der stabilen Version ist die Aktivierung von HTTP/3 für die Veröffentlichung von Firefox 88, die für den 20. April geplant ist, vorgesehen.
Die Unterstützung von HTTP/3 in Firefox basiert auf dem von Mozilla entwickelten Projekt neqo, das eine Implementierung des Clients und Server für das QUIC-Protokoll bereitstellt. Der Code der Komponenten zur Unterstützung von HTTP/3 und QUIC ist in Rust geschrieben. Zur Verwaltung der Aktivierung von HTTP/3 gibt es in about:config die Option „network.http.http3.enabled“. Die experimentelle Unterstützung von HTTP/3 ist auch bereits in Chrome und curl integriert, und für Server ist sie verfügbar in nginx sowie in Form eines nginx-Moduls und eines Testservers von Cloudflare. Zur Überprüfung der Funktion von HTTP/3-Clients wurden mehrere Test-Websites ins Leben gerufen.
Das HTTP/3-Protokoll befindet sich derzeit noch in der Entwurfsphase und ist im IETF noch nicht vollständig 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 zu TCP+TLS für das Web entwickelt, um Probleme mit der langen Verbindungsherstellung und -aushandlung in TCP zu lösen und Verzögerungen bei Paketverlusten während der Datenübertragung zu vermeiden. QUIC ist ein Overlay über dem UDP-Protokoll, das die Multiplexierung mehrerer Verbindungen unterstützt und Verschlüsselungsmethoden bereitstellt, die mit TLS/SSL vergleichbar sind. Im Verlauf der Entwicklung des Standards im IETF wurden Änderungen am Protokoll vorgenommen, was zur Entstehung von zwei parallel existierenden Zweigen führte, einer für HTTP/3 und der andere von Google unterstützt (Chrome unterstützt beide Varianten).
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, eine Verbindung sofort aufzubauen (0-RTT, in etwa 75 % der Fälle können Daten sofort nach dem Senden des Verbindungsaufbaus übertragen werden) und minimale Verzögerungen zwischen der Anfrage und dem Erhalt einer 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 Anstieg der Leistung und Bandbreite im Vergleich zu TCP. Für Video-Streaming-Dienste wie YouTube hat die Verwendung von QUIC die Anzahl der Pufferungsvorgänge beim Ansehen von Videos um 30 % reduziert.
Quelle: opennet.ru
