UDP ကျော် 🥇HTTP - အားသာချက်ကောင်းအတွက် QUIC ပရိုတိုကောကို အသုံးပြုခြင်း။ ProHoster

QUIC (Quick UDP Internet Connections) သည် TCP၊ TLS နှင့် HTTP/2 တို့၏ အင်္ဂါရပ်အားလုံးကို ပံ့ပိုးပေးကာ ၎င်းတို့၏ ပြဿနာအများစုကို ဖြေရှင်းပေးသည့် UDP ၏ထိပ်တွင် ပရိုတိုကောတစ်ခုဖြစ်သည်။ ၎င်းကို အသစ် သို့မဟုတ် "စမ်းသပ်မှု" ပရိုတိုကောဟု မကြာခဏခေါ်သော်လည်း ၎င်းသည် စမ်းသပ်ဆဲအဆင့်ကို ကျော်လွန်ခဲ့သည်- ဖွံ့ဖြိုးတိုးတက်မှုသည် 7 နှစ်ကျော်ကြာခဲ့ပြီဖြစ်သည်။ ဤကာလအတွင်းတွင်၊ ပရိုတိုကောသည် စံတစ်ခုမဖြစ်လာသေးသော်လည်း ကျယ်ပြန့်လာသည်။ ဥပမာအားဖြင့်၊ QUIC ကို Google နှင့် Facebook ကဲ့သို့သော ကုမ္ပဏီကြီးများ၏ မိုဘိုင်းကွန်ရက်များတွင် သွားလာမှု အရှိန်မြှင့်ရန်နှင့် နှောင့်နှေးမှုများကို လျှော့ချရန်အတွက် အသုံးပြုထားပြီး IETF သည် HTTP/3 စံနှုန်းအတွက် အခြေခံအဖြစ် HTTP/2 ကို အသုံးပြုသော်လည်း၊ 44.8% သာ ဆိုဒ်များ)။

ခံယူချက်

QUIC သည် ဆုံးရှုံးမှုရာခိုင်နှုန်းနည်းပါးသော ကြိုးတပ်ကွန်ရက်များအတွက် မူလက ဒီဇိုင်းထုတ်ထားသည့် ခေတ်မမီတော့သော TCP အတွက် အစားထိုးအဖြစ် တီထွင်ခဲ့သည်။ TCP သည် packet များကို အစီအစဉ်တကျ ပို့ဆောင်ပေးသောကြောင့် packet တစ်ခု ပျောက်ဆုံးပါက တန်းစီတစ်ခုလုံး ပိတ်သွားသည် (ထိပ်ပိုင်းပိတ်ဆို့ခြင်း။) ချိတ်ဆက်မှု၏ အရည်အသွေးနှင့် တည်ငြိမ်မှုကို ထိခိုက်စေသည်။ ကြီးမားသောဆုံးရှုံးမှုများကိုရှောင်ရှားရန်၊ ဆယ်လူလာကွန်ရက်များသည် ကြီးမားသောကြားခံများကိုအသုံးပြုရန် အားကိုးအားထားပြုကြပြီး၊ ၎င်းသည် ပရိုတိုကော၏ ထပ်လောင်းခြင်းနှင့် မှားယွင်းသောအနုတ်လက္ခဏာတုံ့ပြန်မှုများကိုဖြစ်ပေါ်စေသည် (bufferbloat) ထို့အပြင်၊ TCP သည် ချိတ်ဆက်မှုတစ်ခုတည်ဆောက်ရန် အချိန်များစွာဖြုန်းသည်- SYN/ACK နှင့် TLS တောင်းဆိုမှုများကို သီးခြားစီပေးပို့ပြီး QUIC ကဲ့သို့ တစ်ခုအစား အသွားအပြန်သုံးကြိမ် လိုအပ်သည်။

QUIC သည် TCP အစားထိုးခြင်းနှင့် TLS 1.3 အကောင်အထည်ဖော်မှုကို ပေါင်းစပ်ထားသောကြောင့်၊ ချိတ်ဆက်မှုများအားလုံးကို အမြဲတမ်း ကုဒ်ဝှက်ထားပြီး၊ ထိုလမ်းကြောင်းကို ကုဒ်ဝှက်ခြင်းသည် HTTPS ထက် ပိုလွယ်ကူမည်မဟုတ်ပါ။ ထို့အပြင်၊ TCP stack ၏ အပြီးသတ် အစားထိုးမှုအဖြစ် QUIC ကို လျှောက်လွှာအဆင့်တွင် အကောင်အထည်ဖော်ပါသည်။ ထာဝရ.

