{"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\/nl\/blog\/administrirovanie\/http-po-udp-ispolzuem-s-polzoj-protokol-quic","title":{"rendered":"HTTP over UDP - nutz het QUIC-protocol optimaal","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"HTTP
\n
\nQUIC (Quick UDP Internet Connections) is een protocol bovenop UDP, dat alle mogelijkheden van TCP, TLS en HTTP\/2 ondersteunt en de meeste van hun problemen oplost. Het wordt vaak een nieuw of 'experimenteel' protocol genoemd, maar is al geruime tijd geen experimentele fase meer: de ontwikkeling is al meer dan 7 jaar aan de gang. In die tijd is het protocol nog geen standaard geworden, maar heeft het wel brede verspreiding gevonden. Zo gebruiken giganten als Google en Facebook QUIC om de datastroom te versnellen en vertraging in mobiele netwerken te verminderen, en heeft de IETF zijn fork van het protocol aangekondigd als basis voor de standaard HTTP\/3 (terwijl HTTP\/2 slechts 44.8%<\/a><\/noindex> van de sites gebruikt).<\/a><\/noindex><\/p>\n

Concept<\/h2>\n

\nQUIC is ontwikkeld als vervanging voor het verouderde TCP, dat oorspronkelijk was geoptimaliseerd voor bedrade netwerken met een laag verliespercentage. TCP levert pakketten op volgorde, wat betekent dat bij het verlies van \u00e9\u00e9n pakket de hele wachtrij stagneert (head-of-line blocking<\/a><\/noindex>), wat een negatieve invloed heeft op de kwaliteit en stabiliteit van de verbinding. Om massaal verlies te voorkomen, gebruiken mobiele netwerken grote buffers, wat op zijn beurt leidt tot overbodigheid en een false negative-reactie van het protocol (bufferbloat<\/a><\/noindex>). Bovendien kost TCP veel tijd om een verbinding tot stand te brengen: SYN\/ACK en TLS-verzoeken worden afzonderlijk verzonden, wat drie roundtrips vereist in plaats van \u00e9\u00e9n, zoals QUIC doet.<\/p>\n

\"HTTP
\n
\nAangezien QUIC zowel een vervanging van TCP als een implementatie van TLS 1.3 is, zijn alle verbindingen altijd versleuteld, en het decrypten van zo'n verkeer is niet eenvoudiger dan wanneer het via HTTPS zou verlopen. Daarnaast is QUIC op applicatieniveau ge\u00efmplementeerd, terwijl het een volledige vervanging van de TCP-stack enorm veel tijd zou kosten. Ewigigheid<\/i>.<\/p>\n

Ondanks de ondersteuning van multiplexing in HTTP\/2, blijft het probleem van head-of-line blocking bestaan door de noodzaak om pakketten in volgorde te leveren. QUIC is bovenop UDP ge\u00efmplementeerd, waardoor er in principe geen blokkades zijn; om ervoor te zorgen dat pakketten niet onherroepelijk verloren gaan, worden ze genummerd en kunnen ze onderdelen van \"buren\" bevatten, wat zorgt voor redundantie. Bovendien verdeelt QUIC de monolithische wachtrij in verschillende stromen voor verschillende typen verzoeken binnen \u00e9\u00e9n verbinding. Bij het verlies van een pakket kunnen problemen dus alleen bij \u00e9\u00e9n wachtrij optreden (bijvoorbeeld voor de overdracht van een specifiek bestand):<\/p>\n

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

Gebruik van <\/h2>\n

\nQUIC werd oorspronkelijk binnen Google ontwikkeld en was in veel opzichten gericht op gebruik binnen het bedrijf. In 2013 is het overgedragen aan de IETF voor standaardisatie (die nog steeds doorgaat), en nu kan iedereen deelnemen aan de ontwikkeling van het protocol door het aan te vullen met wat hij mist. De IETF-werkgroep organiseert jaarlijks bijeenkomsten waarin de nieuwe standaard wordt goedgekeurd en de innovaties worden besproken. Deze implementatie van QUIC wordt als de belangrijkste beschouwd en op basis daarvan wordt de standaard HTTP\/3 gecertificeerd.<\/p>\n

Momenteel is er nog geen sprake van HTTP\/3 als het belangrijkste protocol, omdat het nog niet voltooid is en bijna niet wordt ondersteund:<\/p>\n

\"HTTP
\n
\nMaar QUIC kan worden ge\u00efmplementeerd als transport tussen de applicatie en de server, wat met succes is gedaan bij Uber:<\/p>\n

\n

Uber's opmerking over de implementatie van QUIC<\/i><\/h3>\n

\nOm QUIC succesvol te integreren en de prestaties van de applicatie onder slechte verbindingen te verbeteren, hebben we de oude stack (HTTP\/2 boven TLS\/TCP) vervangen door het QUIC-protocol. We hebben de netwerklibrary Cronet<\/a><\/noindex> uit Chromium Projects<\/a><\/noindex>, die de originele, Google-versie van het protocol \u2013 gQUIC \u2013 bevat. Deze implementatie wordt ook voortdurend verbeterd om de laatste specificatie van de IETF te volgen.<\/p>\n

Eerst hebben we Cronet ge\u00efntegreerd in onze Android-applicaties om ondersteuning voor QUIC toe te voegen. De integratie is zo uitgevoerd dat de migratiekosten tot een minimum worden beperkt. In plaats van de oude netwerklayer volledig te vervangen, die gebruik maakte van de library OkHttp<\/a><\/noindex>, hebben we Cronet ge\u00efntegreerd ONDER de OkHttp API-framework. Door de integratie op deze manier uit te voeren, hebben we wijzigingen in onze netwerkoproepen (die gebruik maken van Retrofit<\/a><\/noindex>) op API-niveau vermeden.<\/p>\n

Net als bij de aanpak voor Android-apparaten hebben we Cronet ge\u00efmplementeerd in de Uber-apps voor iOS, waarbij we HTTP-verkeer onderscheppen vanuit de netwerken API<\/a><\/noindex>, met gebruik van NSURLProtocol<\/a><\/noindex>. Deze abstractie, geboden door de iOS Foundation, verwerkt protocol-specifieke URL-gegevens en zorgt ervoor dat we Cronet in onze iOS-applicaties kunnen integreren zonder aanzienlijke migratiekosten.<\/p><\/blockquote>\n

genomen uit deze vertaling<\/a><\/noindex> van het Uber-artikel<\/i><\/p>\n

Aan de achterkant vingen ze QUIC-verbindingen op via Google Cloud lb, die het protocol ondersteunt<\/a><\/noindex> sinds midden 2018.<\/p>\n

Het is dan ook geen verrassing dat Google Cloud uitstekend werkt met een protocol dat door Google is ontwikkeld, maar welke alternatieven zijn er?<\/p>\n

Nginx<\/h3>\n

\nNiet zo lang geleden heeft CloudFlare geprobeerd te crossbreeden<\/a><\/noindex> nginx (dat standaard geen HTTP\/3 ondersteunt) met zijn Quiche-tool. De implementatie is beschikbaar als \u00e9\u00e9n enkele .patch-bestand, met een installatiehandleiding erbij:<\/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 kunnen indien nodig uw eigen modules worden toegevoegd<\/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
\nHet enige wat overblijft, is de ondersteuning voor HTTP\/3 in te schakelen<\/p>\n
events {\n    worker_connections  1024;\n}\n\nhttp {\n    server {\n        # Schakel QUIC en HTTP\/3 in.\n        listen 443 quic reuseport;\n\n        # Schakel HTTP\/2 in (optioneel).\n        listen 443 ssl http2;\n\n        ssl_certificate      cert.crt;\n        ssl_certificate_key  cert.key;\n\n        # Schakel alle TLS-versies in (TLSv1.3 is vereist voor QUIC).\n        ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;\n\n        # Verzoekbuffering wordt momenteel niet ondersteund voor HTTP\/3.\n        proxy_request_buffering off;\n\n        # Voeg Alt-Svc-header toe om HTTP\/3 te onderhandelen.\n        add_header alt-svc 'h3-27=\"443\"; ma=86400';\n    }\n}<\/code><\/pre>\n
\nIn reguliere browsers is verbinding maken via HTTP\/3 nog niet mogelijk, maar u kunt Chrome Canary<\/a><\/noindex> nemen en het starten met de vlag --enable-quic<\/code>, verbinding maken met uw server of bijvoorbeeld met de website quic.rocks en het type verbinding bekijken in de Developer Tools:
\n\"HTTP
\nIn plaats van HTTP\/3 staat er http2+quic\/99<\/code>, maar dat is in feite hetzelfde.<\/p>\n
Andere technologie\u00ebn<\/h3>\n
<\/p>\n