Chrome သည် HTTP/3 ပရိုတိုကောအတွက် စမ်းသပ်ပံ့ပိုးမှုကို ပေါင်းထည့်သည်။

စမ်းသပ်တည်ဆောက်ရန် Chrome ကိန္နရီ ထပ်ပြောသည်။ HTTP/3 ပရိုတိုကောအတွက် ပံ့ပိုးမှု၊ HTTP/XNUMX ပရိုတိုကောကို QUIC ပရိုတိုကောတွင် လုပ်ဆောင်ရန် HTTP အားဖွင့်ရန် အပိုပရိုဂရမ်ကို အကောင်အထည်ဖော်သည်။ QUIC ပရိုတိုကော ကိုယ်တိုင်က လွန်ခဲ့သော ငါးနှစ်က ဘရောင်ဇာသို့ ပေါင်းထည့်ခဲ့ပြီး နောက်ပိုင်းတွင် Google ဝန်ဆောင်မှုများနှင့် ပိုမိုကောင်းမွန်အောင် လုပ်ဆောင်ရန် အသုံးပြုခဲ့သည်။ တစ်ချိန်တည်းမှာပင်၊ Chrome တွင်အသုံးပြုသည့် Google မှ QUIC ဗားရှင်းသည် ဗားရှင်းနှင့်အသေးစိတ်အချက်အချို့တွင် ကွဲပြားသည်။ သတ်မှတ်ချက်များ IETF၊ သို့သော် ယခုအကောင်အထည်ဖော်မှုများသည် ထပ်တူပြုပါသည်။

HTTP/3 သည် QUIC ကို HTTP/2 အတွက် ပို့ဆောင်မှုအဖြစ် စံသတ်မှတ်သည်။ HTTP/3 နှင့် QUIC ရွေးချယ်မှုကို ဖွင့်ရန် ၂၃ ကြမ်း IETF သတ်မှတ်ချက်များသည် "-enable-quic -quic-version=h3-23" ရွေးချယ်မှုများဖြင့် Chrome ကို စတင်ရန် လိုအပ်ပြီး စမ်းသပ်ဆိုက်ကိုဖွင့်သည့်အခါ၊ quick.rocks:4433 developer ကိရိယာများရှိ ကွန်ရက်စစ်ဆေးခြင်းမုဒ်တွင်၊ HTTP/3 လုပ်ဆောင်ချက်ကို “http/2+quic/99” အဖြစ် ပြသပါမည်။

ပရိုတိုကောကို သတိရပါ။ QUIC (Quick UDP Internet Connections) ကို ဝဘ်အတွက် TCP+TLS ပေါင်းစပ်မှု၏ အစားထိုးတစ်ခုအဖြစ် Google မှ 2013 ခုနှစ်ကတည်းက တီထွင်ခဲ့ပြီး၊ TCP ရှိ ချိတ်ဆက်မှုများအတွက် ကြာမြင့်စွာတပ်ဆင်မှုနှင့် ညှိနှိုင်းမှုအချိန်များအတွက် ပြဿနာများကိုဖြေရှင်းကာ ဒေတာလွှဲပြောင်းမှုအတွင်း ပက်ကတ်များပျောက်ဆုံးသွားသည့်အခါ နှောင့်နှေးမှုများကို ဖယ်ရှားပေးခဲ့သည်။ QUIC သည် ချိတ်ဆက်မှုများစွာကို ပေါင်းထည့်ခြင်းကို ပံ့ပိုးပေးသည့် UDP ပရိုတိုကော၏ တိုးချဲ့မှုတစ်ခုဖြစ်ပြီး TLS/SSL နှင့် ညီမျှသော ကုဒ်ဝှက်နည်းလမ်းများကို ပံ့ပိုးပေးပါသည်။ မေးခွန်းထုတ်ထားသော ပရိုတိုကောကို Google ဆာဗာအခြေခံအဆောက်အအုံတွင် ပေါင်းစပ်ထားပြီး Chrome ၏တစ်စိတ်တစ်ပိုင်းဖြစ်သည်။ စီစဉ်ထားသည်။ Firefox တွင်ပါဝင်ရန်အတွက်နှင့် Google ဆာဗာများတွင် client တောင်းဆိုမှုများကို ဆောင်ရွက်ပေးရန်အတွက် တက်ကြွစွာအသုံးပြုပါသည်။

အဓိက အင်္ဂါရပ်များ 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