HTTP/2 တွင် multiplexing ကို ပံ့ပိုးပေးသော်လည်း၊ packet များကို အစီအစဥ်အတိုင်း ပို့ဆောင်ရန် လိုအပ်သောကြောင့် head-of-line ပိတ်ဆို့ခြင်းပြဿနာမှာ ရှိနေသေးသည်။ QUIC သည် UDP ၏ထိပ်တွင် အကောင်အထည်ဖော်ထားသောကြောင့် ၎င်းတွင်မူအရပိတ်ဆို့ခြင်းမျိုးမရှိသည့်အပြင် packets များကို အလွယ်တကူပြန်မရနိုင်အောင် ပျောက်ကွယ်သွားစေရန်အတွက် ၎င်းတို့ကို နံပါတ်တပ်ထားပြီး အပိုပစ္စည်းများကိုပေးဆောင်သည့် "အိမ်နီးနားချင်းများ" ၏အစိတ်အပိုင်းများပါ၀င်နိုင်သည်။ ထို့အပြင်၊ QUIC သည် ချိတ်ဆက်မှုတစ်ခုအတွင်း တောင်းဆိုမှုအမျိုးအစားအမျိုးမျိုးအတွက် monolithic တန်းစီအား လမ်းကြောင်းများစွာသို့ ပိုင်းခြားထားသည်။ ထို့ကြောင့်၊ ပက်ကတ်တစ်ခုပျောက်ဆုံးသွားသောအခါ၊ တန်းစီတစ်ခုအတွက်သာ ပြဿနာများ ဖြစ်ပေါ်လာနိုင်သည် (ဥပမာ၊ သီးခြားဖိုင်တစ်ခုကို လွှဲပြောင်းခြင်းအတွက်)။

၏အသုံးပြုမှု

အစပိုင်းတွင် QUIC ကို Google တွင် တီထွင်ခဲ့ပြီး ကုမ္ပဏီအတွင်း အသုံးပြုရန်အတွက် အကြီးစားပြင်ဆင်ထားသည်။ 2013 ခုနှစ်တွင်၊ ၎င်းအား စံချိန်စံညွှန်းသတ်မှတ်ခြင်းအတွက် IETF သို့ လွှဲပြောင်းခဲ့ပြီး (ဆက်လက်လုပ်ဆောင်ဆဲ) နှင့် ယခုအခါ မည်သူမဆို ၎င်းတို့ အထူးချို့တဲ့သည့်အရာကို ပေးဆောင်ခြင်းဖြင့် ပရိုတိုကောဖွံ့ဖြိုးတိုးတက်မှုတွင် ပါဝင်နိုင်သည်။ IETF အလုပ်အဖွဲ့သည် စံနှုန်းအသစ်ကို အတည်ပြုပြီး ဆန်းသစ်တီထွင်မှုများကို ဆွေးနွေးနေချိန်အတွင်း နှစ်စဉ်အစည်းအဝေးများကို စီစဉ်ပေးပါသည်။ QUIC ၏ ဤအကောင်အထည်ဖော်မှုသည် အဓိကဖြစ်သည်ဟု ယူဆကြပြီး HTTP/3 စံနှုန်းကို အသိအမှတ်ပြုကြောင်း ၎င်း၏အခြေခံပေါ်တွင် အခြေခံထားသည်။

ပင်မပရိုတိုကောအဖြစ် HTTP/3 ကို ထည့်သွင်းခြင်းနှင့်ပတ်သက်၍ ပြောဆိုခြင်းမရှိသေးပါ၊ ၎င်းသည် မပြီးသေးဘဲ၊ ပံ့ပိုးမလုနီးပါးဖြစ်နေသောကြောင့်ဖြစ်သည်။

သို့သော် QUIC သည် Uber တွင် အောင်မြင်စွာ လုပ်ဆောင်ခဲ့သည့် အပလီကေးရှင်းနှင့် ဆာဗာကြား သယ်ယူပို့ဆောင်ရေးတစ်ခုအဖြစ် အကောင်အထည်ဖော်နိုင်သည်-

QUIC အကောင်အထည်ဖော်မှုအပေါ် Uber ၏ မှတ်ချက်

