Die nächtlichen Builds von Firefox unterstützen HTTP/3

In Nachtbuilds Firefox, das die Grundlage für die Veröffentlichung von Firefox 72 bildet, die für den 7. Januar geplant ist, hinzugefügt unterstützt das Protokoll HTTP/3. Standardmäßig ist HTTP/3 deaktiviert und erfordert die Aktivierung der Option „network.http.http3.enabled“ in about:config.

Die Unterstützung von HTTP/3 in Firefox basiert auf einem von Mozilla entwickelten Projekt neqo, das eine Implementierung von Client und Server für das Protokoll QUIC bereitstellt. Der Code der Komponenten zur Unterstützung von HTTP/3 und QUIC ist in Rust geschrieben.
Die experimentelle Unterstützung von HTTP/3 ist auch bereits in hinzugefügt Chrome und curl verfügbar, und für Server ist sie in Form von eines Moduls für nginx und einem Testserver basierend auf der Bibliothek quiche (eine Umsetzung QUIC und HTTP/3 in Rust von Cloudflare). Um die Funktionalität von HTTP/3-Clients zu überprüfen, wurden mehrere Testseiten ins Leben gerufen, von denen die meisten bisher nicht korrekt in Firefox angezeigt werden können (HTTP/3 befindet sich im Entwurfsspezifikationsstadium und ist noch nicht endgültig standardisiert).

Wir erinnern daran, dass HTTP/3 die Verwendung des QUIC-Protokolls als Transport für HTTP/2 standardisiert. Das Protokoll QUIC (Quick UDP Internet Connections) wird seit 2013 von Google als Alternative zu TCP+TLS für das Web entwickelt. Es adressiert die Probleme langer Verbindungsaufbauzeiten und -aushandlungen in TCP und beseitigt Verzögerungen, die durch Paketverluste während der Datenübertragung entstehen. QUIC ist eine Erweiterung des UDP-Protokolls, das die Multiplexierung mehrerer Verbindungen unterstützt und verschlüsselungsverfahren bietet, die TLS/SSL entsprechen.

Haupt Eigenschaften 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);
• Die Nichtverwendung derselben Sequenznummer bei der Wiederübertragung von Paketen vermeidet Zweideutigkeiten bei der Bestimmung empfangener Pakete und beseitigt Zeitüberschreitungen.
• 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.
• Deutlich der Leistungszuwachs verbessert sich die Leistung und Bandbreite im Vergleich zu TCP. Bei Video-Diensten wie YouTube zeigte die Verwendung von QUIC eine Reduzierung der Pufferungsoperationen beim Anschauen von Videos um 30%.

Quelle: opennet.ru