HTTP/3 တောင်းဆိုမှုတွင် UDP ကို ပံ့ပိုးသော proxy လမ်းကြောင်း လိုအပ်သည်

TCP proxy ဖြင့် HTTPS သို့ အောင်မြင်စွာ ရောက်ရှိသော client သည် HTTP/3 အတွက် လမ်းကြောင်း မတည်ဆောက်ရသေးပါ။ HTTP/3 သည် QUIC ကို သုံးပြီး QUIC သည် UDP ကို သုံးသည်။

သာမန် HTTP CONNECT လိုဏ်ခေါင်းသည် ၎င်း၏ ဦးတည်ရာသို့ TCP စီးကြောင်း ပေးသည်။ URL က HTTPS ဖြင့် စတင်သောအခါ သို့မဟုတ် ဦးတည်ရာက port 443 တွင် နားထောင်သောအခါ ၎င်းသည် UDP ပြန်လွှဲပေးသူ မဖြစ်လာပါ။

SOCKS5 လည်း UDP လမ်းကြောင်း လိုအပ်သည်

SOCKS5 သည် UDP ဆက်စပ်မှုကို သတ်မှတ်သည်၊ သို့သော် client နှင့် server နှစ်ခုစလုံး ၎င်းကို အကောင်အထည်ဖော်ရမည် ဖြစ်ပြီး ပြန်လွှဲသည့် အဆုံးမှတ်သို့ ရောက်ရှိနိုင်ရမည်။ SOCKS TCP dialer ကိုသာ ပေးသော library သည် ၎င်း၏ အမျိုးအစား အမည်က SOCKS5 ဟု ဆိုသောကြောင့်သာ datagram သယ်ယူမှု မပေးနိုင်ပါ။

အလားတူ proxy ဟု အမည်ရသော ကိရိယာ အစိတ်အပိုင်းသည် ယေဘုယျ upstream-proxy client မဟုတ်ဘဲ ဖွံ့ဖြိုးရေး packet-loss သရုပ်ပြစက်ဖြစ်နိုင်သည်။ ၎င်း၏ အမှန်တကယ် interface နှင့် ပံ့ပိုးသော သယ်ယူမှုကို စစ်ဆေးပါ။

CONNECT-UDP ကဲ့သို့ စံနှုန်းများသည် HTTP proxy စနစ်မှတစ်ဆင့် UDP သယ်ဆောင်ရန် အခြားနည်းလမ်းကို သတ်မှတ်သည်။ ၎င်းတို့သည် နှစ်ဖက်စလုံးတွင် ပံ့ပိုးမှု လိုအပ်ပြီး ရိုးရာ CONNECT နှင့် မရောထွေးသင့်ပါ။

HTTP client သည် TCP အပေါ် HTTP/2 သို့မဟုတ် HTTP/1.1 သို့ ပြန်ဆုတ်သွားပါက HTTP/3 ချိတ်ဆက်မှု မသုံးဘဲ သာမန် proxy မှတစ်ဆင့် တောင်းဆိုမှု အောင်မြင်နိုင်သည်။ ထိုကွာခြားချက် အရေးကြီးသောအခါ ညှိနှိုင်းထားသော protocol ကို မှတ်တမ်းတင်ပါ။

ထို့ကြောင့် အသုံးဝင်သော ကိုက်ညီမှု မေးခွန်းမှာ တိကျသည်။ ဤ client သည် ဤပံ့ပိုးထားသော ယန္တရားဖြင့် ဤ proxy မှတစ်ဆင့် ၎င်း၏ QUIC datagram များကို သယ်ဆောင်နိုင်ပါသလား။ အလုပ်လုပ်သော browser စာမျက်နှာ သို့မဟုတ် TCP port စစ်ဆေးမှုသည် ပိုသေးငယ်သော မေးခွန်းကို ဖြေဆိုသည်။