HTTP/3- မြေပြင်ကို ဖြိုခွင်းပြီး သတ္တိရှိသော ကမ္ဘာသစ်

ကျွန်ုပ်တို့သည် HTTP ပရိုတိုကောကို အသုံးပြု၍ ဝဘ်စာမျက်နှာများကို ကြည့်ရှုနေသည်မှာ အနှစ် 20 ကျော်ရှိပြီဖြစ်သည်။ အသုံးပြုသူအများစုသည် ၎င်းသည် မည်သည့်အရာနှင့် မည်သို့အလုပ်လုပ်ကြောင်းကိုပင် မစဉ်းစားကြပေ။ HTTP အောက်တွင် တစ်နေရာတွင် TLS ရှိကြောင်း၊ ၎င်းအောက်တွင် TCP ဖြစ်သည်၊ IP အောက်တွင် စသည်တို့ဖြစ်သည်။ ထို့အပြင် အခြားသူများ - မိစ္ဆာဒိဌိများ - TCP သည် အတိတ်မှအရာဖြစ်သည်ဟု ယုံကြည်ကြပြီး ၎င်းတို့သည် ပိုမိုမြန်ဆန်၊ ပိုမိုစိတ်ချရပြီး လုံခြုံသော အရာတစ်ခုကို လိုချင်ကြသည်။ သို့သော် စံပြပရိုတိုကောအသစ်တစ်ခုကို တီထွင်ရန် ၎င်းတို့၏ကြိုးပမ်းမှုများတွင်၊ ၎င်းတို့သည် 80s ၏နည်းပညာသို့ ပြန်လည်ရောက်ရှိလာပြီး ၎င်းတို့၏ရဲရင့်သောကမ္ဘာသစ်ကို တည်ဆောက်ရန် ကြိုးစားနေကြသည်။

မှတ်တမ်းအနည်းငယ်- HTTP/1.1

1997 ခုနှစ်တွင်၊ စာသားအချက်အလက်ဖလှယ်ရေးပရိုတိုကော HTTP ဗားရှင်း 1.1 သည် ၎င်း၏ကိုယ်ပိုင် RFC ကို ရယူခဲ့သည်။ ထိုအချိန်တွင်၊ ပရိုတိုကောကို ဘရောက်ဆာများက နှစ်အတော်ကြာ အသုံးပြုခဲ့ပြီး စံနှုန်းသစ်သည် နောက်ထပ် ဆယ့်ငါးခု ကြာမြင့်ခဲ့သည်။ ပရိုတိုကောသည် တောင်းဆိုချက်-တုံ့ပြန်မှု နိယာမပေါ်တွင်သာ လုပ်ဆောင်ခဲ့ပြီး စာသားအချက်အလက်များ ပေးပို့ခြင်းအတွက် အဓိကရည်ရွယ်ပါသည်။

HTTP သည် TCP ပရိုတိုကော၏ထိပ်တွင် အလုပ်လုပ်ရန် ဒီဇိုင်းထုတ်ထားပြီး packet များကို ၎င်းတို့၏ဦးတည်ရာသို့ စိတ်ချယုံကြည်စွာ ပို့ဆောင်ကြောင်းသေချာစေပါသည်။ TCP သည် endpoints များကြား ယုံကြည်စိတ်ချရသောချိတ်ဆက်မှုကို ထူထောင်ပြီး ထိန်းသိမ်းခြင်းဖြင့် လမ်းကြောင်းများကို အပိုင်းများခွဲကာ လုပ်ဆောင်သည်။ အပိုင်းများသည် ၎င်းတို့၏ကိုယ်ပိုင်နံပါတ်နှင့် checksum ရှိသည်။ အကယ်၍ အပိုင်းတစ်ခုမှ ရုတ်တရက် မရောက်ပါက သို့မဟုတ် မမှန်သော စစ်ဆေးမှုတစ်ခုဖြင့် ရောက်ရှိလာပါက၊ ဆုံးရှုံးသွားသော အပိုင်းကို ပြန်လည်မရရှိမချင်း ထုတ်လွှင့်မှု ရပ်တန့်သွားမည်ဖြစ်သည်။

HTTP/1.0 တွင်၊ တောင်းဆိုမှုတစ်ခုစီပြီးနောက် TCP ချိတ်ဆက်မှုကို ပိတ်ခဲ့သည်။ ဒါဟာ အလွန်ဖြုန်းတီးခဲ့တာပါ... TCP ချိတ်ဆက်မှု (3-Way-Handshake) ထူထောင်ခြင်းသည် နှေးကွေးသော လုပ်ငန်းစဉ်ဖြစ်သည်။ HTTP/1.1 သည် တောင်းဆိုချက်များစွာအတွက် ချိတ်ဆက်မှုတစ်ခုအား ပြန်သုံးနိုင်စေမည့် Keep-alive ယန္တရားကို မိတ်ဆက်ပေးခဲ့သည်။ သို့သော်၊ ၎င်းသည် အလွယ်တကူ ပိတ်ဆို့မှုတစ်ခု ဖြစ်လာနိုင်သောကြောင့် HTTP/1.1 ၏ အမျိုးမျိုးသော အကောင်အထည်ဖော်မှုများသည် TCP ချိတ်ဆက်မှုများကို တစ်ခုတည်းသော host သို့ ဖွင့်ခွင့်ပြုထားသည်။ ဥပမာအားဖြင့်၊ Chrome နှင့် Firefox ၏ လတ်တလောဗားရှင်းများသည် ချိတ်ဆက်မှု ခြောက်ခုအထိ ခွင့်ပြုသည်။

