အင်တာနက်ပရိုတိုကောများနှင့် ဗိသုကာလက်ရာများ ဖွံ့ဖြိုးတိုးတက်မှုအတွက် တာဝန်ရှိသည့် IETF (Internet Engineering Task Force) သည် HTTP/3.0 ပရိုတိုကောအတွက် RFC ကို ဖွဲ့စည်းပြီးမြောက်ပြီး RFC 9114 (ပရိုတိုကော) နှင့် RFC 9204 (သတ်မှတ်သတ်မှတ်မှုအောက်ရှိ ဆက်စပ်သတ်မှတ်ချက်များကို ထုတ်ပြန်ခဲ့သည်။ HTTP/3 အတွက် QPACK ခေါင်းစီးချုံ့နည်းပညာ။ HTTP/3.0 သတ်မှတ်ချက်သည် “အဆိုပြုထားသော စံသတ်မှတ်ချက်” ၏ အခြေအနေကို လက်ခံရရှိထားပြီး၊ ထို့နောက်တွင် အလုပ်သည် RFC အား အမှန်တကယ်ဆိုလိုသည်မှာ ပရိုတိုကော၏ ပြီးပြည့်စုံသော တည်ငြိမ်မှုကို ဆိုလိုပြီး အားလုံးကို ထည့်သွင်းစဉ်းစားသည့် မူကြမ်းစံနှုန်း (Draft Standard) ၏ အခြေအနေကို ပေးမည်ဖြစ်သည်။ မှတ်ချက်များ။ တစ်ချိန်တည်းတွင်၊ HTTP/1.1 (RFC 9112) နှင့် HTTP/2.0 (RFC 9113) ပရိုတိုကောများအတွက် အဆင့်မြှင့်တင်ထားသော ဗားရှင်းများအပြင် HTTP တောင်းဆိုမှုများ (RFC 9110) နှင့် HTTP ကက်ရှ်ထိန်းချုပ်မှု ခေါင်းစီးများကို သတ်မှတ်သည့် စာရွက်စာတမ်းများ (RFC 9111)။
HTTP/3 ပရိုတိုကောသည် QUIC (Quick UDP Internet Connections) ပရိုတိုကောကို HTTP/2 အတွက် ပို့ဆောင်မှုအဖြစ် သတ်မှတ်သည်။ QUIC သည် ချိတ်ဆက်မှုများစွာကို ပေါင်းထည့်ခြင်းကို ပံ့ပိုးပေးသည့် UDP ပရိုတိုကော၏ တိုးချဲ့မှုတစ်ခုဖြစ်ပြီး TLS/SSL နှင့်ညီမျှသော ကုဒ်ဝှက်နည်းလမ်းများကို ပံ့ပိုးပေးပါသည်။ ပရိုတိုကောကို ဝဘ်အတွက် TCP+TLS ပေါင်းစပ်မှု၏ အစားထိုးတစ်ခုအနေဖြင့် Google မှ 2013 ခုနှစ်တွင် ဖန်တီးခဲ့ပြီး၊ ရှည်လျားသောချိတ်ဆက်မှုစနစ်ထည့်သွင်းမှုနှင့် TCP တွင် ညှိနှိုင်းချိန်များနှင့်အတူ ပြဿနာများကိုဖြေရှင်းကာ ဒေတာလွှဲပြောင်းစဉ်အတွင်း ပက်ကတ်များပျောက်ဆုံးသည့်အခါ နှောင့်နှေးမှုများကို ဖယ်ရှားပေးခဲ့သည်။
လက်ရှိတွင်၊ QUIC နှင့် HTTP/3.0 ပံ့ပိုးမှုအား လူကြိုက်များသော ဝဘ်ဘရောက်ဆာများအားလုံးတွင် အကောင်အထည်ဖော်ထားပြီးဖြစ်သည် (Chrome၊ Firefox နှင့် Edge တွင် HTTP/3 ပံ့ပိုးမှုအား မူရင်းအတိုင်းဖွင့်ထားပြီး Safari တွင် ၎င်းသည် "အဆင့်မြင့် > စမ်းသပ်မှုအင်္ဂါရပ်များ > HTTP/3" ဆက်တင်ကို လိုအပ်သည် ဖွင့်ရန်)။ ဆာဗာဘက်တွင် HTTP/3 အကောင်အထည်ဖော်မှုများကို nginx (သီးခြားဌာနခွဲတစ်ခုနှင့် သီးခြား module တစ်ခု၏ပုံစံ)၊ Caddy၊ IIS နှင့် LiteSpeed အတွက် ရရှိနိုင်သည်။ HTTP/3 ပံ့ပိုးမှုကို Cloudflare အကြောင်းအရာပေးပို့ခြင်းကွန်ရက်မှလည်း ပံ့ပိုးပေးပါသည်။
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% လျှော့ချရန် ပြသထားသည်။
HTTP/1.1 သတ်မှတ်ချက်တွင် အပြောင်းအလဲများကြားတွင်၊ အကြောင်းအရာဖြင့် ကိုယ်ထည်အပြင်ဘက်ရှိ carriage return (CR) ဇာတ်ကောင်ကို သီးခြားအသုံးပြုခြင်းအတွက် တားမြစ်ချက်ကို မှတ်သားနိုင်သည်။ ပရိုတိုကောဒြပ်စင်များတွင်၊ CR ဇာတ်ကောင်အား လိုင်းအစာအက္ခရာ (CRLF) နှင့်သာ တွဲဖက်အသုံးပြုနိုင်ပါသည်။ ပူးတွဲပါအကွက်များနှင့် အပိုင်းများကို ခေါင်းစီးများဖြင့် ခွဲထုတ်ခြင်းအား ရိုးရှင်းစေရန် အတုံးလိုက်အခဲလိုက် တောင်းဆိုမှု အပြင်အဆင် အယ်လဂိုရီသမ်ကို မြှင့်တင်ထားပါသည်။ Frontend နှင့် Backend အကြား စီးဆင်းမှုတွင် အခြားအသုံးပြုသူများ၏ တောင်းဆိုမှုများ၏ အကြောင်းအရာအတွင်းသို့ ကျွန်ုပ်တို့ကိုယ်တိုင် ပါဝင်ခွင့်ပြုသည့် “HTTP Request Smuggling” တိုက်ခိုက်မှုများကို ပိတ်ဆို့ရန် မရှင်းလင်းသော အကြောင်းအရာများကို ကိုင်တွယ်ရန် အကြံပြုချက်များ ထည့်သွင်းထားသည်။
HTTP/2.0 သတ်မှတ်ချက် အပ်ဒိတ်သည် TLS 1.3 အတွက် ပံ့ပိုးမှုကို အတိအလင်း သတ်မှတ်သည်။ ဦးစားပေးအစီအစဉ်နှင့် ဆက်စပ်နေသော ခေါင်းစီးအကွက်များကို ရပ်တန့်ထားသည်။ HTTP/1.1 နှင့် ချိတ်ဆက်မှုကို အပ်ဒိတ်လုပ်ရန် အသုံးမပြုသော ယန္တရားသည် အသုံးမပြုတော့ကြောင်း ကြေညာထားသည်။ အကွက်အမည်များနှင့် တန်ဖိုးများကို စစ်ဆေးခြင်းအတွက် လိုအပ်ချက်များကို လျှော့ချထားသည်။ အချို့သော ယခင်က သီးသန့်ဘောင်အမျိုးအစားများနှင့် ကန့်သတ်ချက်များကို အသုံးပြုရန် အဆိုပြုထားသည်။ ချိတ်ဆက်မှုနှင့်ပတ်သက်သော တားမြစ်ထားသော ခေါင်းစီးအကွက်များကို ပိုမိုတိကျစွာသတ်မှတ်ထားသည်။
source: opennet.ru