HTTP über UDP — nutzen wir das QUIC-Protokoll sinnvoll

QUIC (Quick UDP Internet Connections) ist ein Protokoll, das auf UDP basiert und alle Funktionen von TCP, TLS und HTTP/2 unterstützt, während es die meisten ihrer Probleme löst. Oft wird es als neues oder "experimentelles" Protokoll bezeichnet, hat jedoch bereits seit über 7 Jahren Entwicklungsarbeit hinter sich. Obwohl es noch nicht zum Standard geworden ist, hat es sich bereits weit verbreitet. Beispielsweise verwenden Giganten wie Google und Facebook QUIC, um den Datenverkehr zu beschleunigen und die Latenz in Mobilfunknetzen zu verringern. Außerdem hat die IETF seinen Fork des Protokolls als Grundlage für den Standard HTTP/3 erklärt (während HTTP/2 nur 44,8 % der Webseiten nutzt).

Die Idee

QUIC wurde als Ersatz für das veraltete TCP entwickelt, das ursprünglich für kabelgebundene Netzwerke mit niedrigen Verlustquoten optimiert wurde. TCP liefert Pakete in der richtigen Reihenfolge, wodurch bei Verlust eines Pakets die gesamte Warteschlange blockiert wird (head-of-line blocking), was sich negativ auf die Qualität und Stabilität der Verbindung auswirkt. Um massiven Paketverlusten vorzubeugen, verwenden Mobilfunknetze große Puffer, was wiederum zu Überlastungen und falschen negativen Reaktionen des Protokolls führt (bufferbloat). Darüber hinaus benötigt TCP viel Zeit für den Verbindungsaufbau: SYN/ACK- und TLS-Anfragen laufen separat und erfordern drei Roundtrips statt einem, wie es QUIC macht.

Da QUIC sowohl TCP ersetzt als auch TLS 1.3 implementiert, sind alle Verbindungen immer verschlüsselt. Es ist nicht einfacher, solchen Datenverkehr zu entschlüsseln, als wenn er über HTTPS läuft. Außerdem ist QUIC auf Anwendungsebene implementiert, was eine vollständige Ersetzung des TCP-Stacks erfordern würde. Ewigkeit.

Trotz der Unterstützung von Multiplexing in HTTP/2 bleibt das Problem der Head-of-Line-Blocking aufgrund der Notwendigkeit, Pakete in der richtigen Reihenfolge zu liefern. QUIC wird über UDP implementiert, sodass es im Grundsatz keine Blockierungen gibt. Um sicherzustellen, dass Pakete nicht endgültig verloren gehen, werden sie nummeriert und können Teile von „Nachbarn“ enthalten, was Redundanz bietet. Zudem zerlegt QUIC die monolithische Warteschlange in mehrere Ströme für verschiedene Arten von Anfragen innerhalb einer Verbindung. So können bei Paketverlust Probleme nur in einer Warteschlange entstehen (z. B. beim Übertragen einer bestimmten Datei):

Nutzung

Ursprünglich wurde QUIC von Google entwickelt und war vor allem für den internen Gebrauch innerhalb des Unternehmens optimiert. Im Jahr 2013 wurde es an die IETF zur Standardisierung übergeben (die nach wie vor erfolgt), und jetzt kann jeder zur Weiterentwicklung des Protokolls beitragen, indem er seine eigenen Bedürfnisse einbringt. Die IETF-Arbeitsgruppe organisiert jährlich Treffen, in denen neue Standards verabschiedet und Neuerungen diskutiert werden. Diese QUIC-Implementierung gilt als die grundlegende, auf deren Basis der HTTP/3-Standard zertifiziert wird.

Derzeit wird nicht darüber gesprochen, HTTP/3 als Hauptprotokoll einzuführen, da es noch nicht abgeschlossen ist und kaum Unterstützung findet:

QUIC kann jedoch als Transport zwischen Anwendung und Server implementiert werden, was bei Uber erfolgreich umgesetzt wurde:

Ubers Kommentar zur Implementierung von QUIC

Um QUIC erfolgreich zu integrieren und die Leistung der Anwendung bei schlechten Verbindungsbedingungen zu verbessern, haben wir den alten Stack (HTTP/2 über TLS/TCP) durch das QUIC-Protokoll ersetzt. Wir haben die Netzwerkbibliothek Cronet von Chromium-Projekte, die die originale Google-Version des Protokolls – gQUIC – enthält. Diese Implementierung wird ständig verbessert, um der neuesten IETF-Spezifikation zu folgen.