ကုဒ်ဝှက်ခြင်းအား အခြားပရိုတိုကောများတွင် ချန်ထားရမည်ဖြစ်ပြီး ၎င်းအတွက် TLS ပရိုတိုကောသည် ဒေတာကို စိတ်ချယုံကြည်စွာ ကာကွယ်ပေးထားသည့် TCP ကို ​​အသုံးပြုခဲ့သော်လည်း ချိတ်ဆက်မှုတစ်ခုတည်ဆောက်ရန် လိုအပ်သည့်အချိန်ကို ပိုမိုတိုးမြှင့်ခဲ့သည်။ ရလဒ်အနေဖြင့် လက်ဆွဲနှုတ်ဆက်ခြင်း လုပ်ငန်းစဉ်သည် ဤကဲ့သို့ စတင်လာသည်-

Cloudflare သရုပ်ဖော်ပုံ

ထို့ကြောင့် HTTP/1.1 တွင် ပြဿနာများစွာရှိသည်။

• နှေးကွေးသော ချိတ်ဆက်မှု စနစ်ထည့်သွင်းခြင်း။
• ဒေတာကို စာသားပုံစံဖြင့် ပေးပို့ခြင်းဖြစ်ပြီး၊ ဆိုလိုသည်မှာ ရုပ်ပုံများ၊ ဗီဒီယိုများနှင့် အခြားစာသားမဟုတ်သော အချက်အလက်များကို ပေးပို့ခြင်းမှာ ထိရောက်မှု မရှိပေ။
• တောင်းဆိုချက်တစ်ခုအတွက် TCP ချိတ်ဆက်မှုတစ်ခုအား အသုံးပြုသည်၊ ဆိုလိုသည်မှာ အခြားတောင်းဆိုမှုများသည် အခြားချိတ်ဆက်မှုကို ရှာဖွေရမည် သို့မဟုတ် လက်ရှိတောင်းဆိုချက်မထုတ်ပြန်မီအထိ စောင့်ရမည်ဖြစ်သည်။
• ဆွဲမော်ဒယ်ကိုသာ ပံ့ပိုးထားသည်။ server-push နှင့်ပတ်သက်ပြီး စံသတ်မှတ်ချက်တွင် ဘာမှမရှိပါ။
• ခေါင်းစီးများကို စာသားဖြင့် ပေးပို့ပါသည်။

Server-push ကို အနည်းဆုံး WebSocket ပရိုတိုကောကို အသုံးပြုပြီး လုပ်ဆောင်ပါက ကျန်ပြဿနာများကို ပိုမိုပြင်းထန်စွာ ဖြေရှင်းရမည်ဖြစ်သည်။

အနည်းငယ် ခေတ်မီမှု- HTTP/2

2012 ခုနှစ်တွင် Google သည် SPDY (အသံထွက် "မြန်ဆန်") ပရိုတိုကောကို စတင်လုပ်ဆောင်ခဲ့သည်။ ပရိုတိုကောသည် HTTP/1.1 ၏ အဓိကပြဿနာများကို ဖြေရှင်းရန်အတွက် ဒီဇိုင်းထုတ်ထားပြီး တစ်ချိန်တည်းတွင် နောက်ပြန်လိုက်ဖက်မှုကို ထိန်းသိမ်းထားရန် လိုအပ်သည်။ 2015 ခုနှစ်တွင် IETF အလုပ်အဖွဲ့သည် SPDY ပရိုတိုကောကို အခြေခံ၍ HTTP/2 သတ်မှတ်ချက်ကို မိတ်ဆက်ခဲ့သည်။ ဤသည်မှာ HTTP/2 ၏ ခြားနားချက်များဖြစ်သည် ။

• ဒွိအမှတ်စဉ်။
• တစ်ခုတည်းသော TCP ချိတ်ဆက်မှုတွင် HTTP တောင်းဆိုချက်များစွာကို ပေါင်းထည့်ခြင်း။
• ဆာဗာကို ဘောက်စ် (WebSocket မပါဘဲ) မှ တွန်းထုတ်ပါ။

ပရိုတိုကောသည် ရှေ့သို့ ခြေလှမ်းကြီးလှမ်းခဲ့သည်။ သူက ပြင်းပြင်းထန်ထန် ပထမဗားရှင်းကို အမြန်နှုန်းနဲ့ ကျော်တယ်။ များစွာသော TCP ချိတ်ဆက်မှုများ ဖန်တီးရန် မလိုအပ်ပါ- host တစ်ခုသို့ တောင်းဆိုမှုအားလုံးကို တစ်ခုထဲသို့ ပေါင်းထည့်ပါသည်။ ဆိုလိုသည်မှာ၊ ချိတ်ဆက်မှုတစ်ခုတွင်၊ တစ်ခုချင်းစီတွင်၎င်း၏ကိုယ်ပိုင် ID ပါ ၀ င်သောလမ်းကြောင်းများဟုခေါ်ဝေါ်သောလမ်းကြောင်းများစွာရှိသည်။ ဘောနပ်စ်သည် ဘောက်စ်ဆာဗာ တွန်းပို့မှုတစ်ခုဖြစ်သည်။

