{"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\/da\/blog\/administrirovanie\/http-po-udp-ispolzuem-s-polzoj-protokol-quic","title":{"rendered":"HTTP over UDP - lad os bruge QUIC-protokollen konstruktivt","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"HTTP
\n
\nQUIC (Quick UDP Internet Connections) er en protokol over UDP, der underst\u00f8tter alle funktioner fra TCP, TLS og HTTP\/2 og l\u00f8ser de fleste af deres problemer. Den kaldes ofte for en ny eller \"eksperimentel\" protokol, men den har l\u00e6nge oversteg eksperimentfasen: udviklingen har v\u00e6ret i gang i over 7 \u00e5r. I l\u00f8bet af denne tid er protokollen ikke blevet en standard, men har alligevel opn\u00e5et bred udbredelse. For eksempel bruger giganter som Google og Facebook QUIC til at accelerere trafik og reducere forsinkelser i mobilnetv\u00e6rk, mens IETF har erkl\u00e6ret sin fork af protokollen som grundlaget for standarden HTTP\/3 (hvorimod HTTP\/2 kun bruger kun 44,8%<\/a><\/noindex> af webstederne).<\/a><\/noindex><\/p>\n

Koncept<\/h2>\n

\nQUIC blev udviklet som en erstatning for den for\u00e6ldede TCP, som oprindeligt var designet til kablede netv\u00e6rk med lavt tab. TCP leverer pakker i r\u00e6kkef\u00f8lge, s\u00e5 n\u00e5r en pakke g\u00e5r tabt, stopper hele k\u00f8en (head-of-line blocking<\/a><\/noindex>), hvilket har en negativ indvirkning p\u00e5 kvaliteten og stabiliteten af forbindelsen. For at undg\u00e5 massetab bruger mobilnetv\u00e6rk store buffere, hvilket igen f\u00f8rer til overfl\u00f8dighed og falske negative reaktioner i protokollen (bufferbloat<\/a><\/noindex>). Desuden bruger TCP meget tid p\u00e5 at etablere forbindelse: SYN\/ACK og TLS-anmodninger sendes separat, hvilket kr\u00e6ver tre roundtrips i stedet for \u00e9n, som QUIC g\u00f8r.<\/p>\n

\"HTTP
\n
\nDa QUIC kombinerer en erstatning for TCP og implementeringen af TLS 1.3, er alle forbindelser altid krypterede; det er ikke lettere at dekryptere denne trafik end hvis den blev sendt over HTTPS. Desuden er QUIC implementeret p\u00e5 applikationsniveau, da en fuldst\u00e6ndig erstatning af TCP-stakken ville tage evigheder.<\/i>.<\/p>\n

P\u00e5 trods af underst\u00f8ttelsen af multiplexing i HTTP\/2, forbliver problemet med head-of-line blocking der, p\u00e5 grund af n\u00f8dvendigheden af at levere pakker i r\u00e6kkef\u00f8lge. QUIC er implementeret over UDP, s\u00e5 der er i princippet ingen blokeringer, og for at undg\u00e5, at pakker g\u00e5r tabt permanent, nummereres de og kan indeholde dele af \"naboer\" for at sikre overfl\u00f8dighed. Derudover opdeler QUIC den monolitiske k\u00f8 i flere str\u00f8mme til forskellige typer foresp\u00f8rgsler inden for en enkelt forbindelse. S\u00e5ledes kan problemer kun opst\u00e5 i \u00e9n k\u00f8 (for eksempel ved overf\u00f8rslen af en bestemt fil) ved pakke tab:<\/p>\n

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

Brugen af <\/h2>\n

\nOprindeligt blev QUIC udviklet internt i Google og var i h\u00f8j grad tilpasset brug i virksomheden. I 2013 blev det overdraget til IETF for standardisering (som stadig p\u00e5g\u00e5r), og nu kan alle deltage i udviklingen af protokollen ved at foresl\u00e5, hvad der mangler netop for dem. IETF-arbejdsgruppen organiserer \u00e5rligt m\u00f8der, hvor der fasts\u00e6ttes en ny standard, og der diskuteres nyheder. Denne QUIC-implementering betragtes som den prim\u00e6re, og det er p\u00e5 dens grundlag, at HTTP\/3-standarden certificeres.<\/p>\n

Indtil videre er der ikke tale om at inkludere HTTP\/3 som den prim\u00e6re protokol, fordi den stadig ikke er f\u00e6rdig og n\u00e6sten ikke underst\u00f8ttes:<\/p>\n

\"HTTP
\n
\nMen QUIC kan implementeres som transport mellem applikationen og serveren, hvilket Uber har gjort med succes:<\/p>\n

\n

Ubers kommentar om implementeringen af QUIC<\/i><\/h3>\n

\nFor at integrere QUIC succesfuldt og forbedre applikationens ydeevne under d\u00e5rlige forbindelser, erstattede vi den gamle stak (HTTP\/2 over TLS\/TCP) med QUIC-protokollen. Vi anvendte netv\u00e6rksbiblioteket Cronet<\/a><\/noindex> af Chromium Projects<\/a><\/noindex>, som indeholder den originale, Google-version af protokollen \u2013 gQUIC. Denne implementering forbedres konstant for at f\u00f8lge den nyeste IETF-specifikation.<\/p>\n

F\u00f8rst integrerede vi Cronet i vores Android-applikationer for at tilf\u00f8je st\u00f8tte til QUIC. Integrationen blev udf\u00f8rt p\u00e5 en m\u00e5de, der minimerede migrationsomkostningerne. I stedet for helt at erstatte den gamle netv\u00e6rksstak, der brugte biblioteket OkHttp<\/a><\/noindex>, integrerede vi Cronet UNDER OkHttp API-rammen. Ved at udf\u00f8re integrationen p\u00e5 denne m\u00e5de undgik vi \u00e6ndringer i vores netv\u00e6rksanrop (som bruger Retrofit<\/a><\/noindex>) p\u00e5 API-niveau.<\/p>\n

Ligesom med tilgangen til Android-enhederne implementerede vi Cronet i Uber-applikationer p\u00e5 iOS ved at intercept HTTP-trafik fra netv\u00e6rks API<\/a><\/noindex>, ved hj\u00e6lp af NSURLProtocol<\/a><\/noindex>. Denne abstraktion, som tilbydes af iOS Foundation, h\u00e5ndterer protokolspecifikke URL-data og sikrer, at vi kan integrere Cronet i vores iOS-applikationer uden v\u00e6sentlige migrationsomkostninger.<\/p><\/blockquote>\n

taget fra denne overs\u00e6ttelse<\/a><\/noindex> af artiklen fra Uber<\/i><\/p>\n

P\u00e5 backend fanger de QUIC-forbindelser gennem Google Cloud lb, som underst\u00f8tter protokollen<\/a><\/noindex> siden midten af 2018.<\/p>\n

Det er ikke overraskende, at Google Cloud fungerer godt med en protokol udviklet af Google, men hvilke alternativer er der?<\/p>\n

Nginx<\/h3>\n

\nFor ikke s\u00e5 l\u00e6nge siden fors\u00f8gte CloudFlare at kombinere<\/a><\/noindex> nginx (som som standard ikke underst\u00f8tter HTTP\/3) med deres v\u00e6rkt\u00f8j Quiche. Implementeringen er tilg\u00e6ngelig som en enkelt .patch-fil, som inkluderer en installationsguide:<\/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
\nHer kan du tilf\u00f8je dine moduler om n\u00f8dvendigt<\/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
\nDet er kun tilbage at aktivere HTTP\/3 underst\u00f8ttelse<\/p>\n
events {\n    worker_connections  1024;\n}\n\nhttp {\n    server {\n        # Aktiver QUIC og HTTP\/3.\n        listen 443 quic reuseport;\n\n        # Aktiver HTTP\/2 (valgfrit).\n        listen 443 ssl http2;\n\n        ssl_certificate      cert.crt;\n        ssl_certificate_key  cert.key;\n\n        # Aktiver alle TLS-versioner (TLSv1.3 er p\u00e5kr\u00e6vet for QUIC).\n        ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;\n\n        # Anmodningsbuffering underst\u00f8ttes i \u00f8jeblikket ikke for HTTP\/3.\n        proxy_request_buffering off;\n\n        # Tilf\u00f8j Alt-Svc-header for at forhandle HTTP\/3.\n        add_header alt-svc 'h3-27=":443"; ma=86400';\n    }\n}<\/code><\/pre>\n
\nI almindelige browsere er det endnu ikke muligt at oprette forbindelse via HTTP\/3, men du kan tage Chrome Canary<\/a><\/noindex> og k\u00f8re det med flaget --enable-quic<\/code>, henvende dig til din server eller for eksempel site quic.rocks og se forbindelsestypen i Developer Tools:
\n\"HTTP
\nI stedet for HTTP\/3 skrives http2+quic\/99<\/code>, men det er i det v\u00e6sentlige det samme.<\/p>\n
Andre teknologier<\/h3>\n
<\/p>\n