Cloudflare ကုမ္ပဏီ NGINX ရှိ HTTP/3 ပရိုတိုကောအတွက် ပံ့ပိုးမှုပေးရန်။ မော်ဂျူးကို Cloudflare မှ ဖန်တီးထားသည့် စာကြည့်တိုက်အတွက် အပိုပရိုဂရမ်တစ်ခုအဖြစ် ဒီဇိုင်းထုတ်ထားသည်။ QUIC နှင့် HTTP/3 သယ်ယူပို့ဆောင်ရေးပရိုတိုကောကို အကောင်အထည်ဖော်ခြင်းဖြင့်။ quiche ကုဒ်ကို Rust ဖြင့်ရေးသားထားသော်လည်း NGINX module ကိုယ်တိုင်က C ဖြင့်ရေးသားထားပြီး dynamic linking ကိုအသုံးပြု၍ စာကြည့်တိုက်သို့ဝင်ရောက်သည်။ တိုးတက်မှုများ BSD လိုင်စင်အောက်တွင်။
စုစည်းရန်၊ ဒေါင်းလုဒ်လုပ်ရုံပါပဲ။ nginx 1.16 နှင့် quiche စာကြည့်တိုက်များ၊ ထို့နောက် “—with-http_v3_module —with-quiche=../quiche” ရွေးချယ်မှုများဖြင့် nginx ကို ပြန်လည်တည်ဆောက်ပါ။ တည်ဆောက်သည့်အခါ၊ TLS ပံ့ပိုးမှုသည် BoringSSL စာကြည့်တိုက် (“--with-openssl=../quiche/deps/boringssl”) ပေါ်တွင် အခြေခံသင့်သည်၊ OpenSSL ကိုအသုံးပြုခြင်းကို မပံ့ပိုးရသေးပါ။ ချိတ်ဆက်မှုများကို လက်ခံရန်၊ ဆက်တင်များသို့ "quic" အလံဖြင့် နားထောင်ရန် ညွှန်ကြားချက်ကို ပေါင်းထည့်ရန် လိုအပ်သည် (ဥပမာ၊ "443 quic reuseport ကို နားထောင်ပါ")။
ကလိုင်းယင့်ဆော့ဖ်ဝဲတွင် HTTP/3 ပံ့ပိုးမှုကို Chrome Canary နှင့် curl utility ၏ စမ်းသပ်တည်ဆောက်မှုများတွင် ထည့်သွင်းပြီးဖြစ်သည်။ ဆာဗာဘက်တွင်၊ ယခုအချိန်အထိ သီးခြား၊ အကန့်အသတ်ဖြင့် အသုံးပြုရန် လိုအပ်ပါသည်။ . nginx တွင် HTTP/3 ကို စီမံဆောင်ရွက်နိုင်မှုသည် HTTP/3 ပံ့ပိုးမှုဖြင့် ဆာဗာများ၏ ဖြန့်ကျက်မှုကို သိသိသာသာ ရိုးရှင်းစေပြီး ပရိုတိုကောအသစ်၏ စမ်းသပ်အကောင်အထည်ဖော်မှုကို ပိုမိုအသုံးပြုနိုင်စေမည်ဖြစ်သည်။ nginx တွင် HTTP/3 အတွက် စံပံ့ပိုးမှု ပေါ်ပေါက်လာခြင်း 1.17.x အကိုင်းအခက်တွင် 6-12 လ။
HTTP/3 သည် QUIC ပရိုတိုကောကို HTTP/2 အတွက် ပို့ဆောင်မှုအဖြစ် အသုံးပြုခြင်းကို စံသတ်မှတ်ထားကြောင်း သတိရပါ။ ပရိုတိုကော (Quick UDP Internet Connections) ကို ဝဘ်အတွက် TCP+TLS ပေါင်းစပ်မှု၏ အစားထိုးတစ်ခုအဖြစ် Google မှ 2013 ခုနှစ်ကတည်းက တီထွင်ခဲ့ပြီး၊ TCP အတွင်းရှိ ချိတ်ဆက်မှုများအတွက် ရှည်လျားသော တပ်ဆင်မှုနှင့် ညှိနှိုင်းမှုအချိန်များအတွက် ပြဿနာများကို ဖြေရှင်းကာ ဒေတာလွှဲပြောင်းစဉ်အတွင်း ပက်ကတ်များ ပျောက်ဆုံးသွားသည့်အခါ နှောင့်နှေးမှုများကို ဖယ်ရှားပေးခဲ့သည်။ QUIC သည် ချိတ်ဆက်မှုများစွာကို ပေါင်းထည့်ခြင်းကို ပံ့ပိုးပေးသည့် UDP ပရိုတိုကော၏ တိုးချဲ့မှုတစ်ခုဖြစ်ပြီး TLS/SSL နှင့်ညီမျှသော ကုဒ်ဝှက်နည်းလမ်းများကို ပံ့ပိုးပေးပါသည်။
အဓိက QUIC-
- TLS နှင့် ဆင်တူသော လုံခြုံရေး မြင့်မားသည် (အဓိကအားဖြင့် QUIC သည် UDP မှတဆင့် TLS ကို သုံးနိုင်သည်)
- Flow integrity control၊ packet ဆုံးရှုံးမှုကို ကာကွယ်ပေးသည်။
- ချိတ်ဆက်မှုတစ်ခုချက်ချင်းတည်ထောင်နိုင်မှု (0-RTT၊ ခန့်မှန်းခြေအားဖြင့် 75% တွင် ချိတ်ဆက်မှုထည့်သွင်းမှုပက်ကေ့ချ်ကို ပေးပို့ပြီးနောက် ဒေတာကိုချက်ချင်းပို့နိုင်သည်) နှင့် တောင်းဆိုချက်တစ်ခုပေးပို့ခြင်းနှင့် တုံ့ပြန်မှုလက်ခံခြင်းကြားတွင် အနည်းငယ်နှောင့်နှေးမှုများ (RTT၊ အသွားအပြန်အချိန်)၊
- လက်ခံရရှိထားသော ပက်ကေ့ဂျ်များကို ခွဲခြားသတ်မှတ်ရာတွင် မသေချာမရေရာမှုများကို ရှောင်ရှားပြီး အချိန်ကုန်သွားသည့် ပက်ကတ်ကို ပြန်လည်ပေးပို့သည့်အခါ တူညီသော sequence နံပါတ်ကို မသုံးဘဲ၊
- ပက်ကေ့ခ်ျတစ်ခုဆုံးရှုံးခြင်းသည် ၎င်းနှင့်ဆက်စပ်နေသော stream ၏ပေးပို့မှုကိုသာအကျိုးသက်ရောက်ပြီး လက်ရှိချိတ်ဆက်မှုမှတစ်ဆင့်ကူးစက်သောအပြိုင်စီးကြောင်းများတွင်ဒေတာပေးပို့မှုကိုရပ်တန့်မည်မဟုတ်ပါ။
- ပျောက်ဆုံးသွားသောပက်ကေ့ဂျ်များကို ပြန်လည်ပေးပို့ခြင်းကြောင့် နှောင့်နှေးမှုအနည်းဆုံးဖြစ်စေမည့် အမှားပြင်ဆင်ခြင်းအင်္ဂါရပ်များ။ ဆုံးရှုံးသွားသော packet ဒေတာကို ပြန်လည်ပေးပို့ရန် လိုအပ်သည့် အခြေအနေများကို လျှော့ချရန်အတွက် ပက်ကတ်အဆင့်တွင် အထူးအမှားပြင်ဆင်ကုဒ်များကို အသုံးပြုခြင်း။
- Cryptographic block boundaries များသည် QUIC packet boundaries များနှင့် လိုက်လျောညီထွေဖြစ်ပြီး၊ ၎င်းသည် နောက်ဆက်တွဲ packet များ၏ contents ကို decoding တွင် packet ဆုံးရှုံးမှုများ၏ သက်ရောက်မှုကို လျှော့ချပေးပါသည်။
- TCP တန်းစီပိတ်ဆို့ခြင်းတွင် ပြဿနာမရှိပါ။
- မိုဘိုင်းကလိုင်းယင့်များအတွက် ပြန်လည်ချိတ်ဆက်မှုတစ်ခုကို ထူထောင်ရန် လိုအပ်သည့်အချိန်ကို လျှော့ချပေးသည့် ချိတ်ဆက်မှုအမှတ်အသားအတွက် ပံ့ပိုးမှု။
- အဆင့်မြင့် ချိတ်ဆက်မှု ပိတ်ဆို့မှု ထိန်းချုပ်ရေး ယန္တရားများ ချိတ်ဆက်နိုင်ခြေ၊
- ထုပ်ပိုးမှုများကို အကောင်းမွန်ဆုံးသောနှုန်းထားဖြင့် ပို့ကြောင်းသေချာစေရန်၊ ၎င်းတို့အား ပိတ်ဆို့နေပြီး ပက်ကက်ဆုံးရှုံးမှုဖြစ်စေခြင်းမှ ကာကွယ်ရန်၊
- ကုန်ခန်းသည်။ TCP နှင့် နှိုင်းယှဉ်လျှင် စွမ်းဆောင်ရည်နှင့် ဖြတ်သန်းမှု။ YouTube ကဲ့သို့သော ဗီဒီယိုဝန်ဆောင်မှုများအတွက် QUIC သည် ဗီဒီယိုများကိုကြည့်ရှုသည့်အခါ ပြန်လည်တုံ့ပြန်သည့်လုပ်ဆောင်မှုများကို 30% လျှော့ချရန် ပြသထားသည်။
source: opennet.ru