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 पोर्ट जाँचले सानो प्रश्नको उत्तर दिन्छ।