Ang QUIC (Quick UDP Internet Connections) ay isang protocol sa itaas ng UDP na sumusuporta sa lahat ng feature ng TCP, TLS at HTTP/2 at nilulutas ang karamihan sa kanilang mga problema. Madalas itong tinatawag na bago o "pang-eksperimentong" protocol, ngunit matagal na itong lumampas sa yugto ng eksperimentong: ang pag-unlad ay nagpapatuloy nang higit sa 7 taon. Sa panahong ito, hindi naging pamantayan ang protocol, ngunit naging laganap pa rin. Halimbawa, ang QUIC ay ginagamit ng mga higanteng tulad ng Google at Facebook upang pabilisin ang trapiko at bawasan ang mga pagkaantala sa mga mobile network, at idineklara ng IETF ang tinidor nito ng protocol bilang batayan para sa pamantayang HTTP/3 (kahit na gumagamit ang HTTP/2 mga site).
Pagkaunawa
Ang QUIC ay binuo bilang kapalit ng legacy na TCP, na orihinal na idinisenyo para sa mga low-loss wired network. Ang TCP ay naghahatid ng mga packet sa pagkakasunud-sunod, kaya kung ang isang packet ay nawala, ang buong pila ay hihinto (), na negatibong nakakaapekto sa kalidad at katatagan ng koneksyon. Upang maiwasan ang napakalaking pagkalugi, ang mga cellular network ay gumagamit ng malalaking buffer, na humahantong naman sa redundancy at maling negatibong tugon ng protocol (). Bilang karagdagan, ang TCP ay gumugugol ng maraming oras sa pagtatatag ng isang koneksyon: SYN/ACK at TLS na mga kahilingan ay magkahiwalay, na nangangailangan ng tatlong roundtrip sa halip na isa, tulad ng ginagawa ng QUIC.
Dahil pinagsasama ng QUIC ang pagpapalit ng TCP at pagpapatupad ng TLS 1.3, palaging naka-encrypt ang lahat ng koneksyon, at hindi mas madali ang pag-decrypt sa naturang trapiko kaysa sa kung ito ay dumadaan sa HTTPS. Bilang karagdagan, ang QUIC ay ipinatupad sa antas ng aplikasyon, bilang isang kumpletong pagpapalit ng TCP stack ay kukuha walang hanggan.
Sa kabila ng suporta para sa multiplexing sa HTTP/2, nanatili roon ang problema ng head-of-line blocking dahil sa pangangailangang maghatid ng mga packet sa pagkakasunud-sunod. Ang QUIC ay ipinatupad sa itaas ng UDP, kaya wala itong pagharang sa prinsipyo, at upang maiwasang mawala nang tuluyan ang mga packet, binibilang ang mga ito at maaaring maglaman ng mga bahagi ng "mga kapitbahay," na nagbibigay ng redundancy. Bilang karagdagan, hinahati ng QUIC ang monolithic queue sa maraming mga thread para sa iba't ibang uri ng mga kahilingan sa loob ng iisang koneksyon. Kaya, kung ang isang packet ay nawala, ang mga problema ay maaaring lumitaw lamang para sa isang pila (halimbawa, para sa paglilipat ng isang partikular na file):
Gamitin
Sa una, ang QUIC ay binuo sa loob ng Google at higit na iniakma para sa paggamit sa loob ng kumpanya. Noong 2013, inilipat ito sa IETF para sa standardisasyon (na patuloy pa rin), at ngayon ang lahat ay maaaring lumahok sa pagbuo ng protocol sa pamamagitan ng pagmumungkahi kung ano ang nawawala sa kanila. Ang IETF working group ay nag-oorganisa ng mga taunang pagpupulong kung saan ang isang bagong pamantayan ay naaprubahan at ang mga inobasyon ay tinatalakay. Ang pagpapatupad na ito ng QUIC ay itinuturing na pangunahing isa at ito ay sa batayan nito na ang HTTP/3 na pamantayan ay sertipikado.
Sa ngayon, walang usapan tungkol sa pagsasama ng HTTP/3 bilang pangunahing protocol, dahil hindi pa ito tapos at halos hindi suportado:
Ngunit ang QUIC ay maaaring ipatupad bilang isang transportasyon sa pagitan ng application at ng server, na matagumpay na nagawa sa Uber:
Ang komento ng Uber sa pagpapakilala ng QUIC
Upang matagumpay na i-embed ang QUIC at pagbutihin ang performance ng application sa mahihirap na kapaligiran ng koneksyon, pinalitan namin ang lumang stack (HTTP/2 sa TLS/TCP) ng QUIC protocol. Ginamit namin ang library ng network ng , na naglalaman ng orihinal, bersyon ng Google ng protocol - gQUIC. Ang pagpapatupad na ito ay patuloy ding pinapabuti upang sundin ang pinakabagong detalye ng IETF.
Una naming isinama ang Cronet sa aming mga Android app upang magdagdag ng suporta para sa QUIC. Ang pagsasama ay isinagawa sa paraang mabawasan ang mga gastos sa paglilipat hangga't maaari. Sa halip na ganap na palitan ang lumang networking stack na ginamit ang library , isinama namin ang Cronet SA ILALIM ng balangkas ng OkHttp API. Sa pamamagitan ng paggawa ng pagsasama sa ganitong paraan, naiwasan namin ang mga pagbabago sa aming mga tawag sa network (na ginagamit ng ) sa antas ng API.
Katulad ng diskarte para sa mga Android device, ipinatupad namin ang Cronet sa mga Uber app sa iOS, na humahadlang sa trapiko ng HTTP mula sa network gamit . Ang abstraction na ito, na ibinigay ng iOS Foundation, ay humahawak sa data ng URL na tukoy sa protocol at tinitiyak na maaari naming isama ang Cronet sa aming mga iOS application nang walang makabuluhang gastos sa paglipat.
kinuha mula sa Mga artikulo sa Uber
Sa backend ay nakakuha sila ng mga QUIC na koneksyon sa pamamagitan ng Google Cloud lb, na mula noong kalagitnaan ng 2018.
Hindi nakakagulat na mahusay na gumagana ang Google Cloud sa protocol na binuo ng Google, ngunit ano ang mga alternatibo?
Nginx
Hindi nagtagal CloudFlare nginx (na hindi sumusuporta sa HTTP/3 bilang default) gamit ang Quiche tool nito. Available ang pagpapatupad bilang isang solong .patch file, na may kasamang tutorial sa pag-install:
curl -O https://nginx.org/download/nginx-1.16.1.tar.gz
tar xvzf nginx-1.16.1.tar.gz
git clone --recursive https://github.com/cloudflare/quiche
cd nginx-1.16.1
patch -p01 < ../quiche/extras/nginx/nginx-1.16.patchDito maaari mong ikonekta ang iyong mga module kung kinakailangan
./configure
--prefix=$PWD
--with-http_ssl_module
--with-http_v2_module
--with-http_v3_module
--with-openssl=../quiche/deps/boringssl
--with-quiche=../quiche
makeAng natitira na lang ay paganahin ang suporta sa HTTP/3
events {
worker_connections 1024;
}
http {
server {
# Enable QUIC and HTTP/3.
listen 443 quic reuseport;
# Enable HTTP/2 (optional).
listen 443 ssl http2;
ssl_certificate cert.crt;
ssl_certificate_key cert.key;
# Enable all TLS versions (TLSv1.3 is required for QUIC).
ssl_protocols TLSv1 TLSv1.1 TLSv1.2 TLSv1.3;
# Request buffering in not currently supported for HTTP/3.
proxy_request_buffering off;
# Add Alt-Svc header to negotiate HTTP/3.
add_header alt-svc 'h3-27=":443"; ma=86400';
}
}
Hindi pa posible na kumonekta sa pamamagitan ng HTTP/3 sa mga regular na browser, ngunit maaari mong gamitin at patakbuhin ito gamit ang bandila --enable-quic, pumunta sa iyong server o, halimbawa, ang quic.rocks site at tingnan ang uri ng koneksyon sa Developer Tools:
Sa halip na HTTP/3 ito ay nakasulat http2+quic/99, ngunit ito ay mahalagang ang parehong bagay.
Iba pang mga teknolohiya
- Sinusuportahan din ng QUIC (na kumonekta sa Facebook sa pamamagitan ng HTTP/3 na may mahusay na fanfare) at progresibo . Hindi pa ito magagawa ng Apache, ngunit isinasagawa ang trabaho .
- Na-update ang Enero 21
- Noong isang araw lang nagbukas ang Microsoft , kung saan hindi pa available ang lahat ng function mula sa pamantayan ng IETF, ngunit isa na itong malaking tagumpay.
Konklusyon
Ang interes sa QUIC ay hindi matatag, ngunit lumalaki, at ang trabaho ay isinasagawa upang i-standardize ito. Ang mga bagong pagpapatupad ng protocol ay lumilitaw halos bawat buwan, at bawat taon parami nang parami ang mga developer na kumbinsido na ang QUIC ay ang hinaharap. Posible pa ring isama ang protocol sa mga hinaharap na bersyon ng TCP stack, na nangangahulugan na maaga o huli ang buong Internet ay lilipat sa mas matatag at mas mabilis na mga koneksyon.
Ngayon ay maaari mo nang i-configure ang QUIC na pakikipag-ugnayan para sa iyong imprastraktura o kahit na ibigay ito sa mga browser - lahat sila ay nagpaplanong magdagdag ng suporta para sa protocol, at ang malungkot na istatistika sa caniuse ay magiging mas masaya.
Pinagmulan: www.habr.com