QUIC (Quick UDP Internet Connections) သည် TCP၊ TLS နှင့် HTTP/2 တို့၏ အင်္ဂါရပ်အားလုံးကို ပံ့ပိုးပေးကာ ၎င်းတို့၏ ပြဿနာအများစုကို ဖြေရှင်းပေးသည့် UDP ၏ထိပ်တွင် ပရိုတိုကောတစ်ခုဖြစ်သည်။ ၎င်းကို အသစ် သို့မဟုတ် "စမ်းသပ်မှု" ပရိုတိုကောဟု မကြာခဏခေါ်သော်လည်း ၎င်းသည် စမ်းသပ်ဆဲအဆင့်ကို ကြာရှည်စွာ သက်တမ်းတိုးခဲ့သည်- ဖွံ့ဖြိုးတိုးတက်မှုသည် 7 နှစ်ကျော်ကြာ ဆက်လက်လုပ်ဆောင်နေခဲ့သည်။ ထိုအချိန်တွင်၊ ပရိုတိုကောသည် စံတစ်ခုဖြစ်လာရန် မစီမံခဲ့သော်လည်း ကျယ်ပြန့်လာသည်။ ဥပမာအားဖြင့်၊ QUIC ကို Google နှင့် Facebook ကဲ့သို့သော ကုမ္ပဏီကြီးများက မိုဘိုင်းကွန်ရက်များတွင် အသွားအလာကို အရှိန်မြှင့်ရန်နှင့် နှောင့်နှေးမှုများကို လျှော့ချရန်အတွက် အသုံးပြုကြပြီး IETF သည် HTTP/3 စံနှုန်းအတွက် အခြေခံအဖြစ် HTTP/2 ကို အသုံးပြုသော်လည်း၊ ဆိုဒ်များ)။
ခံယူချက်
QUIC သည် ဆုံးရှုံးမှုနည်းသော ဝိုင်ယာကြိုးကွန်ရက်များအတွက် မူလက ဒီဇိုင်းထုတ်ထားသည့် အမွေအနှစ် TCP အတွက် အစားထိုးအဖြစ် တီထွင်ခဲ့သည်။ TCP သည် packet များကို အစီအစဉ်တကျ ပို့ဆောင်ပေးသည်၊ ထို့ကြောင့် packet တစ်ခု ပျောက်ဆုံးပါက၊ တန်းစီတစ်ခုလုံးကို ရပ်သွားသည် () ချိတ်ဆက်မှု၏ အရည်အသွေးနှင့် တည်ငြိမ်မှုကို ထိခိုက်စေသည်။ ကြီးမားသောဆုံးရှုံးမှုများကိုရှောင်ရှားရန်၊ ဆယ်လူလာကွန်ရက်များသည် ကြီးမားသောကြားခံများကိုအသုံးပြုရန် အားကိုးအားထားပြုကြပြီး၊ ၎င်းသည် ပရိုတိုကော၏ ထပ်လောင်းခြင်းနှင့် မှားယွင်းသောတုံ့ပြန်မှုကိုဖြစ်ပေါ်စေသည် () ထို့အပြင်၊ TCP သည် ချိတ်ဆက်မှုတစ်ခုထူထောင်ရန် အချိန်များစွာဖြုန်းသည်- SYN/ACK နှင့် TLS တောင်းဆိုမှုများကို သီးခြားစီလုပ်ဆောင်ပြီး QUIC ကဲ့သို့ တစ်ကြိမ်အစား အသွားအပြန်သုံးကြိမ် လိုအပ်သည်။
QUIC သည် TCP အစားထိုးခြင်းနှင့် TLS 1.3 ကို အကောင်အထည်ဖော်ခြင်းတို့ကို ပေါင်းစပ်ထားသောကြောင့် ချိတ်ဆက်မှုများအားလုံးကို အမြဲတမ်း ကုဒ်ဝှက်ထားပြီး၊ ထိုလမ်းကြောင်းကို ကုဒ်ဝှက်ခြင်းသည် HTTPS ကို ကျော်သွားပါကထက် မလွယ်ကူပါ။ ထို့အပြင်၊ TCP stack ၏ အပြီးသတ် အစားထိုးမှုအဖြစ် QUIC ကို လျှောက်လွှာအဆင့်တွင် အကောင်အထည်ဖော်ပါသည်။ ထာဝရ.
HTTP/2 တွင် multiplexing ကို ပံ့ပိုးပေးသော်လည်း၊ packet များကို အစီအစဉ်တကျ ပို့ဆောင်ရန် လိုအပ်ခြင်းကြောင့် ထိပ်ပိုင်းပိတ်ဆို့ခြင်း ပြဿနာသည် ထိုနေရာတွင် ရှိနေခဲ့သည်။ QUIC သည် UDP ၏ထိပ်တွင် အကောင်အထည်ဖော်ထားသောကြောင့် ၎င်းတွင်မူအရပိတ်ဆို့ခြင်းမျိုးမရှိသည့်အပြင် packet များကို ထာဝရပျောက်ဆုံးခြင်းမှကာကွယ်ရန် ၎င်းတို့ကို နံပါတ်တပ်ထားပြီး အပိုပစ္စည်းများပါရှိသော "အိမ်နီးနားချင်းများ" ၏ အစိတ်အပိုင်းများပါရှိပါသည်။ ထို့အပြင်၊ 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) ကို အစားထိုးပါသည်။ ကျွန်ုပ်တို့သည် ကွန်ရက်စာကြည့်တိုက်ကို အသုံးပြုခဲ့သည်။ မှ ပရိုတိုကော၏ မူရင်း၊ Google ဗားရှင်း - gQUIC ပါရှိသည်။ နောက်ဆုံးပေါ် IETF သတ်မှတ်ချက်ကို လိုက်နာရန် ဤအကောင်အထည်ဖော်မှုကို အဆက်မပြတ် မြှင့်တင်နေပါသည်။
ကျွန်ုပ်တို့သည် QUIC အတွက် ပံ့ပိုးမှုပေါင်းထည့်ရန် Cronet ကို ကျွန်ုပ်တို့၏ Android အက်ပ်များတွင် ပထမဆုံး ပေါင်းစပ်ထားသည်။ ရွှေ့ပြောင်းသွားလာမှုစရိတ်များကို တတ်နိုင်သမျှ လျှော့ချရန် ပေါင်းစည်းခြင်းကို ဆောင်ရွက်ခဲ့ပါသည်။ ဒစ်ဂျစ်တိုက်ကို အသုံးပြုခဲ့သည့် ကွန်ရက်စနစ်ဟောင်းကို လုံးဝ အစားထိုးမည့်အစား၊ OkHttp API မူဘောင်အောက်တွင် Cronet ကို ပေါင်းစပ်ထားသည်။ ဤနည်းဖြင့် ပေါင်းစပ်ခြင်းဖြင့် ကျွန်ုပ်တို့၏ကွန်ရက်ခေါ်ဆိုမှုများ (အသုံးပြုသော အပြောင်းအလဲများကို ရှောင်ရှားခဲ့ပါသည်။ ) API အဆင့်မှာ။
Android စက်ပစ္စည်းများအတွက် ချဉ်းကပ်ပုံအတိုင်း၊ Cronet ကို iOS ပေါ်ရှိ Uber အက်ပ်များတွင် ထည့်သွင်းပြီး ကွန်ရက်မှ HTTP လမ်းကြောင်းကို ကြားဖြတ်တားဆီးခြင်း သုံးပြီး . iOS ဖောင်ဒေးရှင်းမှ ပံ့ပိုးပေးထားသော ဤ abstraction သည် protocol-specific URL data ကို ကိုင်တွယ်ပြီး Cronet ကို ကျွန်ုပ်တို့၏ iOS အပလီကေးရှင်းများတွင် သိသာထင်ရှားသော ရွှေ့ပြောင်းမှုစရိတ်စကများမပါဘဲ ပေါင်းစပ်ဆောင်ရွက်နိုင်ကြောင်း သေချာစေသည်။
မှယူသည်။ Uber ဆောင်းပါးများ
နောက်ကွယ်တွင် ၎င်းတို့သည် Google Cloud lb မှတစ်ဆင့် QUIC ချိတ်ဆက်မှုများကို ဖမ်းမိခဲ့သည်။ 2018 နှစ်လယ်ကတည်းက။
Google Cloud သည် Google-developed protocol နှင့် ကောင်းမွန်စွာအလုပ်လုပ်သည်ကို အံ့သြစရာမဟုတ်ပါ၊ သို့သော် အခြားရွေးချယ်စရာများကား အဘယ်နည်း။
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 မှတစ်ဆင့် ချိတ်ဆက်ရန် မဖြစ်နိုင်သေးသော်လည်း သင်အသုံးပြုနိုင်ပါသည်။ အလံနှင့်ပြေးလော့ --enable-quicသင့်ဆာဗာသို့သွားပါ သို့မဟုတ် ဥပမာအားဖြင့် quic.rocks ဆိုက်ကိုသွားပြီး Developer Tools အတွင်းရှိ ချိတ်ဆက်မှုအမျိုးအစားကိုကြည့်ပါ-
HTTP/3 အစား ၎င်းကို ရေးထားသည်။ http2+quic/99ဒါပေမယ့် အခြေခံအားဖြင့်တော့ အတူတူပါပဲ။
အခြားနည်းပညာများ
- QUIC ကိုလည်း ပံ့ပိုးပေးပါတယ်။ (HTTP/3 မှတဆင့် Facebook နှင့် ချိတ်ဆက်ထားသည့် အလွန်ကောင်းမွန်သော ပရိသတ်အားပေးမှုဖြင့်) နှင့် တိုးတက်သည်။ . Apache သည် ၎င်းကို မလုပ်ဆောင်နိုင်သေးသော်လည်း လုပ်ဆောင်နေဆဲဖြစ်သည်။ .
- ဇန်နဝါရီ 21 တွင် အပ်ဒိတ်လုပ်ထားသည်။
- မနေ့တနေ့ကပဲ Microsoft ဖွင့်တယ်။ IETF စံနှုန်းမှ လုပ်ဆောင်ချက်များအားလုံးကို မရရှိနိုင်သေးသော်လည်း ၎င်းသည် ကြီးမားသော အောင်မြင်မှုတစ်ခု ဖြစ်နေပါပြီ။
ကောက်ချက်
QUIC ကို စိတ်ဝင်စားမှုသည် မတည်ငြိမ်သော်လည်း ကြီးထွားလာပြီး ၎င်းကို စံချိန်စံညွှန်းသတ်မှတ်ရန် လုပ်ဆောင်နေပါသည်။ ပရိုတိုကော၏ အကောင်အထည်ဖော်မှုအသစ်များသည် လတိုင်းလိုလိုပေါ်လာပြီး QUIC သည် အနာဂတ်ဖြစ်သည်ကို နှစ်တိုင်း developer များက ယုံကြည်လက်ခံလာကြသည်။ TCP stack ၏အနာဂတ်ဗားရှင်းများတွင် ပရိုတိုကောကိုထည့်သွင်းရန်ပင် ဖြစ်နိုင်သည်၊ ဆိုလိုသည်မှာ မကြာမီ သို့မဟုတ် နောက်ပိုင်းတွင် အင်တာနက်တစ်ခုလုံးသည် ပိုမိုတည်ငြိမ်ပြီး ပိုမိုမြန်ဆန်သော ချိတ်ဆက်မှုများသို့ ပြောင်းရွှေ့သွားမည်ဖြစ်သည်။
ယခု သင်သည် သင်၏အခြေခံအဆောက်အအုံအတွက် QUIC အပြန်အလှန်တုံ့ပြန်မှုကို စီစဉ်သတ်မှတ်နိုင်သည် သို့မဟုတ် ၎င်းကိုဘရောက်ဆာများသို့ပင် ပေးဆောင်နိုင်သည် - ၎င်းတို့အားလုံးသည် ပရိုတိုကောအတွက် ပံ့ပိုးမှုထည့်ရန် စီစဉ်နေပြီး၊ caniuse နှင့် ဝမ်းနည်းစရာစာရင်းဇယားများသည် ပိုမိုရွှင်လန်းလာမည်ဖြစ်သည်။
source: www.habr.com