သို့သော်၊ multiplexing သည် နောက်ထပ်သော့ချက်ပြဿနာတစ်ခုဆီသို့ ဦးတည်သည်။ ကျွန်ုပ်တို့သည် ဆာဗာတစ်ခုသို့ တောင်းဆိုချက် 5 ခုကို တပြိုင်တည်းလုပ်ဆောင်နေသည်ဟု မြင်ယောင်ကြည့်ပါ။ HTTP/2 ကိုအသုံးပြုသည့်အခါ၊ ဤတောင်းဆိုချက်အားလုံးကို တူညီသော TCP ချိတ်ဆက်မှုအတွင်း လုပ်ဆောင်သွားမည်ဖြစ်ပြီး ဆိုလိုသည်မှာ တောင်းဆိုချက်တစ်ခုမှ အစိတ်အပိုင်းတစ်ခု ပျောက်ဆုံးသွားပါက သို့မဟုတ် မမှန်မကန် လက်ခံရရှိပါက၊ ဆုံးရှုံးသွားသည့်အပိုင်းအထိ တောင်းဆိုချက်များနှင့် တုံ့ပြန်မှုများအားလုံးကို ပေးပို့ခြင်းမှာ ရပ်သွားမည်ဖြစ်သည်။ ပြန်လည်သိမ်းဆည်းခဲ့သည်။ ချိတ်ဆက်မှုအရည်အသွေး ပိုဆိုးလေ၊ HTTP/2 နှေးလေ အလုပ်လုပ်သည်။ Daniel Stenberg ၏ ပြောကြားချက်အရ သိရသည်။အထုပ်အားလုံး၏ 2% ဆုံးရှုံးသွားသော အခြေအနေများတွင်၊ ဘရောက်ဆာရှိ HTTP/1.1 သည် တစ်ခုထက်မက ချိတ်ဆက်မှု 2 ခုကို ဖွင့်ထားသောကြောင့် HTTP/6 ထက် ပိုမိုကောင်းမွန်ပါသည်။

ဤပြဿနာကို "head-of-line blocking" ဟုခေါ်ပြီး ကံမကောင်းစွာဖြင့်၊ TCP ကိုအသုံးပြုသည့်အခါ ၎င်းကိုဖြေရှင်းရန်မဖြစ်နိုင်ပါ။

Daniel Steinberg ၏ သရုပ်ဖော်ပုံ

ရလဒ်အနေဖြင့် HTTP/2 စံသတ်မှတ်ချက်၏ developer များသည် ကောင်းမွန်သောအလုပ်များကို လုပ်ဆောင်ခဲ့ပြီး OSI မော်ဒယ်၏ အပလီကေးရှင်းအလွှာတွင် လုပ်ဆောင်နိုင်သည့် အရာအားလုံးနီးပါးကို လုပ်ဆောင်ခဲ့သည်။ သယ်ယူပို့ဆောင်ရေးအလွှာသို့ဆင်းပြီး သယ်ယူပို့ဆောင်ရေးပရိုတိုကောအသစ်တစ်ခုကို တီထွင်ရန် အချိန်တန်ပြီ။

ကျွန်ုပ်တို့သည် ပရိုတိုကောအသစ်တစ်ခု လိုအပ်သည်- UDP နှင့် TCP

သယ်ယူပို့ဆောင်ရေးအလွှာပရိုတိုကောအသစ်ကို အကောင်အထည်ဖော်ခြင်းသည် ယနေ့ခေတ်လက်တွေ့အခြေအနေများတွင် မဖြစ်နိုင်သောအလုပ်တစ်ခုဖြစ်ကြောင်း လျင်မြန်စွာ သိသာလာသည်။ အမှန်မှာ ဟာ့ဒ်ဝဲ သို့မဟုတ် အလယ်အလတ်ဘောက်စ်များ (router၊ firewalls၊ NAT ဆာဗာများ ...) သည် သယ်ယူပို့ဆောင်ရေးအလွှာအကြောင်း သိပြီး ၎င်းတို့အား အသစ်အဆန်းတစ်ခုခု သင်ပေးခြင်းသည် အလွန်ခက်ခဲသော အလုပ်ဖြစ်သည်။ ထို့အပြင်၊ သယ်ယူပို့ဆောင်ရေးပရိုတိုကောများအတွက် ပံ့ပိုးမှုသည် လည်ပတ်မှုစနစ်များ၏ ကာနယ်တွင် တည်ဆောက်ထားပြီး kernels များသည်လည်း ပြောင်းလဲရန် ဆန္ဒမရှိပေ။

