{"id":81847,"date":"2020-05-17T01:42:34","date_gmt":"2020-05-16T23:42:34","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/http-po-udp-ispolzuem-s-polzoj-protokol-quic"},"modified":"2020-05-17T01:42:34","modified_gmt":"2020-05-16T23:42:34","slug":"http-po-udp-ispolzuem-s-polzoj-protokol-quic","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/http-po-udp-ispolzuem-s-polzoj-protokol-quic","title":{"rendered":"HTTP \u00fcber UDP \u2014 nutzen wir das QUIC-Protokoll sinnvoll","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"HTTP
\n
\nQUIC (Quick UDP Internet Connections) ist ein Protokoll, das auf UDP basiert und alle Funktionen von TCP, TLS und HTTP\/2 unterst\u00fctzt, w\u00e4hrend es die meisten ihrer Probleme l\u00f6st. Oft wird es als neues oder \"experimentelles\" Protokoll bezeichnet, hat jedoch bereits seit \u00fcber 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\u00dferdem hat die IETF seinen Fork des Protokolls als Grundlage f\u00fcr den Standard HTTP\/3 erkl\u00e4rt (w\u00e4hrend HTTP\/2 nur 44,8 %<\/a><\/noindex> der Webseiten nutzt).<\/a><\/noindex><\/p>\n

Die Idee<\/h2>\n

\nQUIC wurde als Ersatz f\u00fcr das veraltete TCP entwickelt, das urspr\u00fcnglich f\u00fcr 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<\/a><\/noindex>), was sich negativ auf die Qualit\u00e4t und Stabilit\u00e4t der Verbindung auswirkt. Um massiven Paketverlusten vorzubeugen, verwenden Mobilfunknetze gro\u00dfe Puffer, was wiederum zu \u00dcberlastungen und falschen negativen Reaktionen des Protokolls f\u00fchrt (bufferbloat<\/a><\/noindex>). Dar\u00fcber hinaus ben\u00f6tigt TCP viel Zeit f\u00fcr die Verbindungsherstellung: SYN\/ACK- und TLS-Anfragen erfolgen separat, was drei Roundtrips anstelle von einem erfordert, wie es QUIC tut.<\/p>\n

\"HTTP
\n
\nDa QUIC sowohl TCP ersetzt als auch TLS 1.3 implementiert, sind alle Verbindungen immer verschl\u00fcsselt. Es ist nicht einfacher, solchen Datenverkehr zu entschl\u00fcsseln, als wenn er \u00fcber HTTPS l\u00e4uft. Au\u00dferdem ist QUIC auf Anwendungsebene implementiert, was eine vollst\u00e4ndige Ersetzung des TCP-Stacks erfordern w\u00fcrde. Ewigkeit<\/i>.<\/p>\n

Trotz der Unterst\u00fctzung 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 \u00fcber UDP implementiert, sodass es im Grundsatz keine Blockierungen gibt. Um sicherzustellen, dass Pakete nicht endg\u00fcltig verloren gehen, werden sie nummeriert und k\u00f6nnen Teile von \u201eNachbarn\u201c enthalten, was Redundanz bietet. Zudem zerlegt QUIC die monolithische Warteschlange in mehrere Str\u00f6me f\u00fcr verschiedene Arten von Anfragen innerhalb einer Verbindung. So k\u00f6nnen bei Paketverlust Probleme nur in einer Warteschlange entstehen (z. B. beim \u00dcbertragen einer bestimmten Datei):<\/p>\n

\"HTTP
\n<\/p>\n

Nutzung <\/h2>\n

\nUrspr\u00fcnglich wurde QUIC von Google entwickelt und war vor allem f\u00fcr den internen Gebrauch innerhalb des Unternehmens optimiert. Im Jahr 2013 wurde es an die IETF zur Standardisierung \u00fcbergeben (die nach wie vor erfolgt), und jetzt kann jeder zur Weiterentwicklung des Protokolls beitragen, indem er seine eigenen Bed\u00fcrfnisse einbringt. Die IETF-Arbeitsgruppe organisiert j\u00e4hrlich 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.<\/p>\n

Derzeit wird nicht dar\u00fcber gesprochen, HTTP\/3 als Hauptprotokoll einzuf\u00fchren, da es noch nicht abgeschlossen ist und kaum Unterst\u00fctzung findet:<\/p>\n

\"HTTP
\n
\nQUIC kann jedoch als Transport zwischen Anwendung und Server implementiert werden, was bei Uber erfolgreich umgesetzt wurde:<\/p>\n

\n

Ubers Kommentar zur Implementierung von QUIC<\/i><\/h3>\n