QUIC ကို အောင်မြင်စွာ မြှုပ်နှံပြီး ညံ့ဖျင်းသော ချိတ်ဆက်မှုပတ်ဝန်းကျင်များတွင် အပလီကေးရှင်းများ၏ စွမ်းဆောင်ရည်ကို မြှင့်တင်ရန်အတွက်၊ ကျွန်ုပ်တို့သည် QUIC ပရိုတိုကော (HTTP/2 over TLS/TCP) အဟောင်း (HTTP/XNUMX over TLS/TCP) ကို အစားထိုးပါသည်။ ကျွန်ုပ်တို့သည် ကွန်ရက်စာကြည့်တိုက်ကို အသုံးပြုခဲ့သည်။ ခရိုနက် မှ Chromium ပရောဂျက်များပရိုတိုကော၏ မူရင်း၊ Google ဗားရှင်း - gQUIC ပါရှိသည်။ နောက်ဆုံးပေါ် IETF သတ်မှတ်ချက်ကို လိုက်နာရန် ဤအကောင်အထည်ဖော်မှုကို အဆက်မပြတ် မြှင့်တင်နေပါသည်။

ကျွန်ုပ်တို့သည် Cronet ကို ကျွန်ုပ်တို့၏ အစိတ်အပိုင်းထဲသို့ ပထမဆုံး ပေါင်းစပ်ထည့်သွင်းခဲ့သည် Android-QUIC ပံ့ပိုးမှုထည့်သွင်းရန် အပလီကေးရှင်းများ။ ပြောင်းရွှေ့မှုကုန်ကျစရိတ်များကို လျှော့ချရန်အတွက် ပေါင်းစပ်မှုကို အကောင်အထည်ဖော်ခဲ့သည်။ library ကိုအသုံးပြုထားသော network stack အဟောင်းကို လုံးဝအစားထိုးမည့်အစား OkHttpOkHttp API မူဘောင်အောက်တွင် Cronet ကို ပေါင်းစပ်ထားသည်။ ဤနည်းဖြင့် ပေါင်းစပ်ခြင်းဖြင့် ကျွန်ုပ်တို့၏ကွန်ရက်ခေါ်ဆိုမှုများ (အသုံးပြုသော အပြောင်းအလဲများကို ရှောင်ရှားခဲ့ပါသည်။ ပြန်လည်ပြုပြင်မွမ်းမံခြင်း) API အဆင့်မှာ။

ချဉ်းကပ်ပုံနှင့်ဆင်တူသည် Android-devices များ၊ ကျွန်ုပ်တို့သည် Uber iOS အက်ပ်များတွင် Cronet ကို အကောင်အထည်ဖော်ခဲ့ပြီး ကွန်ရက်မှ HTTP အသွားအလာကို ကြားဖြတ်ခဲ့သည် API ကိုသုံးပြီး NSURLProtocol. iOS ဖောင်ဒေးရှင်းမှ ပံ့ပိုးပေးထားသော ဤ abstraction သည် protocol-specific URL data ကို ကိုင်တွယ်ပြီး Cronet ကို ကျွန်ုပ်တို့၏ iOS အပလီကေးရှင်းများတွင် သိသာထင်ရှားသော ရွှေ့ပြောင်းမှုစရိတ်စကများမပါဘဲ ပေါင်းစပ်ဆောင်ရွက်နိုင်ကြောင်း သေချာစေသည်။

မှယူသည်။ ဤဘာသာပြန်၏ Uber ဆောင်းပါးများ

နောက်ခံတွင်၊ ၎င်းတို့သည် Google Cloud lb မှတစ်ဆင့် QUIC ချိတ်ဆက်မှုများကို ဖမ်းမိခဲ့သည်။ protocol ကိုထောက်ခံပါတယ်။ 2018 နှစ်လယ်ကတည်းက။

Google က ဖန်တီးထားတဲ့ ပရိုတိုကောနဲ့ Google Cloud မှာ ကောင်းကောင်းအလုပ်လုပ်တာ အံ့သြစရာမဟုတ်ပေမယ့် တခြားရွေးချယ်စရာတွေက ဘာတွေလဲ။

Nginx

မကြာသေးမီက CloudFlare ဖြတ်ကျော်ဖို့ ကြိုးစားခဲ့တယ်။ ၎င်း၏ Quiche တူးလ်ဖြင့် nginx (ပုံမှန်အားဖြင့် HTTP/3 ကို မပံ့ပိုးပါ)။ အကောင်အထည်ဖော်မှုကို .patch ဖိုင်တစ်ခုတည်းအဖြစ် ရနိုင်သည်၊ ထည့်သွင်းမှုသင်ခန်းစာတစ်ခုပါရှိသည်-

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.patch