ပြီးတော့ ဒီနေရာမှာ တစ်ယောက်ယောက်က လက်မြှောက်ပြီးပြောနိုင်တယ် "ဟုတ်ပါတယ်၊ ငါတို့က HTTP/3 ကို ဦးစားပေးပြီး ရိုသေလေးစားမှုတွေနဲ့ တီထွင်လိမ့်မယ်၊ ဒါပေမယ့် အကောင်အထည်ဖော်ဖို့ 10-15 နှစ်လောက် အချိန်ယူရလိမ့်မယ်။ အစားထိုးသည်)” ၊ သို့သော်နောက်ထပ်တစ်ခုရှိသေးသည်မဟုတ်သောကြောင့်သိသာထင်ရှားသောရွေးချယ်မှုသည် UDP ပရိုတိုကောကိုအသုံးပြုရန်ဖြစ်သည်။ ဟုတ်တယ်၊ ဟုတ်တယ်၊ ကိုးဆယ်ကျော်နှောင်းပိုင်းနဲ့ XNUMX အစောပိုင်းတွေမှာ LAN မှာ ဖိုင်တွေကို လွှင့်ပစ်ခဲ့တဲ့ တူညီတဲ့ ပရိုတိုကော။ ယနေ့ခေတ် ဟာ့ဒ်ဝဲအားလုံးနီးပါးသည် ၎င်းနှင့်အလုပ်လုပ်နိုင်သည်။

TCP ထက် UDP ၏ အားသာချက်များကား အဘယ်နည်း။ ပထမဦးစွာ၊ ကျွန်ုပ်တို့တွင် ဟာ့ဒ်ဝဲအကြောင်း သိသည့် သယ်ယူပို့ဆောင်ရေး အလွှာအပိုင်း မရှိပါ။ ၎င်းသည် ကျွန်ုပ်တို့အား အဆုံးမှတ်များပေါ်ရှိ session ကို ကိုယ်တိုင်ဆုံးဖြတ်နိုင်ပြီး ထိုနေရာတွင် ပဋိပက္ခများကို ဖြေရှင်းနိုင်စေပါသည်။ ဆိုလိုသည်မှာ၊ ကျွန်ုပ်တို့သည် (TCP တွင်ကဲ့သို့) session တစ်ခု သို့မဟုတ် အများအပြားတွင် အကန့်အသတ်မရှိသော်လည်း ၎င်းတို့ကို ကျွန်ုပ်တို့ လိုအပ်သလောက် ဖန်တီးနိုင်သည်။ ဒုတိယအချက်မှာ UDP မှတစ်ဆင့် ဒေတာပေးပို့ခြင်းသည် TCP ထက် ပိုမိုမြန်ဆန်သည်။ ထို့ကြောင့်၊ သီအိုရီအရ HTTP/2 တွင်ရရှိထားသော လက်ရှိမြန်နှုန်းမျက်နှာကျက်ကို ဖြတ်ကျော်နိုင်ပါသည်။

သို့သော်လည်း UDP သည် ယုံကြည်စိတ်ချရသော ဒေတာပေးပို့ခြင်းကို အာမမခံနိုင်ပါ။ အမှန်တော့၊ ကျွန်ုပ်တို့သည် ထုပ်ပိုးမှုများကို ရိုးရှင်းစွာ ပေးပို့နေပြီး အခြားတစ်ဖက်မှ ၎င်းတို့ကို လက်ခံရရှိမည်ဟု မျှော်လင့်ပါသည်။ မရဘူးလား? ကံမကောင်းစွာပဲ... ၎င်းသည် လူကြီးများအတွက် ဗီဒီယိုများ ထုတ်လွှင့်ရန် လုံလောက်သည်၊ သို့သော် ပိုမိုလေးနက်သော အရာများအတွက် သင်သည် ယုံကြည်စိတ်ချရမှု လိုအပ်သည်၊ ဆိုလိုသည်မှာ သင်သည် UDP ၏ထိပ်တွင် အခြားအရာတစ်ခုကို ခြုံထားရမည်ဟု ဆိုလိုပါသည်။

HTTP/2 ကဲ့သို့ပင်၊ 2012 ခုနှစ်တွင် Google တွင် ပရိုတိုကောအသစ်ဖန်တီးခြင်းဆိုင်ရာ အလုပ်စလုပ်ခဲ့သည်၊ ဆိုလိုသည်မှာ SPDY တွင် အလုပ်စတင်သည့်အချိန်နှင့် အတူတူပင်ဖြစ်ပါသည်။ 2013 ခုနှစ်တွင် Jim Roskind သည် လူအများအား တင်ပြခဲ့သည်။ QUIC (Quick UDP Internet Connections) ပရိုတိုကောနှင့် 2015 တွင် IETF တွင် စံသတ်မှတ်ခြင်းအတွက် Internet Draft ကို စတင်မိတ်ဆက်ခဲ့သည်။ ထိုအချိန်တွင်၊ Google မှ Roskind မှထုတ်လုပ်သည့်ပရိုတိုကောသည် စံနှင့်အလွန်ကွာခြားသောကြောင့် Google ဗားရှင်းကို gQUIC ဟုခေါ်ဆိုလာသည်။

QUIC ဆိုတာဘာလဲ

