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 पोर्ट तपासणी लहान प्रश्नाचे उत्तर देते.