Chrome fügt experimentelle Unterstützung für das HTTP/3-Protokoll hinzu

Zu experimentellen Builds Chrome Canary hinzugefügt Unterstützung für das HTTP/3-Protokoll, das ein Add-on implementiert, damit HTTP über das QUIC-Protokoll funktionieren kann. Das QUIC-Protokoll selbst wurde vor fünf Jahren zum Browser hinzugefügt und wird seitdem zur Optimierung der Arbeit mit Google-Diensten verwendet. Gleichzeitig unterschied sich die in Chrome verwendete QUIC-Version von Google in einigen Details von der Version von spezifiziert IETF, aber jetzt sind die Implementierungen synchronisiert.

HTTP/3 standardisiert die Verwendung von QUIC als Transport für HTTP/2. So aktivieren Sie die HTTP/3- und QUIC-Option von 23 Entwürfe Die IETF-Spezifikationen erfordern, dass Chrome mit den Optionen „-enable-quic -quic-version=h3-23“ und dann beim Öffnen der Testseite gestartet wird Quick.rocks:4433 Im Netzwerkinspektionsmodus in Entwicklertools wird die HTTP/3-Aktivität als „http/2+quic/99“ angezeigt.

Denken Sie daran, dass das Protokoll QUIC (Quick UDP Internet Connections) wurde von Google seit 2013 als Alternative zur TCP+TLS-Kombination für das Web entwickelt und löst Probleme mit langen Einrichtungs- und Aushandlungszeiten für Verbindungen in TCP und eliminiert Verzögerungen, wenn Pakete während der Datenübertragung verloren gehen. QUIC ist eine Erweiterung des UDP-Protokolls, das das Multiplexen mehrerer Verbindungen unterstützt und Verschlüsselungsmethoden bereitstellt, die TLS/SSL entsprechen. Das betreffende Protokoll ist bereits in die Google-Server-Infrastruktur integriert und Teil von Chrome. ist geplant zur Aufnahme in Firefox und wird aktiv zur Bearbeitung von Clientanfragen auf Google-Servern verwendet.

Haupt- eigenschaften SCHNELL:

  • 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;
  • Bei der erneuten Übertragung eines Pakets wird nicht dieselbe Sequenznummer verwendet, 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.
  • Wahrnehmbar Wachstum Leistung und Durchsatz im Vergleich zu TCP. Bei Videodiensten wie YouTube reduziert QUIC nachweislich die Umpufferungsvorgänge beim Ansehen von Videos um 30 %.

Source: opennet.ru

Kommentar hinzufügen