ပထမဦးစွာ၊ ဖော်ပြထားပြီးဖြစ်သည့်အတိုင်း၊ ဤအရာသည် UDP ၏ခြုံငုံသုံးသပ်ချက်ဖြစ်သည်။ QUIC ချိတ်ဆက်မှုသည် UDP ၏ထိပ်တွင် တက်လာသည်၊ ၎င်းတွင် HTTP/2 နှင့် ယှဉ်တွဲ၍ စမ်းချောင်းများစွာ တည်ရှိနိုင်သည်။ ဤစီးကြောင်းများသည် အဆုံးမှတ်များတွင်သာ တည်ရှိပြီး သီးခြားဝန်ဆောင်မှုပေးပါသည်။ ဒေတာစီးကြောင်းတစ်ခုတွင် ပက်ကတ်ဆုံးရှုံးမှုတစ်ခု ဖြစ်ပေါ်ပါက၊ ၎င်းသည် အခြားသူများကို ထိခိုက်မည်မဟုတ်ပါ။

Daniel Steinberg ၏ သရုပ်ဖော်ပုံ

ဒုတိယအနေနှင့်၊ ကုဒ်ဝှက်ခြင်းအား သီးခြားအဆင့်တွင် အကောင်အထည်မဖော်တော့ဘဲ ပရိုတိုကောတွင် ထည့်သွင်းထားသည်။ ၎င်းသည် သင့်အား လက်ဆွဲနှုတ်ဆက်ခြင်းတစ်ခုတည်းတွင် ချိတ်ဆက်မှုတစ်ခုနှင့် အများသူငှာသော့များကို လဲလှယ်နိုင်စေပြီး လိမ္မာပါးနပ်သော 0-RTT လက်ဆွဲခြင်းယန္တရားကို အသုံးပြုရန်နှင့် လက်ဆွဲနှောင့်နှေးမှုများကို လုံးဝရှောင်ရှားနိုင်စေမည်ဖြစ်သည်။ ထို့အပြင်၊ ယခုအခါ တစ်ဦးချင်းစီဒေတာပက်ကေ့ခ်ျများကို စာဝှက်ထားနိုင်ပါပြီ။ ၎င်းသည် ထုတ်လွှင့်မှုမှ ဒေတာလက်ခံရရှိမှု ပြီးစီးမှုကို မစောင့်ဘဲ လက်ခံရရှိထားသော ပက်ကတ်များကို လွတ်လပ်စွာ ကုဒ်ဝှက်ရန် ခွင့်ပြုသည်။ ဤလုပ်ဆောင်ချက်သည် ယေဘုယျအားဖြင့် TCP တွင် မဖြစ်နိုင်သောကြောင့်ဖြစ်သည်။ TLS နှင့် TCP သည် တစ်ခုနှင့်တစ်ခု သီးခြားလုပ်ဆောင်ခဲ့ပြီး TLS သည် မည်သည့်အပိုင်းများ TCP ဒေတာကို ဖြတ်တောက်မည်ကို မသိနိုင်ပါ။ ထို့ကြောင့်၊ TCP အပိုင်းများကို တစ်ခုနှင့်တစ်ခု အံဝင်ခွင်ကျဖြစ်စေရန် ၎င်း၏အပိုင်းများကို မပြင်ဆင်နိုင်ဘဲ လွတ်လပ်စွာ စာဝှက်ထားနိုင်မည်ဖြစ်သည်။ ဤတိုးတက်မှုများအားလုံးသည် TCP နှင့် နှိုင်းယှဉ်ပါက စောင့်ဆိုင်းနေချိန်ကို လျှော့ချရန် QUIC ကို ခွင့်ပြုပါသည်။

တတိယအနေဖြင့်၊ အလင်းလွှင့်ခြင်း၏သဘောတရားသည် သင့်အား သုံးစွဲသူ၏ IP လိပ်စာမှ ချိတ်ဆက်မှုကို ဖြတ်တောက်နိုင်စေပါသည်။ ဥပမာအားဖြင့်၊ client သည် Wi-Fi access point တစ်ခုမှ အခြားတစ်ခုသို့ ပြောင်းသည့်အခါ ၎င်း၏ IP ကိုပြောင်းသည့်အခါ ၎င်းသည် အရေးကြီးပါသည်။ ဤကိစ္စတွင်၊ TCP ကိုအသုံးပြုသည့်အခါ၊ ရှိပြီးသား TCP ချိတ်ဆက်မှုများ အချိန်ကုန်သွားကာ IP အသစ်တစ်ခုမှ ချိတ်ဆက်မှုအသစ်များကို ဖန်တီးသည့်ကာလတွင် ရှည်လျားသောလုပ်ငန်းစဉ်တစ်ခု ဖြစ်ပေါ်ပါသည်။ QUIC ကိစ္စတွင်၊ client သည် stream ID အဟောင်းဖြင့် IP အသစ်တစ်ခုမှ server သို့ packets များကို ဆက်လက်ပေးပို့နေပါသည်။ ဘာဖြစ်လို့လဲဆိုတော့ တိုက်ရိုက်ထုတ်လွှင့်မှု ID သည် ယခုထူးခြားပြီး ပြန်သုံးခြင်းမပြုတော့ဘဲ၊ client သည် IP ကိုပြောင်းထားပြီး၊ ပျောက်ဆုံးသွားသော packet များကို ပြန်လည်ပေးပို့ပြီး လိပ်စာအသစ်တွင် ဆက်သွယ်မှုကို ဆက်လက်လုပ်ဆောင်ကြောင်း ဆာဗာမှ နားလည်သည်။