Zuerst haben wir Cronet in unsere Android-Anwendungen integriert, um QUIC-Unterstützung hinzuzufügen. Die Integration wurde so umgesetzt, dass die Migrationskosten minimiert werden. OkHttp, haben wir Cronet UNTER dem OkHttp API-Rahmen integriert. Durch diese Art der Integration haben wir Änderungen an unseren Netzwerkaufrufen (die Retrofit) auf API-Ebene vermieden.

Ähnlich wie bei Android-Geräten haben wir Cronet in die Uber-Anwendungen für iOS integriert, indem wir HTTP-Verkehr über Netzwerke abgefangen haben, API, unter Verwendung von NSURLProtocol. Diese Abstraktion, die von der iOS Foundation bereitgestellt wird, verarbeitet protocollspezifische URL-Daten und stellt sicher, dass wir Cronet in unsere iOS-Anwendungen integrieren können, ohne erhebliche Migrationskosten.

stammt aus dieser Übersetzung des Uber-Artikels.

Im Backend haben sie QUIC-Verbindungen über Google Cloud lb erfasst, die das Protokoll seit Mitte 2018 unterstützt.

Es ist nicht verwunderlich, dass Google Cloud hervorragend mit einem von Google entwickelten Protokoll funktioniert, aber welche Alternativen gibt es?

Nginx

Vor nicht allzu langer Zeit hat CloudFlare versucht, nginx (das standardmäßig kein HTTP/3 unterstützt) mit seinem Tool Quiche zu verbinden. Die Implementierung ist als einzelne .patch-Datei verfügbar, zu der eine Installationsanleitung gehört:

curl -O https://nginx.org/download/nginx-1.16.1.tar.gz
tar xvzf nginx-1.16.1.tar.gz
git clone --recursive https://github.com/cloudflare/quiche
cd nginx-1.16.1
patch -p01 < ../quiche/extras/nginx/nginx-1.16.patch

Hier können bei Bedarf eigene Module hinzugefügt werden.

./configure                          	
   	--prefix=$PWD                       	
   	--with-http_ssl_module              	
   	--with-http_v2_module               	
   	--with-http_v3_module               	
   	--with-openssl=../quiche/deps/boringssl 
   	--with-quiche=../quiche
 make

Es bleibt nur noch, die Unterstützung für HTTP/3 zu aktivieren.

events {
    worker_connections  1024;
}

http {
    server {
        # QUIC und HTTP/3 aktivieren.
        listen 443 quic reuseport;

        # HTTP/2 aktivieren (optional).
        listen 443 ssl http2;

        ssl_certificate      cert.crt;
        ssl_certificate_key  cert.key;

        # Alle TLS-Versionen aktivieren (TLSv1.3 ist für QUIC erforderlich).
        ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;

        # Anforderungs-Pufferung wird derzeit nicht für HTTP/3 unterstützt.
        proxy_request_buffering off;

        # Alt-Svc-Header hinzufügen, um HTTP/3 auszuhandeln.
        add_header alt-svc 'h3-27=":443"; ma=86400';
    }
}

In herkömmlichen Browsern ist eine Verbindung über HTTP/3 derzeit nicht möglich, aber man kann Chrome Canary und starten Sie es mit der Flagge --enable-quic, um sich mit Ihrem Server oder beispielsweise der Seite quic.rocks zu verbinden und den Verbindungstyp in den Entwicklertools zu überprüfen:

Statt HTTP/3 wird angezeigt http2+quic/99, aber im Wesentlichen ist es das Gleiche.

Andere Technologien

• supporten ebenfalls QUIC LiteSpeed (die sich mit viel Pomp mit Facebook über HTTP/3 verbunden haben) und die progressive Caddy. Apache kann das bisher nicht, die Arbeiten laufen aber auf Hochtouren.
• Am 21. Januar wurde aktualisiert der Standardentwurf für WebRTC
• Vor wenigen Tagen hat Microsoft den Code seiner msquic-Implementierung veröffentlicht, bei der noch nicht alle Funktionen des IETF-Standards verfügbar sind, aber es ist bereits ein großer Durchbruch.

Fazit

Das Interesse an QUIC ist unbeständig, wächst jedoch. Es wird an der Standardisierung gearbeitet. Neue Implementierungen des Protokolls erscheinen quasi jeden Monat, und jährlich sind immer mehr Entwickler überzeugt, dass die Zukunft QUIC gehört. Sogar die Einbeziehung des Protokolls in zukünftige Versionen des TCP-Stacks ist möglich, was bedeutet, dass das gesamte Internet früher oder später auf stabilere und schnellere Verbindungen umschwenkt.

Sie können jetzt bereits QUIC-Interaktionen für Ihre Infrastruktur einrichten oder sogar an die Browser weitergeben – sie planen alle, das Protokoll zu unterstützen, und die traurige Statistik von caniuse wird erfreulicher.

Quelle: habr.com