{"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 \u2013 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 \u00fcber UDP, das alle Funktionen von TCP, TLS und HTTP\/2 unterst\u00fctzt und die meisten ihrer Probleme l\u00f6st. Oft wird es als neues oder \u201eexperimentelles\u201c Protokoll bezeichnet, aber es hat die experimentelle Phase l\u00e4ngst hinter sich: Die Entwicklung l\u00e4uft seit \u00fcber 7 Jahren. In dieser Zeit wurde das Protokoll zwar nicht zum Standard, hat jedoch dennoch weite Verbreitung gefunden. Zum Beispiel nutzen Giganten wie Google und Facebook QUIC, um den Datenverkehr zu beschleunigen und Verz\u00f6gerungen in Mobilfunknetzen zu reduzieren, und die IETF k\u00fcndigte ihren Fork des Protokolls als Grundlage f\u00fcr den Standard HTTP\/3 an (w\u00e4hrend HTTP\/2 nur 44,8%<\/a><\/noindex> der Websites verwendet).<\/a><\/noindex><\/p>\n

Konzept<\/h2>\n

\nQUIC wurde als Ersatz f\u00fcr das veraltete TCP entwickelt, das urspr\u00fcnglich f\u00fcr Kabelnetze mit niedrigem Verlustanteil optimiert war. TCP liefert Pakete in der richtigen Reihenfolge, wodurch bei Verlust eines Pakets die gesamte Warteschlange zum Stillstand kommt (head-of-line blocking<\/a><\/noindex>), was sich negativ auf die Qualit\u00e4t und Stabilit\u00e4t der Verbindung auswirkt. Um massiven Paketverlusten entgegenzuwirken, verwenden Mobilfunknetze gro\u00dfe Pufferspeicher, was seinerseits zu \u00dcberfl\u00fcssigkeit und einer falschen negativen Reaktion des Protokolls f\u00fchrt (Bufferbloat<\/a><\/noindex>). Dar\u00fcber hinaus ben\u00f6tigt TCP erheblich mehr Zeit, um eine Verbindung herzustellen: SYN\/ACK- und TLS-Anfragen laufen separat und erfordern drei Roundtrips anstelle von einem, 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, und es ist nicht einfacher, diesen Datenverkehr zu entschl\u00fcsseln, als wenn er \u00fcber HTTPS ginge. Dar\u00fcber hinaus ist QUIC auf Anwendungsebene implementiert, da eine vollst\u00e4ndige Ersetzung des TCP-Stacks eine Ewigkeit<\/i>.<\/p>\n

dauern w\u00fcrde. Trotz der Unterst\u00fctzung von Multiplexing in HTTP\/2 bleibt das Problem des head-of-line blocking aufgrund der Notwendigkeit, Pakete in der richtigen Reihenfolge zu liefern, bestehen. QUIC ist \u00fcber UDP implementiert, wodurch es grunds\u00e4tzlich keine Blockierungen gibt, und um sicherzustellen, dass Pakete nicht unwiderruflich verloren gehen, werden sie nummeriert und k\u00f6nnen Teile von \u201eNachbarn\u201c enthalten, um Redundanz zu gew\u00e4hrleisten. Au\u00dferdem unterteilt QUIC die monolithische Warteschlange in mehrere Streams f\u00fcr unterschiedliche Anfragearten innerhalb einer Verbindung. Somit k\u00f6nnen bei einem Paketverlust Probleme nur bei einer Warteschlange auftreten (zum Beispiel beim \u00dcbertragen einer bestimmten Datei):<\/p>\n

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

Verwendung <\/h2>\n

\nUrspr\u00fcnglich wurde QUIC intern bei Google entwickelt und war stark auf den Einsatz innerhalb des Unternehmens ausgerichtet. Im Jahr 2013 wurde es zur Standardisierung an die IETF \u00fcbergeben (die bis heute andauert), und jetzt kann jeder an der Entwicklung des Protokolls teilnehmen, indem er das vorschl\u00e4gt, was ihm fehlt. Die IETF-Arbeitsgruppe organisiert j\u00e4hrlich Treffen, in denen neue Standards festgelegt und neue Entwicklungen diskutiert werden. Diese QUIC-Implementierung gilt als die Hauptimplementierung und darauf basiert die Zertifizierung des HTTP\/3-Standards.<\/p>\n

Bisher ist die Rede von einer Einf\u00fchrung von HTTP\/3 als Hauptprotokoll noch nicht aktueller, da es noch nicht abgeschlossen ist und kaum unterst\u00fctzt wird:<\/p>\n

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

\n

Kommentar von Uber zur Einf\u00fchrung von QUIC<\/i><\/h3>\n

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

Zun\u00e4chst haben wir Cronet in unsere Android-Anwendungen integriert, um Unterst\u00fctzung f\u00fcr QUIC hinzuzuf\u00fcgen. Die Integration wurde so vorgenommen, dass die Migrationskosten minimiert werden. Anstatt den alten Netzwerk-Stack, der die Bibliothek OkHttp<\/a><\/noindex>, vollst\u00e4ndig zu ersetzen, haben wir Cronet UNTER dem OkHttp-API-Framework integriert. Durch diese Vorgehensweise haben wir \u00c4nderungen an unseren Netzwerkaufrufen (die verwenden Retrofit<\/a><\/noindex>) auf der API-Ebene vermieden.<\/p>\n

\u00c4hnlich wie bei Android-Ger\u00e4ten haben wir Cronet in die Uber-Anwendungen auf iOS integriert, indem wir den HTTP-Verkehr \u00fcber die Netzwerke API<\/a><\/noindex>, unter Verwendung von NSURLProtocol<\/a><\/noindex>abgefangen haben. Diese Abstraktion, die von iOS Foundation bereitgestellt wird, verarbeitet protokollspezifische URL-Daten und gew\u00e4hrleistet, dass wir Cronet in unsere iOS-Anwendungen ohne wesentliche Migrationskosten integrieren k\u00f6nnen.<\/p><\/blockquote>\n

entnommen von dieser \u00dcbersetzung<\/a><\/noindex> des Uber-Artikels<\/i><\/p>\n

Auf der Backend-Seite erfingen sie QUIC-Verbindungen \u00fcber Google Cloud lb, die das Protokoll<\/a><\/noindex> seit Mitte 2018 unterst\u00fctzt.<\/p>\n

Es \u00fcberrascht nicht, dass Google Cloud hervorragend mit einem Protokoll funktioniert, das von Google entwickelt wurde, aber welche Alternativen gibt es?<\/p>\n

Nginx<\/h3>\n

\nVor nicht allzu langer Zeit versuchte CloudFlare nginx (das standardm\u00e4\u00dfig kein HTTP\/3 unterst\u00fctzt) mit ihrem Tool Quiche zu kombinieren. Die Implementierung ist als einzelnes .patch-Datei verf\u00fcgbar, die mit einem Tutorial zur Installation geliefert wird:<\/a><\/noindex> 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<\/p>\n

Hier k\u00f6nnen bei Bedarf eigene Module hinzugef\u00fcgt werden<\/code><\/pre>\n
\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<\/p>\n
Es bleibt nur noch, die Unterst\u00fctzung f\u00fcr HTTP\/3 zu aktivieren<\/code><\/pre>\n
\nevents {\n    worker_connections  1024;\n}\n\nhttp {\n    server {\n        # QUIC und HTTP\/3 aktivieren.\n        listen 443 quic reuseport;\n\n        # HTTP\/2 aktivieren (optional).\n        listen 443 ssl http2;\n\n        ssl_certificate      cert.crt;\n        ssl_certificate_key  cert.key;\n\n        # Alle TLS-Versionen aktivieren (TLSv1.3 ist f\u00fcr QUIC erforderlich).\n        ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;\n\n        # Anfrage-Pufferung wird derzeit f\u00fcr HTTP\/3 nicht unterst\u00fctzt.\n        proxy_request_buffering off;\n\n        # Alt-Svc-Header hinzuf\u00fcgen, um HTTP\/3 auszuhandeln.\n        add_header alt-svc 'h3-27=\":443\"; ma=86400';\n    }\n}<\/p>\n
events {\n    worker_connections  1024;\n}\n\nhttp {\n    server {\n        # QUIC und HTTP\/3 aktivieren.\n        listen 443 quic reuseport;\n\n        # HTTP\/2 aktivieren (optional).\n        listen 443 ssl http2;\n\n        ssl_certificate      cert.crt;\n        ssl_certificate_key  cert.key;\n\n        # Alle TLS-Versionen aktivieren (TLSv1.3 ist f\u00fcr QUIC erforderlich).\n        ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;\n\n        # Anfragepufferung wird f\u00fcr HTTP\/3 derzeit nicht unterst\u00fctzt.\n        proxy_request_buffering off;\n\n        # Alt-Svc-Header hinzuf\u00fcgen, um HTTP\/3 auszuhandeln.\n        add_header alt-svc 'h3-27=\"443\"; ma=86400';\n    }\n}<\/code><\/pre>\n
\nnehmen und es mit dem Flag Chrome Canary<\/a><\/noindex> --enable-quic , sich mit seinem Server oder beispielsweise der Website quic.rocks verbinden und den Verbindungstyp in den Entwicklertools ansehen:<\/code>Statt HTTP\/3 wird angezeigt
\n\"HTTP
\nhttp2+quic\/99 , aber das ist im Grunde dasselbe.<\/code>Andere Technologien<\/p>\n
Andere Technologien<\/h3>\n
<\/p>\n