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 પોર્ટ તપાસ નાના પ્રશ્નનો જવાબ આપે છે.