د HTTP/3 غوښتنې لپاره د UDP وړ پروکسي لار ته اړتیا ده
د HTTP/3 د QUIC لېږد له عادي HTTP CONNECT TCP تونلونو او د SOCKS5 خدمت د اختیاري UDP ملاتړ څخه توپیر کړئ.
هغه کلاینټ چې د TCP پروکسي له لارې په بریالیتوب HTTPS ته رسېږي، د HTTP/3 لپاره یې لار نه ده جوړه کړې. HTTP/3 له QUIC کار اخلي، او QUIC له UDP کار اخلي.
عادي HTTP CONNECT تونل خپل هدف ته د TCP جریان ورکوي. کله چې URL په HTTPS پیل شي یا هدف پر 443 پورټ غوږ ونیسي، دا د UDP لېږدوونکي په توګه نه بدلېږي.
SOCKS5 هم د UDP لارې ته اړتیا لري
SOCKS5 د UDP ټولنه تعریفوي، خو کلاینټ او سرور دواړه باید پلي یې کړي، او د لېږد پایټکی باید د لاسرسي وړ وي. هغه کتابتون چې یوازې د SOCKS TCP ډایلر وړاندې کوي، یوازې د دې لپاره چې د ډول نوم یې SOCKS5 دی، د ډاټاګرام لېږد نه شي وړاندې کولی.
همدا راز، د یوې وسیلې د proxy په نوم برخه کېدای شي د پراختیا د پاکټ ضایع کېدو سیمولیټر وي، نه د پورتني پروکسي عمومي کلاینټ. د دې ریښتینی انټرفیس او ملاتړ شوی لېږد وګورئ.
د CONNECT-UDP په څېر معیارونه د HTTP پروکسي سیسټم له لارې د UDP د لېږد بل لار تعریفوي. دوی دواړو خواوو ته ملاتړ ته اړتیا لري او د دودیز CONNECT سره باید ګډ نه شي.
که HTTP کلاینټ پر TCP بېرته HTTP/2 یا HTTP/1.1 ته ولاړ شي، غوښتنه کېدای شي د عادي پروکسي له لارې بریالۍ شي پرته لدې چې کوم HTTP/3 نښلون کارول شوی وي. کله چې دا توپیر مهم وي، هوکړه شوی پروتوکول ثبت کړئ.
نو د مطابقت ګټور پوښتنه ځانګړې ده: ایا دا کلاینټ کولی شي خپل QUIC ډاټاګرامونه د دې ملاتړ شوي میکانیزم سره د دې پروکسي له لارې ولېږدوي؟ کاري براوزر پاڼه یا د TCP پورټ کتنه کوچنۍ پوښتنې ته ځواب وایي.