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 ਪੋਰਟ ਜਾਂਚ ਛੋਟੇ ਸਵਾਲ ਦਾ ਜਵਾਬ ਦਿੰਦੀ ਹੈ।