ဤနေရာတွင် လိုအပ်ပါက သင်၏ module များကို ချိတ်ဆက်နိုင်ပါသည်။

./configure                          	
   	--prefix=$PWD                       	
   	--with-http_ssl_module              	
   	--with-http_v2_module               	
   	--with-http_v3_module               	
   	--with-openssl=../quiche/deps/boringssl 
   	--with-quiche=../quiche
 make

ကျန်တာအားလုံးက 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';
    }
}

ပုံမှန်ဘရောက်ဆာများတွင် HTTP/3 မှတဆင့်ချိတ်ဆက်ရန်မဖြစ်နိုင်သေးသော်လည်းသင်ယူနိုင်သည်။ Chrome ကိန္နရီ အလံနှင့်ပြေးလော့ --enable-quicသင့်ဆာဗာကို ဆက်သွယ်ပါ သို့မဟုတ် ဥပမာအားဖြင့်၊ quic.rocks ဆိုက်နှင့် Developer Tools များတွင် ချိတ်ဆက်မှုအမျိုးအစားကို ကြည့်ရှုပါ-

HTTP/3 အစား ၎င်းကို ရေးထားသည်။ http2+quic/99ဒါပေမယ့် အခြေခံအားဖြင့်တော့ အတူတူပါပဲ။

အခြားနည်းပညာများ

QUIC ကိုလည်း ပံ့ပိုးထားသည်။ LiteSpeed (HTTP/3 မှတစ်ဆင့် ကြီးမားသော ပရိသတ်အားပေးမှုဖြင့် Facebook နှင့် ချိတ်ဆက်ထားသည့်) နှင့် တိုးတက်သည်။ CaddyApache သည် မည်သို့မည်ပုံဖြစ်သည်ကို မသိရသေးသော်လည်း အလုပ်ဆက်လုပ်နေပါသည်။ အပြည့်အဝလွှဲ.
ဇန်နဝါရီ ၂၁ ရက်က အပ်ဒိတ်လုပ်ထားသည်။ WebRTC အတွက် စံမူကြမ်း
မနေ့တနေ့ကပဲ Microsoft ဖွင့်တယ်။ ကျွန်ုပ်၏အကောင်အထည်ဖော်မှု msquic ၏ကုဒ်IETF စံနှုန်းမှ ရရှိနိုင်သော လုပ်ဆောင်ချက်များ အားလုံး မပါဝင်သေးသော်လည်း ၎င်းသည် ကြီးမားသော အောင်မြင်မှုများ ဖြစ်နေပါပြီ။

ကောက်ချက်

QUIC ကို စိတ်ဝင်စားမှုသည် မတည်ငြိမ်သော်လည်း ကြီးထွားလာပြီး ၎င်းကို စံသတ်မှတ်ရန် လုပ်ဆောင်နေပါသည်။ ပရိုတိုကော၏ အကောင်အထည်ဖော်မှုအသစ်များသည် လတိုင်းလိုလိုပေါ်လာပြီး နှစ်စဉ်အနာဂတ်သည် QUIC နှင့်သက်ဆိုင်သည်ဟု ဆော့ဖ်ဝဲရေးသားသူ ပိုများလာသည်ဟု ယုံကြည်ကြသည်။ TCP stack ၏အနာဂတ်ဗားရှင်းများတွင် ပရိုတိုကောကိုထည့်သွင်းရန်ပင် ဖြစ်နိုင်သည်၊ ဆိုလိုသည်မှာ မကြာမီ သို့မဟုတ် နောက်ပိုင်းတွင် အင်တာနက်တစ်ခုလုံးသည် ပိုမိုတည်ငြိမ်ပြီး ပိုမိုမြန်ဆန်သော ချိတ်ဆက်မှုများသို့ ပြောင်းရွှေ့သွားမည်ဖြစ်သည်။

သင်၏အခြေခံအဆောက်အအုံအတွက် QUIC အပြန်အလှန်တုံ့ပြန်မှုကို သင်သတ်မှတ်နိုင်သည် သို့မဟုတ် ၎င်းကိုဘရောက်ဆာများသို့ပင် ပေးဆောင်နိုင်သည် - ၎င်းတို့အားလုံးသည် ပရိုတိုကောအတွက် ပံ့ပိုးမှုထည့်ရန်စီစဉ်ထားပြီး၊ caniuse ပါသော ဝမ်းနည်းစရာစာရင်းဇယားများသည် ပိုမိုရွှင်လန်းလာမည်ဖြစ်သည်။

source: www.habr.com