HTTP/3 so'rovi UDP qo'llab-quvvatlaydigan proksi yo'lini talab qiladi
HTTP/3 ning QUIC transportini oddiy HTTP CONNECT TCP tunnellaridan va SOCKS5 xizmatining ixtiyoriy UDP qo'llab-quvvatlashidan ajrating.
TCP proksi orqali HTTPS ga muvaffaqiyatli yetib borgan mijoz HTTP/3 uchun yo'l ochmagan. HTTP/3 QUIC dan, QUIC esa UDP dan foydalanadi.
Oddiy HTTP CONNECT tunnel o'z manziliga TCP oqimini beradi. URL HTTPS bilan boshlanganda yoki manzil 443 portida tinglaganda ham u UDP uzatgichga aylanmaydi.
SOCKS5 ham UDP yo'liga muhtoj
SOCKS5 UDP assotsiatsiyasini belgilaydi, lekin uni mijoz ham, server ham amalga oshirishi kerak, uzatishning oxirgi nuqtasi esa yetib borish imkoniyatiga ega bo'lishi lozim. Faqat SOCKS TCP dialerini taqdim etadigan kutubxona tur nomi SOCKS5 deb turgani uchungina datagramma transportini bera olmaydi.
Xuddi shunday, asbobning proxy deb nomlangan komponenti umumiy yuqori proksi mijozi emas, balki ishlab chiqish uchun paket yo'qotish simulyatori bo'lishi mumkin. Uning haqiqiy interfeysi va qo'llab-quvvatlanadigan transportini tekshiring.
CONNECT-UDP kabi standartlar UDP ni HTTP proksi tizimi orqali olib o'tishning boshqa usulini belgilaydi. Ular ikki tomonda ham qo'llab-quvvatlashni talab qiladi va an'anaviy CONNECT bilan chalkashtirilmasligi kerak.
Agar HTTP mijozi TCP ustida HTTP/2 yoki HTTP/1.1 ga qaytsa, so'rov oddiy proksi orqali muvaffaqiyatli bo'lishi mumkin, ammo hech qanday HTTP/3 ulanishi ishlatilmagan. Bu farq muhim bo'lganda kelishilgan protokolni yozib oling.
Shuning uchun foydali moslik savoli aniq: bu mijoz o'zining QUIC datagrammalarini shu qo'llab-quvvatlanadigan mexanizm bilan shu proksi orqali o'tkaza oladimi? Ishlaydigan brauzer sahifasi yoki TCP port tekshiruvi kichikroq savolga javob beradi.