{"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 UDP kaudu - kasutame QUIC-protokolli kasulikult","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"HTTP
\n
\nQUIC (Kiirus UDP Interneti \u00dchendused) on protokoll UDP peal, mis toetab k\u00f5iki TCP, TLS ja HTTP\/2 funktsioone ning lahendab enamiku nende probleeme. Seda nimetatakse sageli uueks v\u00f5i \"eksperimentaalseks\" protokolliks, kuid see on juba ammu \u00fcletanud eksperimendi etapi: arendust on tehtud \u00fcle 7 aasta. Selle aja jooksul pole protokoll veel standardiks saanud, kuid see on siiski laialdaselt levinud. N\u00e4iteks kasutavad QUIC-i liikluse kiirendamiseks ja viivituste v\u00e4hendamiseks mobiilsete v\u00f5rkude hiiglased nagu Google ja Facebook, ning IETF kuulutas oma protokolli haru HTTP\/3 standardi aluseks. ainult 44,8%<\/a><\/noindex> veebilehtedest).<\/a><\/noindex><\/p>\n

Kontseptsioon<\/h2>\n

\nQUIC loodi vananenud TCP asendamiseks, mis oli algselt kohandatud juhtmega v\u00f5rkude jaoks madala kadude protsendiga. TCP edastab pakette j\u00e4rjestikku, seega, kui \u00fcks pakk kadus, seiskub terve j\u00e4rjekord (head-of-line blocking<\/a><\/noindex>), mis m\u00f5jutab negatiivselt \u00fchenduse kvaliteeti ja stabiilsust. Massiliste kadude v\u00e4ltimiseks kasutavad mobiilsed v\u00f5rgud suuri puhverid, mis omakorda viib liigsetele andmetele ja vale negatiivsele reaktsioonile protokollis (bufferbloat<\/a><\/noindex>). Lisaks kulutab TCP palju aega \u00fchenduse loomisele: SYN\\\/ACK ja TLS p\u00e4ringud toimuvad eraldi, n\u00f5udes kolme roundtrip'i, nagu QUIC teeb \u00fchega.<\/p>\n

\"HTTP
\n
\nKuna QUIC \u00fchendab TCP asendamise ja TLS 1.3 rakendamise, on k\u00f5ik \u00fchendused alati kr\u00fcpteeritud ning sellise liikluse dekodeerimine ei ole lihtsam kui HTTPS-i puhul. Lisaks on QUIC rakendatud rakendustasandil, kuna t\u00e4ielik TCP staki asendamine v\u00f5taks igavesti.<\/i>.<\/p>\n

Hoolimata HTTP\/2 mitmepleksimise toetusest, j\u00e4i problemaatiline head-of-line blocking seal alles, kuna pakette tuleb edastada j\u00e4rjestikku. QUIC on rakendatud UDP peal, seega puuduvad seal p\u00f5him\u00f5tteliselt blokeeringud, ning et pakette ei kaotataks l\u00f5plikult, nummerdatakse need ja need v\u00f5ivad sisaldada \u201enaabreid\u201c, tagades liigseeandmed. Lisaks jagab QUIC monoliitse j\u00e4rjekorra mitmeks vooks erinevat t\u00fc\u00fcpi p\u00e4ringute jaoks \u00fche \u00fchenduse sees. Seega, kui pakk kaob, v\u00f5ivad probleemid tekkida ainult \u00fche j\u00e4rjekorra puhul (n\u00e4iteks konkreetse faili edastamisel):<\/p>\n

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

Kasutamine <\/h2>\n

\nAlguses t\u00f6\u00f6tati QUIC v\u00e4lja Google'is ja see oli peamiselt kohandatud sisemiseks kasutamiseks. 2013. aastal anti see IETF-ile standardiseerimiseks (mis k\u00e4ib siiani) ning n\u00fc\u00fcd saab iga\u00fcks osaleda protokolli edasiarendamises, pakkudes sellele, mis just tema jaoks puudub. IETF-i t\u00f6\u00f6grupp korraldab iga-aastaselt kohtumisi, kus kinnitatakse uus standard ja arutatakse uuendusi. Seda QUIC-i teostust peetakse p\u00f5hiliseks ja selle alusel sertifitseeritakse HTTP\/3 standard.<\/p>\n

Praegu ei ole jutt HTTP\/3-st kui p\u00f5h protokollist, kuna see ei ole veel valminud ja praktiliselt ei ole toetatud:<\/p>\n

\"HTTP
\n
\nKuid QUIC-i saab rakendada transpordina rakenduse ja serveri vahel, nagu on edukalt teinud Uber:<\/p>\n

\n

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

\nQUIC-i edukaks integreerimiseks ja rakenduse j\u00f5udluse parandamiseks n\u00f5rkades \u00fchendustes asendasime vana steki (HTTP\/2 \u00fcle TLS\/TCP) QUIC-protokolliga. Kasutasime v\u00f5rgu teeki Cronet<\/a><\/noindex> API-s Chromium Projects<\/a><\/noindex>, mis sisaldab originaali, Google'i versioon protokollist \u2013 gQUIC. Seda teostust t\u00e4iustatakse pidevalt, et j\u00e4rgida viimast IETF-i spetsifikatsiooni.<\/p>\n

Esmalt integreerisime Croneti oma Android-rakendustesse, et lisada QUIC-i tugi. Integreerimine toimus nii, et migratsioonikulusid oleks v\u00f5imalikult v\u00e4he. Selle asemel, et t\u00e4ielikult asendada vana v\u00f5rgu steki, mis kasutas teeki OkHttp<\/a><\/noindex>, integreerisime Croneti OkHttp API raames. Sellise integreerimisega v\u00e4ltisime muudatusi meie v\u00f5rgu kutsumistes (mida kasutavad Retrofit<\/a><\/noindex>) API tasemel.<\/p>\n

Sarnaselt l\u00e4henemisele Android-seadmetele rakendasime Croneti Uberi rakendustes iOS-is, peatades HTTP liikluse v\u00f5rgu API<\/a><\/noindex>, kasutades NSURLProtocol<\/a><\/noindex>. See abstraktsioon, mis on saadud iOS Foundationist, haldab protokollispetsiifilisi URL-andmeid ja tagab, et saame Croneti integreerida oma iOS-rakendustes oluliste migratsioonikuludeta.<\/p><\/blockquote>\n

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

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

Ei ole \u00fcllatav, et Google Cloud t\u00f6\u00f6tab suurep\u00e4raselt protokolliga, mille Google v\u00e4lja t\u00f6\u00f6tas, kuid millised on alternatiivid?<\/p>\n

Nginx<\/h3>\n

\nHiljuti proovis CloudFlare ristata<\/a><\/noindex> nginx (mille, mis vaikimisi ei toeta HTTP\/3) koos oma Quiche t\u00f6\u00f6riistaga. Teostus on saadaval \u00fche .patch faili kujul, millele on lisatud installimise \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
\nSiin on v\u00f5imalik vajadusel lisada oma mooduleid<\/p>\n
.\/configure                          \n   \t--prefix=$PWD                       \n   \t--with-http_ssl_module              \n   \t--with-http_v2_module               \n   \t--with-http_v3_module               \n   \t--with-openssl=..\/quiche\/deps\/boringssl \n   \t--with-quiche=..\/quiche\n make<\/code><\/pre>\n
\nJ\u00e4\u00e4b vaid lubada HTTP\/3 toe<\/p>\n
events {\n    worker_connections  1024;\n}\n\nhttp {\n    server {\n        # Aktiveeri QUIC ja HTTP\\\/3.\n        listen 443 quic reuseport;\n\n        # Aktiveeri HTTP\\\/2 (valikuline).\n        listen 443 ssl http2;\n\n        ssl_certificate      cert.crt;\n        ssl_certificate_key  cert.key;\n\n        # Aktiveeri k\u00f5ik TLS versioonid (TLSv1.3 on vajalik QUIC jaoks).\n        ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;\n\n        # P\u00e4ringu puhverdamine 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 veel HTTP\/3 kaudu \u00fchendust luua, kuid saate v\u00f5tta Uus manifest on v\u00e4lja t\u00f6\u00f6tatud<\/a><\/noindex> ja k\u00e4ivitada seda lipuga --enable-quic<\/code>, p\u00f6\u00f6rduda oma serveri v\u00f5i n\u00e4iteks saidi quic.rocks poole ja vaadata \u00fchenduse t\u00fc\u00fcpi Developer Toolsis:
\n\"HTTP
\nHTTP\/3 asemel kuvatakse http2+quic\/99<\/code>, kuid sisuliselt on see sama asi.<\/p>\n
Teised tehnoloogiad<\/h3>\n
<\/p>\n