စတုတ္ထ၊ QUIC သည် လည်ပတ်မှုစနစ်အဆင့်မဟုတ်ဘဲ လျှောက်လွှာအဆင့်တွင် အကောင်အထည်ဖော်သည်။ တစ်ဖက်တွင်၊ ၎င်းသည် ပရိုတိုကောကို လျင်မြန်စွာ ပြောင်းလဲမှုများ ပြုလုပ်နိုင်သောကြောင့် ဖြစ်သည်။ အပ်ဒိတ်တစ်ခုရရန်၊ OS ဗားရှင်းအသစ်ကို စောင့်ရမည့်အစား စာကြည့်တိုက်ကို အပ်ဒိတ်လုပ်ရန်သာလိုသည်။ အခြားတစ်ဖက်တွင်၊ ၎င်းသည် ပရိုဆက်ဆာသုံးစွဲမှုကို အားကောင်းစေသည်။

နောက်ဆုံးတော့ ခေါင်းစည်းတွေ။ header compression သည် QUIC နှင့် gQUIC အကြား ကွဲပြားသည့် အရာများထဲမှ တစ်ခုဖြစ်သည်။ ဒါကို အချိန်အများကြီး ပေးရတဲ့အချက်ကို ကျွန်တော် မမြင်ပါဘူး၊ စံသတ်မှတ်ချက်အတွက် တင်ပြထားတဲ့ ဗားရှင်းမှာ၊ header compression ကို HTTP/2 မှာ header compression နဲ့ တတ်နိုင်သမျှ ဆင်တူတယ်လို့ပဲ ပြောချင်ပါတယ်။ စာများများဖတ်လို့ရတယ်။ ဒီမှာ.

ဘယ်လောက်မြန်လဲ

ခက်တဲ့မေးခွန်းပါ။ တကယ်တော့ စံနှုန်းတစ်ခု မရှိသေးသရွေ့ တိုင်းတာစရာ ဘာမှ ထူးထူးခြားခြား မရှိပါဘူး။ 2013 နှင့် 2016 တွင် gQUIC ကိုအသုံးပြုခဲ့သည့် Google မှစာရင်းအင်းများသာဖြစ်နိုင်သည်။ IETF သို့ တိုင်ကြားခဲ့သည်။Chrome ဘရောက်ဆာမှ ၎င်းတို့၏ဆာဗာများသို့သွားသော အသွားအလာများ၏ 90% ခန့်သည် ယခုအခါ QUIC ကို အသုံးပြုသည်။ တူညီသောတင်ဆက်မှုတွင်၊ စာမျက်နှာများသည် gQUIC မှတဆင့် 5% ပိုမြန်ပြီး TCP နှင့်နှိုင်းယှဉ်ပါက ဗီဒီယိုကြည့်ရှုခြင်းတွင် 30% နည်းပါးကြောင်း အစီရင်ခံပါသည်။

2017 ခုနှစ်တွင် Arash Molavi Kakhki ဦးဆောင်သော သုတေသီအဖွဲ့မှ ထုတ်ဝေခဲ့သည်။ အလုပ်ကောင်း TCP နှင့် နှိုင်းယှဉ်ပါက gQUIC ၏ စွမ်းဆောင်ရည်ကို လေ့လာရန်။
လေ့လာမှုသည် gQUIC ၏ အားနည်းချက်များစွာဖြစ်သည့် ကွန်ရက်ပက်ကေ့ခ်ျများ ရောနှောခြင်းအတွက် မတည်မငြိမ်ဖြစ်မှု၊ လောဘကြီးမှု (မတရားမှု) ချန်နယ်ဘန်းဝဒ်နှင့် သေးငယ်သော (10 kb အထိ) အရာဝတ္ထုများကို လွှဲပြောင်းမှု နှေးကွေးစေခြင်းစသည့် လေ့လာမှုက ဖော်ပြခဲ့သည်။ သို့သော် နောက်ပိုင်းတွင် 0-RTT ကို အသုံးပြု၍ လျော်ကြေးပေးနိုင်သည်။ လေ့လာခဲ့သည့် အခြားကိစ္စများအားလုံးတွင်၊ gQUIC သည် TCP နှင့် နှိုင်းယှဉ်ပါက အရှိန်မြင့်တက်လာကြောင်း ပြသခဲ့သည်။ ဤနေရာတွင် သီးခြားနံပါတ်များအကြောင်း ပြောရန် ခက်ခဲသည်။ ဖတ်ရတာ ပိုကောင်းပါတယ်။ ကိုယ်တိုင်လေ့လာသည်။ သို့မဟုတ် ပို့စ်တို.

ဤနေရာတွင် ဤဒေတာသည် gQUIC နှင့် ပတ်သက်၍ အထူးပြောရမည် ဖြစ်ပြီး ၎င်းသည် စံနှုန်းကို ဖော်ထုတ်ခြင်းအတွက် မသက်ဆိုင်ပါ။ QUIC အတွက် ဘာဖြစ်မည်နည်း- ၎င်းသည် လျှို့ဝှက်ထားဆဲဖြစ်သည်၊ သို့သော် gQUIC တွင် ဖော်ပြထားသော အားနည်းချက်များကို ထည့်သွင်းစဉ်းစားပြီး ပြင်ပေးမည်ဟု မျှော်လင့်ပါသည်။