\nUm QUIC erfolgreich zu integrieren und die Leistung der Anwendung bei schlechten Verbindungsbedingungen zu verbessern, haben wir den alten Stack (HTTP\/2 \u00fcber TLS\/TCP) durch das QUIC-Protokoll ersetzt. Wir haben die Netzwerkbibliothek Cronet<\/a><\/noindex> von Chromium-Projekte<\/a><\/noindex>, die die originale Google-Version des Protokolls \u2013 gQUIC \u2013 enth\u00e4lt. Diese Implementierung wird st\u00e4ndig verbessert, um der neuesten IETF-Spezifikation zu folgen.<\/p>\n

Zuerst haben wir Cronet in unsere Android-Anwendungen integriert, um QUIC-Unterst\u00fctzung hinzuzuf\u00fcgen. Die Integration wurde so umgesetzt, dass die Migrationskosten minimiert werden. OkHttp<\/a><\/noindex>, haben wir Cronet UNTER dem OkHttp API-Rahmen integriert. Durch diese Art der Integration haben wir \u00c4nderungen an unseren Netzwerkaufrufen (die Retrofit<\/a><\/noindex>) auf API-Ebene vermieden.<\/p>\n

\u00c4hnlich wie bei Android-Ger\u00e4ten haben wir Cronet in die Uber-Anwendungen f\u00fcr iOS integriert, indem wir HTTP-Verkehr \u00fcber Netzwerke abgefangen haben, API<\/a><\/noindex>, unter Verwendung von NSURLProtocol<\/a><\/noindex>. 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\u00f6nnen, ohne erhebliche Migrationskosten.<\/p><\/blockquote>\n

stammt aus dieser \u00dcbersetzung<\/a><\/noindex> des Uber-Artikels.<\/i><\/p>\n

Im Backend haben sie QUIC-Verbindungen \u00fcber Google Cloud lb erfasst, die das Protokoll<\/a><\/noindex> seit Mitte 2018 unterst\u00fctzt.<\/p>\n

Es ist nicht verwunderlich, dass Google Cloud hervorragend mit einem von Google entwickelten Protokoll funktioniert, aber welche Alternativen gibt es?<\/p>\n

Nginx<\/h3>\n

\nVor nicht allzu langer Zeit hat CloudFlare versucht,<\/a><\/noindex> nginx (das standardm\u00e4\u00dfig kein HTTP\/3 unterst\u00fctzt) mit seinem Tool Quiche zu verbinden. Die Implementierung ist als einzelne .patch-Datei verf\u00fcgbar, zu der eine Installationsanleitung geh\u00f6rt:<\/p>\n

curl -O https:\/\/nginx.org\/download\/nginx-1.16.1.tar.gz\ntar xvzf nginx-1.16.1.tar.gz\ngit clone --recursive https:\/\/github.com\/cloudflare\/quiche\ncd nginx-1.16.1\npatch -p01 < ..\/quiche\/extras\/nginx\/nginx-1.16.patch<\/code><\/pre>\n
\nHier k\u00f6nnen bei Bedarf eigene Module hinzugef\u00fcgt werden.<\/p>\n
.\/configure                          \t\n   \t--prefix=$PWD                       \t\n   \t--with-http_ssl_module              \t\n   \t--with-http_v2_module               \t\n   \t--with-http_v3_module               \t\n   \t--with-openssl=..\/quiche\/deps\/boringssl \n   \t--with-quiche=..\/quiche\n make<\/code><\/pre>\n
\nEs bleibt nur noch, die Unterst\u00fctzung f\u00fcr HTTP\/3 zu aktivieren.<\/p>\n
events {\n    worker_connections  1024;\n}\n\nhttp {\n    server {\n        # Aktivieren Sie QUIC und HTTP\/3.\n        listen 443 quic reuseport;\n\n        # Aktivieren Sie HTTP\/2 (optional).\n        listen 443 ssl http2;\n\n        ssl_certificate      cert.crt;\n        ssl_certificate_key  cert.key;\n\n        # Aktivieren Sie alle TLS-Versionen (TLSv1.3 ist f\u00fcr QUIC erforderlich).\n        ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;\n\n        # Anfragepufferung wird derzeit f\u00fcr HTTP\/3 nicht unterst\u00fctzt.\n        proxy_request_buffering off;\n\n        # F\u00fcgen Sie den Alt-Svc-Header hinzu, um HTTP\/3 auszuhandeln.\n        add_header alt-svc 'h3-27=":443"; ma=86400';\n    }\n}<\/code><\/pre>\n
\nIn herk\u00f6mmlichen Browsern ist eine Verbindung \u00fcber HTTP\/3 derzeit nicht m\u00f6glich, aber man kann Chrome Canary<\/a><\/noindex> und starten Sie es mit der Flagge --enable-quic<\/code>, um sich mit Ihrem Server oder beispielsweise der Seite quic.rocks zu verbinden und den Verbindungstyp in den Entwicklertools zu \u00fcberpr\u00fcfen:
\n\"HTTP
\nStatt HTTP\/3 wird angezeigt http2+quic\/99<\/code>, aber im Wesentlichen ist es das Gleiche.<\/p>\n
Andere Technologien<\/h3>\n
<\/p>\n