Firefox သည် မေလကုန်တွင် HTTP/3 ပံ့ပိုးမှုကို စတင်နိုင်မည်ဟု မျှော်လင့်ရသည်။

Mozilla သည် ဧပြီလ 3 ရက်နေ့တွင် စီစဉ်ထားသော Firefox 88 ဖြန့်ချိမှုဖြင့် HTTP/19 နှင့် QUIC တွင် အဆင့်မြှင့်တင်ရန် ၎င်း၏ရည်ရွယ်ချက်ကို ကြေညာခဲ့သည် (မူလက ဧပြီလ 20 ရက်နေ့တွင် ဖြန့်ချိရန် မျှော်လင့်ထားသော်လည်း အချိန်ဇယားအရ ဆုံးဖြတ်ပါက ၎င်းကို တစ်ရက်အတွင်း ပြန်ရွှေ့မည်)။ HTTP/3 ပံ့ပိုးကူညီမှုသည် ကနဦးအသုံးပြုသူ အနည်းငယ်သာရှိမည်ဖြစ်ပြီး၊ မမျှော်လင့်ထားသော ပြဿနာများကို တားဆီးခြင်းဖြင့် မေလကုန်တွင် လူတိုင်းအား စတင်အသုံးပြုနိုင်မည်ဖြစ်သည်။ ညစဉ်တည်ဆောက်မှုများနှင့် beta ဗားရှင်းများတွင်၊ HTTP/3 ကို မတ်လကုန်တွင် ပုံမှန်အားဖြင့် ဖွင့်ထားသည်။

Firefox တွင် HTTP/3 ကို အကောင်အထည်ဖော်ခြင်းသည် QUIC ပရိုတိုကောအတွက် client နှင့် server အကောင်အထည်ဖော်မှုကို ပံ့ပိုးပေးသည့် Mozilla မှ ဖန်တီးထားသည့် neqo ပရောဂျက်အပေါ် အခြေခံထားကြောင်း သတိရကြပါစို့။ HTTP/3 နှင့် QUIC ပံ့ပိုးမှုအတွက် အစိတ်အပိုင်းကုဒ်ကို Rust တွင် ရေးသားထားသည်။ HTTP/3 ကို ဖွင့်ထားခြင်း ရှိမရှိ ထိန်းချုပ်ရန်၊ about:config သည် “network.http.http3.enabled” ရွေးချယ်မှုကို ပေးသည်။ client software မှ HTTP/3 အတွက် စမ်းသပ်ပံ့ပိုးမှုအား Chrome နှင့် curl တွင် ပေါင်းထည့်ထားပြီး ဆာဗာများအတွက် ၎င်းကို nginx နှင့် nginx module ၏ပုံစံနှင့် Cloudflare မှ စမ်းသပ်ဆာဗာပုံစံဖြင့် ရရှိနိုင်ပါသည်။ ဝဘ်ဆိုက်ဘက်တွင် HTTP/3 ပံ့ပိုးမှုကို Google နှင့် Facebook ဆာဗာများတွင် ပေးထားပြီးဖြစ်သည်။

HTTP/3 ပရိုတိုကောသည် မူကြမ်းသတ်မှတ်ချက်အဆင့်တွင်ရှိနေဆဲဖြစ်ပြီး IETF မှ အပြည့်အဝစံသတ်မှတ်ခြင်းမရှိသေးပါ။ HTTP/3 သည် Alt-Svc ခေါင်းစီးတွင်ဖော်ပြထားသည့် QUIC မူကြမ်းစံနှုန်းနှင့် HTTP/3 ၏တူညီသောဗားရှင်းအတွက် client နှင့် server ပံ့ပိုးမှုလိုအပ်သည် (Firefox သည် spec မူကြမ်း 27 မှ 32 ကိုပံ့ပိုးသည်)။

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

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

မှတ်ချက် Add