အနာဂတ်အနည်းငယ်- HTTP/3 ကကော။

သို့သော် ဤတွင် အရာအားလုံးသည် ကြည်လင်ပြတ်သားနေသည်- API သည် မည်သည့်နည်းနှင့်မျှ ပြောင်းလဲမည်မဟုတ်ပါ။ အရာအားလုံးသည် HTTP/2 တွင်ရှိသကဲ့သို့ အတိအကျတူညီနေမည်ဖြစ်သည်။ ကောင်းပြီ၊ API သည် တူညီနေပါက၊ HTTP/3 သို့ ကူးပြောင်းခြင်းသည် QUIC သယ်ယူပို့ဆောင်ရေးကို ပံ့ပိုးပေးသည့် နောက်ကွယ်ရှိ စာကြည့်တိုက်၏ ဗားရှင်းအသစ်ကို အသုံးပြုခြင်းဖြင့် ဖြေရှင်းရမည်ဖြစ်သည်။ မှန်ပါသည်၊ အဘယ်ကြောင့်ဆိုသော် HTTP ဗားရှင်းဟောင်းတွင် ဆုတ်ခွာမှုကို အချိန်အတော်ကြာအောင် ထားရှိရမည်ဖြစ်ပါသည်။ အင်တာနက်သည် UDP သို့ ပြီးပြည့်စုံသော အသွင်ကူးပြောင်းမှုအတွက် လောလောဆယ် အဆင်သင့်မဖြစ်သေးပါ။

ဘယ်သူက ထောက်ခံနေပြီလဲ။

ဒီမှာ စာရင်း လက်ရှိ QUIC အကောင်အထည်ဖော်မှုများ။ အဆင့်အတန်းမရှိပေမယ့် စာရင်းက မဆိုးပါဘူး။

ထုတ်လုပ်ဖြန့်ချိမှုတွင် လက်ရှိတွင် ဘရောက်ဆာသည် QUIC ကို ပံ့ပိုးမထားပါ။ မကြာသေးမီက HTTP/3 အတွက် ပံ့ပိုးကူညီမှုမှာ Chrome တွင် ပါ၀င်ခဲ့သော်လည်း ယခုအချိန်အထိ Canary တွင်သာ ရှိနေပါသည်။

နောက်ကွယ်မှ၊ HTTP/3 ကိုသာ ပံ့ပိုးပေးသည်။ Caddy и CloudFlareဒါပေမယ့် စမ်းသပ်ဆဲပါ။ နွေဦး 2019 ၏အဆုံးတွင် NGINX ကြေငြာခဲ့သည်HTTP/3 ပံ့ပိုးကူညီမှုတွင် ၎င်းတို့ စတင်လုပ်ဆောင်ခဲ့သော်လည်း မပြီးသေးပါ။

ပြဿနာတွေက ဘာတွေလဲ။

သင်နှင့်ကျွန်ုပ်သည် လက်တွေ့ကမ္ဘာတွင်နေထိုင်ကြပြီး၊ မည်သည့်နည်းပညာကြီးကြီးမားမားမှ ခံနိုင်ရည်မရှိသောလူများထံရောက်ရှိနိုင်ပြီး QUIC သည် ချွင်းချက်မဟုတ်ပါ။

အရေးကြီးဆုံးအချက်မှာ “https://” သည် TCP port 443 သို့ ဦးတည်သွားသည့်အချက်မဟုတ်တော့ကြောင်း ဘရောက်ဆာအား တစ်နည်းနည်းဖြင့် ရှင်းပြရန် လိုအပ်ပါသည်။ TCP လုံးဝမရှိနိုင်ပါ။ ၎င်းအတွက် Alt-Svc ခေါင်းစီးကို အသုံးပြုသည်။ ၎င်းသည် ဤဝဘ်ဆိုက်ကို ထိုကဲ့သို့သော ပရိုတိုကောနှင့် ထိုကဲ့သို့သော လိပ်စာများတွင်လည်း ဤဝဘ်ဆိုက်တွင် ရနိုင်သည်ဟု ဘရောက်ဆာအား ပြောပြနိုင်စေပါသည်။ သီအိုရီအရ၊ ၎င်းသည် ကျက်သရေတစ်ခုကဲ့သို့ လုပ်ဆောင်သင့်သော်လည်း လက်တွေ့တွင် DDoS တိုက်ခိုက်မှုများကိုရှောင်ရှားရန် ဥပမာအားဖြင့် UDP သည် firewall တွင်တားမြစ်ထားနိုင်သည်ဟူသောအချက်ကို ကျွန်ုပ်တို့တွေ့လာရမည်ဖြစ်ပါသည်။

