{"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\/et\/blog\/administrirovanie\/http-po-udp-ispolzuem-s-polzoj-protokol-quic","title":{"rendered":"HTTP \u00fcle UDP \u2014 kasutame QUIC protokolli t\u00f5husalt","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"HTTP
\n
\nQUIC (Kiired UDP Interneti \u00dchendused) on UDP peal t\u00f6\u00f6tav protokoll, mis toetab k\u00f5iki TCP, TLS ja HTTP\/2 funktsioone ning lahendab enamik nende probleeme. Seda tuntakse sageli kui uut v\u00f5i 'eksperimentaalset' protokolli, kuid see on juba pikka aega eksperimentaalsest staadiumist v\u00e4lja kasvanud: arendust\u00f6\u00f6d on kestnud \u00fcle 7 aasta. Selle aja jooksul ei ole protokollist veel saanud standardit, kuid see on end siiski laialdaselt t\u00f5estanud. N\u00e4iteks kasutavad QUIC-i liikluse kiirendamiseks ja viivituste v\u00e4hendamiseks mobiilsetes v\u00f5rkudes sellised hiidettev\u00f5tted nagu Google ja Facebook, ning IETF kuulutas oma protokolli hargnemise HTTP\/3 standardi aluseks (samal ajal, kui HTTP\/2 kasutab ainult 44,8%<\/a><\/noindex> veebilehtedest).<\/a><\/noindex><\/p>\n

Kontseptsioon<\/h2>\n

\nQUIC v\u00e4lja t\u00f6\u00f6tati vananenud TCP asendamiseks, mis oli algselt loodud madala kaotusprotsendiga kaabliv\u00f5rkude jaoks. TCP edastab pakette j\u00e4rjestikku, seet\u00f5ttu peatub terve j\u00e4rjekord, kui \u00fcks pakett kaob (pea-rea ummik<\/a><\/noindex>), mis m\u00f5jutab negatiivselt \u00fchenduse kvaliteeti ja stabiilsust. Massiliste kaotuste v\u00e4ltimiseks kasutavad mobiilv\u00f5rgud suuri puhvrite kasutamise meetodeid, mis omakorda toovad kaasa liialdatuse ja vale negatiivse reaktsiooni protokollis (bufferbloat<\/a><\/noindex>). Lisaks kulutab TCP \u00fchenduse loomisele palju aega: SYN\/ACK ja TLS p\u00e4ringud toimuvad eraldi, n\u00f5udes kolme roundtrip'i asemel \u00fchte, nagu QUIC teeb.<\/p>\n

\"HTTP
\n
\nKuna QUIC \u00fchendab endas TCP asendamise ja TLS 1.3 rakendamise, on k\u00f5ik \u00fchendused alati kr\u00fcpteeritud. Sellise liikluse dekr\u00fcpteerimine ei ole lihtsam kui siis, kui see kulgeks HTTPS protokolli kaudu. Lisaks on QUIC rakendatud rakenduslikul tasemel, kuna t\u00e4ielik TCP staki asendamine v\u00f5taks igavikku<\/i>.<\/p>\n

Hoolimata HTTP\/2 mitmeosalise edastamise toetusest on seal j\u00e4\u00e4nud peamine probleem, et pakettide edastamine toimub j\u00e4rjekorras. QUIC on rakendatud UDP peal, seega ei tekita see \u00fcldse ummistusi ning pakette ei kaotata igaveseks, kuna need on nummerdatud ja v\u00f5ivad sisaldada oma \u201enaabrite\u201c osi, tagades \u00fcleliigsuse. Lisaks jagab QUIC monoliitset j\u00e4rjekorda mitmeks vooks erinevatele p\u00e4ringut\u00fc\u00fcpidele \u00fche \u00fchenduse sees. Seet\u00f5ttu v\u00f5ivad paketi kaotuse korral probleemid tekkida ainult \u00fches j\u00e4rjekorras (n\u00e4iteks siis, kui edastatakse konkreetset faili):<\/p>\n

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

Kasutamine <\/h2>\n

\nQUIC loodi algselt Google'is ja oli suuresti kohandatud ettev\u00f5tte sisekasutuseks. 2013. aastal anti see IETF-ile standardiseerimiseks (mis j\u00e4tkub endiselt), ja n\u00fc\u00fcd v\u00f5ib iga\u00fcks osaleda protokolli arenduses, pakkudes just omale vajalikke t\u00e4iustusi. IETF-i t\u00f6\u00f6grupp korraldab igal aastal kohtumisi, kus kinnitatakse uus standard ja arutatakse uuendusi. See QUIC-i rakendus on peamine ning selle alusel sertifitseeritakse HTTP\/3 standard.<\/p>\n

Praegu ei r\u00e4\u00e4gita HTTP\/3 lisamisest p\u00f5h protokollina, kuna see pole veel l\u00f5petatud ja peaaegu ei toetata:<\/p>\n

\"HTTP
\n
\nKuid QUIC-i saab ellu viia kui transporti rakenduse ja serveri vahel, mida on edukalt teinud Uber:<\/p>\n

\n

Uberi kommentaar QUIC-i rakendamisest<\/i><\/h3>\n

\nQUIC-i edukaks integreerimiseks ja rakenduse j\u00f5udluse parandamiseks halva \u00fchenduvuse tingimustes asendasime vana steki (HTTP\/2 TLS-i\/TCP-i peal) QUIC protokolliga. Kasutasime v\u00f5rgu raamatukogu Cronet<\/a><\/noindex> kohast Chromium Projects<\/a><\/noindex>, mis sisaldab originaalset, Google'i versiooni protokollist \u2013 gQUIC. See teostus t\u00e4iustatakse pidevalt, et j\u00e4rgida viimast IETF spetsifikatsiooni.<\/p>\n

Esmalt integreerisime Croneti oma Android-rakendustesse, et lisada QUIC-i tugi. Integreerimine viidi l\u00e4bi nii, et minimeerida migratsioonikulud. Selle asemel, et t\u00e4ielikult asendada vana v\u00f5rgu redaktori, mis kasutas teeki OkHttp<\/a><\/noindex>, integreerisime Croneti OkHttp API raamistiku ALL. Sel viisil integreerides v\u00e4ltisime muudatusi meie v\u00f5rgu p\u00e4ringutes (mida kasutavad Retrofit<\/a><\/noindex>) API tasemel.<\/p>\n

Sarnaselt l\u00e4henemisele Android-seadmetele, oleme integreerinud Croneti Uberi rakendustesse iOS-is, suunates HTTP-liiklust v\u00f5rgu API<\/a><\/noindex>, kasutades NSURLProtocol<\/a><\/noindex>. See iOS Foundation'i pakutud abstraktsioon t\u00f6\u00f6tleb protokollispetsiifilisi URL-andmeid ja tagab, et saame Croneti integreerida oma iOS-rakendustesse ilma oluliste migratsioonikuludeta.<\/p><\/blockquote>\n

v\u00f5etud sellest t\u00f5lkest<\/a><\/noindex> artiklist Uber<\/i><\/p>\n

Tagaplaanil nad p\u00fc\u00fcdsid QUIC-\u00fchendusi Google Cloud lb kaudu, mis toetab protokolli<\/a><\/noindex> alates 2018. aasta keskpaigast.<\/p>\n

Pole \u00fcllatav, et Google Cloud t\u00f6\u00f6tab suurep\u00e4raselt Google'i loodud protokolliga, kuid millised on alternatiivid?<\/p>\n

Nginx<\/h3>\n

\nHiljuti proovisin CloudFlare ristata<\/a><\/noindex> nginx'i (mis vaikimisi ei toeta HTTP\/3) oma Quiche t\u00f6\u00f6riistaga. Teostus on saadaval \u00fches .patch failis, millele on lisatud installi \u00f5petus:<\/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
\nSiia saab vajadusel lisada oma mooduleid<\/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
\nJ\u00e4\u00e4nud on vaid HTTP\/3 toe sissel\u00fclitamine<\/p>\n
events {\n    worker_connections  1024;\n}\n\nhttp {\n    server {\n        # Luba QUIC ja HTTP\/3.\n        listen 443 quic reuseport;\n\n        # Luba HTTP\/2 (valikuline).\n        listen 443 ssl http2;\n\n        ssl_certificate      cert.crt;\n        ssl_certificate_key  cert.key;\n\n        # Luba k\u00f5ik TLS versioonid (TLSv1.3 on vajalik QUIC-i jaoks).\n        ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;\n\n        # P\u00e4ringu puhverside ei ole praegu HTTP\/3 jaoks toetatud.\n        proxy_request_buffering off;\n\n        # Lisa Alt-Svc p\u00e4is HTTP\/3 l\u00e4bir\u00e4\u00e4kimiseks.\n        add_header alt-svc 'h3-27=":443"; ma=86400';\n    }\n}<\/code><\/pre>\n
\nTavalistes brauserites ei saa HTTP\/3 \u00fcle \u00fchendust, kuid saab v\u00f5tta Chrome Canary<\/a><\/noindex> ja k\u00e4ivita see lipuga --enable-quic<\/code>, k\u00fclastage oma serverit v\u00f5i n\u00e4iteks veebisaiti quic.rocks ja vaadake \u00fchenduse t\u00fc\u00fcpi Developer Tools'is:
\n\"HTTP
\nHTTP\/3 asemel kuvatakse http2+quic\/99<\/code>, kuid tegelikult on see sama asi.<\/p>\n
Muud tehnoloogiad<\/h3>\n
<\/p>\n