ਇੱਕ ਪ੍ਰੌਕਸੀ ਪੋਰਟ HTTP ਅਤੇ SOCKS ਦੋਵੇਂ ਕਿਵੇਂ ਸਵੀਕਾਰ ਕਰ ਸਕਦਾ ਹੈ
ਦੱਸਦਾ ਹੈ ਕਿ ਜਾਣ-ਬੁੱਝ ਕੇ ਮਿਲਿਆ ਜੋੜਿਆ ਲਿਸਨਰ HTTP ਅਤੇ SOCKS ਵਿੱਚ ਫ਼ਰਕ ਕਿਵੇਂ ਕਰ ਸਕਦਾ ਹੈ, ਜਦਕਿ ਆਮ ਇੱਕ-ਪ੍ਰੋਟੋਕਾਲ ਲਿਸਨਰ ਅਜਿਹਾ ਨਹੀਂ ਕਰ ਸਕਦਾ।
ਮਿਲਿਆ ਜੋੜਿਆ ਪ੍ਰੌਕਸੀ ਲਿਸਨਰ ਇੱਕ TCP ਪੋਰਟ ਉੱਤੇ HTTP ਅਤੇ SOCKS ਸਵੀਕਾਰ ਕਰ ਸਕਦਾ ਹੈ ਕਿਉਂਕਿ ਸਰਵਰ ਸ਼ੁਰੂਆਤੀ ਪ੍ਰੋਟੋਕਾਲ ਬਾਈਟਾਂ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ। ਪੋਰਟ ਨੰਬਰ ਉਹ ਪਛਾਣ ਨਹੀਂ ਕਰਦਾ।
HTTP ਪ੍ਰੌਕਸੀ ਬੇਨਤੀ HTTP ਢੰਗ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦੀ ਹੈ, ਜਿਵੇਂ GET ਜਾਂ CONNECT। SOCKS ਸਤਿਕਾਰ ਬਾਈਨਰੀ ਪ੍ਰੋਟੋਕਾਲ ਖੇਤਰਾਂ ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ। ਇਹਨਾਂ ਇਨਪੁਟਾਂ ਲਈ ਬਣਾਇਆ ਸੌਫਟਵੇਅਰ ਕਨੈਕਸ਼ਨ ਨੂੰ ਢੁਕਵੇਂ ਹੈਂਡਲਰ ਕੋਲ ਭੇਜ ਸਕਦਾ ਹੈ।
ਇਹ ਸਪਸ਼ਟ ਲਾਗੂਕਰਨ ਵਿਸ਼ੇਸ਼ਤਾ ਹੈ। ਆਮ Squid HTTP ਲਿਸਨਰ ਆਪਣਾ ਪੋਰਟ 1080 ਵਿੱਚ ਬਦਲਣ ਨਾਲ ਮਿਲਿਆ ਜੋੜਿਆ ਨਹੀਂ ਹੁੰਦਾ, ਅਤੇ ਸਿਰਫ਼ SOCKS ਵਾਲਾ ਲਿਸਨਰ ਬ੍ਰਾਊਜ਼ਰ ਦੀ ਸੈਟਿੰਗ ਤੋਂ HTTP ਨਹੀਂ ਸਿੱਖਦਾ।
TLS ਇੱਕ ਹੋਰ ਸੀਮਾ ਜੋੜਦਾ ਹੈ: ਐਨਕ੍ਰਿਪਟਿਡ ਪ੍ਰੌਕਸੀ ਕਨੈਕਸ਼ਨ TLS ਨਾਲ ਸ਼ੁਰੂ ਹੁੰਦਾ ਹੈ, ਦਿਸਦੇ HTTP ਢੰਗ ਨਾਲ ਨਹੀਂ। ਉਸੇ ਐਂਡਪੌਇੰਟ ਉੱਤੇ ਇਸ ਦਾ ਸਮਰਥਨ ਕਰਨ ਲਈ ਵਾਧੂ ਜਾਣ-ਬੁੱਝ ਕੇ ਹੈਂਡਲਿੰਗ ਲੋੜੀਂਦੀ ਹੈ; ਸਾਦਾ HTTP ਅਤੇ SOCKS ਪਛਾਣਨਾ ਉਹ ਸਮਰੱਥਾ ਸਥਾਪਤ ਨਹੀਂ ਕਰਦਾ।
ਐਂਡਪੌਇੰਟ ਲਈ ਦਸਤਾਵੇਜ਼ੀ ਕਲਾਇੰਟ ਪ੍ਰੋਟੋਕਾਲ ਵਰਤੋ। ਜੇ ਦੋਵੇਂ ਕੰਮ ਕਰਦੇ ਹਨ, ਤਾਂ ਇਹ ਉਸ ਸਰਵਰ ਦੇ ਮਿਲੇ ਜੋੜੇ ਲਿਸਨਰ ਬਾਰੇ ਸਬੂਤ ਹੈ, ਹਰ ਕਲਾਇੰਟ ਵਿੱਚ ਪ੍ਰੋਟੋਕਾਲ ਅਣਦੱਸਿਆ ਛੱਡਣ ਦਾ ਕਾਰਨ ਨਹੀਂ।
Glider ਦਾ ਮਿਲਿਆ ਜੋੜਿਆ ਲਿਸਨਰ ਇੱਕ ਠੋਸ ਉਦਾਹਰਨ ਦਿੰਦਾ ਹੈ: ਇਹ ਇੱਕ ਬਾਈਟ ਨੂੰ ਵਰਤੇ ਬਿਨਾਂ ਉਸ ਉੱਤੇ ਨਜ਼ਰ ਪਾਉਂਦਾ ਹੈ, 0x05 ਆਪਣੇ SOCKS5 ਹੈਂਡਲਰ ਨੂੰ ਭੇਜਦਾ ਹੈ, ਅਤੇ ਨਹੀਂ ਤਾਂ ਆਪਣਾ HTTP ਪਾਰਸਰ ਬੁਲਾਉਂਦਾ ਹੈ। ਉਹ ਪਾਰਸਰ ਅਜੇ ਵੀ ਆ ਰਹੀ ਬੇਨਤੀ ਦੀ ਪੁਸ਼ਟੀ ਕਰਦਾ ਹੈ; ਭੇਜਣ ਦੀ ਚੋਣ ਮਨਮਾਨੀ ਇਨਪੁਟ ਨੂੰ ਵੈਧ HTTP ਨਹੀਂ ਬਣਾਉਂਦੀ।
TCP ਲਿਸਨਰ ਸਾਂਝਾ ਕਰਨਾ ਆਪਣੇ ਆਪ SOCKS5 UDP ਸੰਬੰਧ ਨਹੀਂ ਦਿੰਦਾ। Glider ਆਪਣਾ UDP ਲਿਸਨਰ ਵੱਖਰਾ ਸ਼ੁਰੂ ਕਰਦਾ ਹੈ। TCP ਪ੍ਰੋਟੋਕਾਲ ਚੋਣ ਅਤੇ ਬਾਅਦ ਵਿੱਚ ਡੇਟਾਗ੍ਰਾਮ ਰਿਲੇ ਵੱਖਰੀਆਂ ਸਮਰੱਥਾਵਾਂ ਹਨ।