UDP ကိုတားမြစ်ထားသော်လည်း၊ client သည် IP address ဖြင့် TCP session တစ်ခုကျင်းပရန် configure လုပ်ထားသည့် NAT router ၏နောက်တွင်ရှိနေနိုင်သည်၊ ကျွန်ုပ်တို့သည် ဟာ့ဒ်ဝဲစက်ရှင်မရှိသော UDP ကိုအသုံးပြုသည်၊ NAT သည် ချိတ်ဆက်မှုကို ထိန်းထားမည်မဟုတ်ပါ၊ နှင့် QUIC စက်ရှင်တစ်ခုဖြစ်သည်။ အဆက်မပြတ် ပြတ်သွားလိမ့်မယ်။.

ဤပြဿနာများအားလုံးသည် UDP သည် ယခင်ကအင်တာနက်အကြောင်းအရာများကို ထုတ်လွှင့်ရန်အသုံးမပြုခဲ့သောကြောင့်ဖြစ်ပြီး၊ ဟာ့ဒ်ဝဲထုတ်လုပ်သူများအနေဖြင့် ၎င်းသည် မည်သည့်အခါမျှဖြစ်လာမည်ကို ကြိုမသိနိုင်သောကြောင့်ဖြစ်သည်။ အလားတူပင်၊ စီမံခန့်ခွဲသူများသည် QUIC အလုပ်ဖြစ်ရန်အတွက် ၎င်းတို့၏ကွန်ရက်များကို မည်ကဲ့သို့ စနစ်တကျပြင်ဆင်သတ်မှတ်ရမည်ကို အမှန်တကယ်နားမလည်သေးပါ။ ဤအခြေအနေသည် တဖြည်းဖြည်းပြောင်းလဲသွားမည်ဖြစ်ပြီး မည်သို့ပင်ဆိုစေကာမူ အဆိုပါပြောင်းလဲမှုများသည် သယ်ယူပို့ဆောင်ရေးအလွှာပရိုတိုကောအသစ်ကို အကောင်အထည်ဖော်ခြင်းထက် အချိန်ပိုကြာမည်ဖြစ်သည်။

ထို့အပြင်၊ ဖော်ပြထားပြီးဖြစ်သည့်အတိုင်း QUIC သည် CPU အသုံးပြုမှုကို အလွန်တိုးစေသည်။ Daniel Stenberg တန်ဖိုးထား ပရိုဆက်ဆာသည် သုံးဆအထိ ကြီးထွားလာသည်။

HTTP/3 ဘယ်တော့ရောက်လာမလဲ။

စံ လက်ခံချင်သည်။ 2020 ခုနှစ် မေလတွင် ဖြစ်သော်လည်း၊ 2019 ခုနှစ် ဇူလိုင်လအတွက် စီစဉ်ထားသော စာရွက်စာတမ်းများသည် လောလောဆယ်တွင် မပြီးပြတ်သေးသောကြောင့် ရက်စွဲကို နောက်ပြန်ဆုတ်သွားဖွယ်ရှိသည်ဟု ကျွန်ုပ်တို့ပြောနိုင်ပါသည်။

ကောင်းပြီ၊ Google သည် ၎င်း၏ gQUIC အကောင်အထည်ဖော်မှုကို 2013 ခုနှစ်ကတည်းက အသုံးပြုခဲ့သည်။ Google ရှာဖွေရေးအင်ဂျင်သို့ ပေးပို့သည့် HTTP တောင်းဆိုချက်ကို သင်ကြည့်ရှုပါက၊ ဤအရာကို သင်မြင်ရလိမ့်မည်-

တွေ့ရှိချက်များ

ယခု QUIC သည် အမိုက်စားဖြစ်သော်လည်း အလွန်အလားအလာရှိသော နည်းပညာတစ်ခုကဲ့သို့ ဖြစ်နေပါသည်။ လွန်ခဲ့သည့်နှစ် 20 ကျော်အတွင်း၊ သယ်ယူပို့ဆောင်ရေးအလွှာပရိုတိုကောများ၏ ပိုမိုကောင်းမွန်အောင်လုပ်ဆောင်မှုအားလုံးသည် ကိစ္စအများစုတွင် အကောင်းဆုံးစွမ်းဆောင်ရည်ရှိသည့် TCP၊ QUIC တို့ကို အဓိကအားဖြင့် သက်ဆိုင်သည်မှာ အလွန်ကောင်းမွန်နေပြီဖြစ်သည်။

သို့သော်လည်း လာမည့်နှစ်အနည်းငယ်အတွင်း ဖြေရှင်းရမည့် ပြဿနာများ ရှိနေသေးသည်။ မည်သူမျှ မွမ်းမံမွမ်းမံခြင်းကို မကြိုက်သော ဟာ့ဒ်ဝဲများ ပါ၀င်နေခြင်းကြောင့် လုပ်ငန်းစဉ် နှောင့်နှေးနိုင်သော်လည်း၊ မည်သို့ပင်ဆိုစေကာမူ၊ ပြဿနာအားလုံးသည် အတော်လေး ဖြေရှင်းနိုင်ပုံရပြီး မကြာမီ သို့မဟုတ် နောက်ပိုင်းတွင် ကျွန်ုပ်တို့အားလုံး HTTP/3 ရှိပါမည်။

အနာဂတ်သည် နီးနီးလေးပင်။

source: www.habr.com