សំណើ HTTP/3 ត្រូវការផ្លូវប្រូកស៊ីដែលគាំទ្រ UDP
បែងចែកការដឹកជញ្ជូន QUIC របស់ HTTP/3 ពីផ្លូវរូង TCP HTTP CONNECT ធម្មតា និងពីការគាំទ្រ UDP ជាជម្រើសរបស់សេវា SOCKS5។
អតិថិជនដែលទៅដល់ HTTPS ដោយជោគជ័យតាមរយៈប្រូកស៊ី TCP មិនបានបង្កើតផ្លូវសម្រាប់ HTTP/3 ទេ។ HTTP/3 ប្រើ QUIC ហើយ QUIC ប្រើ UDP។
ផ្លូវរូង HTTP CONNECT ធម្មតាផ្តល់ស្ទ្រីម TCP ទៅគោលដៅរបស់វា។ វាមិនប្រែក្លាយជាអ្នកបញ្ជូនបន្ត UDP នៅពេល URL ចាប់ផ្តើមដោយ HTTPS ឬពេលគោលដៅស្តាប់នៅច្រក 443 នោះទេ។
SOCKS5 ក៏ត្រូវការផ្លូវ UDP ដែរ
SOCKS5 កំណត់ សមាគម UDP ប៉ុន្តែទាំងអតិថិជន និងម៉ាស៊ីនមេត្រូវអនុវត្តវា ហើយចំណុចបញ្ចប់បញ្ជូនបន្តត្រូវតែអាចទៅដល់បាន។ បណ្ណាល័យដែលផ្តល់តែ dialer TCP របស់ SOCKS មិនអាចផ្តល់ការដឹកជញ្ជូនដាតាក្រាមបានទេ គ្រាន់តែដោយសារតែឈ្មោះប្រភេទរបស់វានិយាយថា SOCKS5។
ដូចគ្នាដែរ ធាតុផ្សំនៃឧបករណ៍ដែលមានឈ្មោះថា proxy អាចជាឧបករណ៍ក្លែងធ្វើការបាត់បង់កញ្ចប់សម្រាប់អភិវឌ្ឍន៍ មិនមែនជាអតិថិជនប្រូកស៊ីខាងលើទូទៅទេ។ ពិនិត្យមើលចំណុចប្រទាក់ពិត និងការដឹកជញ្ជូនដែលគាំទ្រ។
ស្តង់ដារដូចជា CONNECT-UDP កំណត់វិធីមួយផ្សេងទៀតដើម្បីដឹក UDP តាមរយៈប្រព័ន្ធប្រូកស៊ី HTTP។ ពួកវាត្រូវការការគាំទ្រនៅចុងទាំងពីរ ហើយមិនគួរច្រឡំជាមួយ CONNECT បុរាណទេ។
ប្រសិនបើអតិថិជន HTTP ត្រឡប់ទៅ HTTP/2 ឬ HTTP/1.1 លើ TCP នោះសំណើអាចជោគជ័យតាមប្រូកស៊ីធម្មតា ខណៈដែលគ្មានការតភ្ជាប់ HTTP/3 ត្រូវបានប្រើ។ កត់ត្រាពិធីការដែលបានចរចា នៅពេលភាពខុសគ្នានោះសំខាន់។
ដូច្នេះសំណួរភាពឆបគ្នាដែលមានប្រយោជន៍គឺជាក់លាក់៖ តើអតិថិជននេះអាចដឹកដាតាក្រាម QUIC របស់វាតាមប្រូកស៊ីនេះ ដោយប្រើយន្តការដែលគាំទ្រនេះបានទេ? ទំព័រកម្មវិធីរុករកដែលដំណើរការ ឬការពិនិត្យច្រក TCP ឆ្លើយសំណួរតូចជាង។