{"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\/pl\/blog\/administrirovanie\/http-po-udp-ispolzuem-s-polzoj-protokol-quic","title":{"rendered":"HTTP przez UDP \u2014 korzystanie z protoko\u0142u QUIC.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"HTTP
\n
\nQUIC (Quick UDP Internet Connections) to protok\u00f3\u0142 dzia\u0142aj\u0105cy na bazie UDP, kt\u00f3ry wspiera wszystkie mo\u017cliwo\u015bci TCP, TLS i HTTP\/2 oraz rozwi\u0105zuje wiele ich problem\u00f3w. Cz\u0119sto nazywany jest nowym lub \u201eeksperymentalnym\u201d protoko\u0142em, ale od dawna przeszed\u0142 faz\u0119 eksperymentu: rozwijany jest od ponad 7 lat. W tym czasie protok\u00f3\u0142 nie sta\u0142 si\u0119 standardem, ale mimo to zyska\u0142 szerokie zastosowanie. Na przyk\u0142ad QUIC jest wykorzystywany do przyspieszania ruchu i redukcji op\u00f3\u017anie\u0144 w sieciach mobilnych przez takich gigant\u00f3w jak Google i Facebook, a IETF og\u0142osi\u0142a jego forka podstaw\u0105 dla standardu HTTP\/3 (przy czym HTTP\/2 wykorzystuje tylko 44,8%<\/a><\/noindex> stron).<\/a><\/noindex><\/p>\n

Koncepcja<\/h2>\n

\nQUIC zosta\u0142 stworzony jako zamiennik przestarza\u0142ego TCP, kt\u00f3re pierwotnie by\u0142o dostosowane do przewodowych sieci o niskim procencie strat. TCP dostarcza pakiety w kolejno\u015bci, wi\u0119c w przypadku utraty jednego pakietu ca\u0142a kolejka staje w miejscu (head-of-line blocking<\/a><\/noindex>), co negatywnie wp\u0142ywa na jako\u015b\u0107 i stabilno\u015b\u0107 po\u0142\u0105czenia. Aby unikn\u0105\u0107 masowych strat, sieci kom\u00f3rkowe stosuj\u0105 du\u017ce bufory, co z kolei prowadzi do nadmiarowo\u015bci i fa\u0142szywie negatywnej reakcji protoko\u0142u (bufferbloat<\/a><\/noindex>). Dodatkowo, TCP zajmuje bardzo du\u017co czasu na nawi\u0105zywanie po\u0142\u0105czenia: zapytania SYN\/ACK oraz TLS s\u0105 wykonywane oddzielnie, co wymaga trzech roundtrip\u00f3w zamiast jednego, jak to robi QUIC.<\/p>\n

\"HTTP
\n
\nPoniewa\u017c QUIC \u0142\u0105czy w sobie zamian\u0119 TCP i implementacj\u0119 TLS 1.3, wszystkie po\u0142\u0105czenia s\u0105 zawsze szyfrowane, a deszyfrowanie takiego ruchu nie jest \u0142atwiejsze ni\u017c w przypadku HTTPS. Co wi\u0119cej, QUIC jest zaimplementowany na poziomie aplikacji, poniewa\u017c pe\u0142na zamiana stosu TCP zaj\u0119\u0142aby wieczno\u015b\u0107.<\/i>.<\/p>\n

Mimo wsparcia dla multiplexingu w HTTP\/2, problem head-of-line blocking pozosta\u0142 z uwagi na konieczno\u015b\u0107 dostarczania pakiet\u00f3w w kolejno\u015bci. QUIC dzia\u0142a na bazie UDP, dlatego nie wyst\u0119puj\u0105 w nim blokady, a aby pakiety nie gin\u0119\u0142y bezpowrotnie, s\u0105 numerowane i mog\u0105 zawiera\u0107 cz\u0119\u015bci \u201es\u0105siad\u00f3w\u201d, zapewniaj\u0105c nadmiarowo\u015b\u0107. Dodatkowo QUIC dzieli monolityczn\u0105 kolejk\u0119 na kilka strumieni dla r\u00f3\u017cnych typ\u00f3w \u017c\u0105da\u0144 w ramach jednego po\u0142\u0105czenia. W ten spos\u00f3b, przy utracie pakietu, problemy mog\u0105 wyst\u0105pi\u0107 tylko w jednej kolejce (na przyk\u0142ad przy przesy\u0142aniu konkretnego pliku):<\/p>\n

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

U\u017cycie <\/h2>\n

\nPierwotnie QUIC by\u0142 rozwijany w Google i by\u0142 g\u0142\u00f3wnie dostosowany do u\u017cytku wewn\u0119trznego w firmie. W 2013 roku przekazano go do IETF w celu standaryzacji (kt\u00f3ra trwa do dzi\u015b), a teraz ka\u017cdy mo\u017ce wzi\u0105\u0107 udzia\u0142 w rozwoju protoko\u0142u, proponuj\u0105c to, czego mu brakuje. Grupa robocza IETF organizuje coroczne spotkania, na kt\u00f3rych zatwierdzany jest nowy standard i omawiane s\u0105 innowacje. Ta implementacja QUIC jest uwa\u017cana za podstawow\u0105 i na jej podstawie certyfikowany jest standard HTTP\/3.<\/p>\n

Na razie nie m\u00f3wi si\u0119 o w\u0142\u0105czeniu HTTP\/3 jako g\u0142\u00f3wnego protoko\u0142u, poniewa\u017c nie jest on jeszcze uko\u0144czony i prawie nie jest wspierany:<\/p>\n

\"HTTP
\n
\nJednak QUIC mo\u017cna zrealizowa\u0107 jako transport mi\u0119dzy aplikacj\u0105 a serwerem, co z powodzeniem zrobili w Uber:<\/p>\n

\n

Komentarz Ubera na temat implementacji QUIC<\/i><\/h3>\n

\nAby pomy\u015blnie zaimplementowa\u0107 QUIC i poprawi\u0107 wydajno\u015b\u0107 aplikacji w warunkach s\u0142abego po\u0142\u0105czenia, zast\u0105pili\u015bmy stary stos (HTTP\/2 nad TLS\/TCP) protoko\u0142em QUIC. Skorzystali\u015bmy z biblioteki sieciowej Cronet<\/a><\/noindex> z Chromium Projects<\/a><\/noindex>, kt\u00f3ra zawiera oryginaln\u0105, google'owsk\u0105 wersj\u0119 protoko\u0142u \u2013 gQUIC. Ta implementacja jest r\u00f3wnie\u017c stale ulepszana, aby przestrzega\u0107 najnowszej specyfikacji IETF.<\/p>\n

Najpierw zintegrowali\u015bmy Cronet w naszych aplikacjach na Androida, aby doda\u0107 wsparcie dla QUIC. Integracja zosta\u0142a przeprowadzona w spos\u00f3b, aby maksymalnie ograniczy\u0107 koszty migracji. Zamiast ca\u0142kowicie zast\u0105pi\u0107 stary stos sieciowy, kt\u00f3ry korzysta\u0142 z biblioteki OkHttp<\/a><\/noindex>, zintegrowali\u015bmy Cronet POD frameworkiem OkHttp API. Przeprowadzaj\u0105c integracj\u0119 w ten spos\u00f3b, unikn\u0119li\u015bmy zmian w naszych wywo\u0142aniach sieciowych (kt\u00f3re u\u017cywaj\u0105 Retrofit<\/a><\/noindex>) na poziomie API.<\/p>\n

Podobnie jak w przypadku urz\u0105dze\u0144 z Androidem, wdro\u017cyli\u015bmy Cronet w aplikacjach Uber na iOS, przechwytuj\u0105c ruch HTTP z API<\/a><\/noindex>, u\u017cywaj\u0105c NSURLProtocol<\/a><\/noindex>. Ta abstrakcja, dostarczana przez iOS Foundation, obs\u0142uguje specyficzne dla protoko\u0142u dane URL i zapewnia, \u017ce mo\u017cemy zintegrowa\u0107 Cronet w naszych aplikacjach na iOS bez znacznych koszt\u00f3w migracji.<\/p><\/blockquote>\n

pochodzi z tego t\u0142umaczenia<\/a><\/noindex> artyku\u0142u Uber<\/i><\/p>\n

Na backendzie przechwytywali po\u0142\u0105czenia QUIC przez Google Cloud lb, kt\u00f3ry wspiera protok\u00f3\u0142<\/a><\/noindex> od po\u0142owy 2018 roku.<\/p>\n

Nie dziwi fakt, \u017ce Google Cloud doskonale wsp\u00f3\u0142pracuje z protoko\u0142em stworzonym przez Google, ale jakie s\u0105 alternatywy?<\/p>\n

Nginx<\/h3>\n

\nNiedawno CloudFlare pr\u00f3bowa\u0142 skrosowa\u0107<\/a><\/noindex> nginx (kt\u00f3ry domy\u015blnie nie obs\u0142uguje HTTP\/3) z w\u0142asnym narz\u0119dziem Quiche. Realizacja jest dost\u0119pna w postaci jednego pliku .patch, do kt\u00f3rego do\u0142\u0105czono tutorial instalacyjny:<\/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
\nTutaj mo\u017cna pod\u0142\u0105czy\u0107 w\u0142asne modu\u0142y w razie potrzeby<\/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
\nPozostaje tylko w\u0142\u0105czy\u0107 wsparcie dla HTTP\/3<\/p>\n
events {\n    worker_connections  1024;\n}\n\nhttp {\n    server {\n        # W\u0142\u0105cz QUIC i HTTP\/3.\n        listen 443 quic reuseport;\n\n        # W\u0142\u0105cz HTTP\/2 (opcjonalnie).\n        listen 443 ssl http2;\n\n        ssl_certificate      cert.crt;\n        ssl_certificate_key  cert.key;\n\n        # W\u0142\u0105cz wszystkie wersje TLS (TLSv1.3 jest wymagany dla QUIC).\n        ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;\n\n        # Buforowanie \u017c\u0105da\u0144 nie jest obecnie obs\u0142ugiwane dla HTTP\/3.\n        proxy_request_buffering off;\n\n        # Dodaj nag\u0142\u00f3wek Alt-Svc do negocjacji HTTP\/3.\n        add_header alt-svc 'h3-27=":443"; ma=86400';\n    }\n}<\/code><\/pre>\n
\nW zwyk\u0142ych przegl\u0105darkach po\u0142\u0105czenie przez HTTP\/3 jest w tej chwili niemo\u017cliwe, ale mo\u017cna u\u017cy\u0107 Chrome Canary<\/a><\/noindex> i uruchomi\u0107 go z flag\u0105 --enable-quic<\/code>, po\u0142\u0105czy\u0107 si\u0119 ze swoim serwerem lub np. z witryn\u0105 quic.rocks i sprawdzi\u0107 typ po\u0142\u0105czenia w Narz\u0119dziach Deweloperskich:
\n\"HTTP
\nZamiast HTTP\/3 pisze si\u0119 http2+quic\/99<\/code>, ale jest to w zasadzie to samo.<\/p>\n
Inne technologie<\/h3>\n
<\/p>\n