Paano Makakatanggap ng HTTP at SOCKS ang Isang Proxy Port

Makakatanggap ng HTTP at SOCKS ang pinaghalong proxy listener sa isang TCP port dahil sinusuri ng server ang mga unang byte ng protocol. Hindi ginagawa ng numero ng port ang pagkilalang iyon.

Nagsisimula ang kahilingang proxy ng HTTP sa isang paraan ng HTTP, tulad ng GET o CONNECT. Nagsisimula ang pagbati ng SOCKS sa mga binary na field ng protocol. Maaaring ipadala ng software na ginawa para sa mga input na ito ang koneksyon sa angkop na handler.

Ito ay isang tahasang katangian ng implementasyon. Ang karaniwang HTTP listener ng Squid ay hindi nagiging pinaghalo dahil binago ang port nito sa 1080, at ang SOCKS-only na listener ay hindi natututo ng HTTP mula sa setting ng browser.

Nagdaragdag ang TLS ng isa pang hangganan: nagsisimula ang naka-encrypt na koneksyon ng proxy sa TLS, hindi sa nakikitang paraan ng HTTP. Ang pagsuporta nito sa parehong endpoint ay nangangailangan ng karagdagang sadyang paghawak; ang pagkilala sa plaintext HTTP at SOCKS ay hindi nagpapatunay ng kakayahang iyon.

Gamitin ang client protocol na dokumentado para sa endpoint. Kung gumagana ang dalawa, ebidensya iyon tungkol sa pinaghalong listener ng server na iyon, hindi dahilan para iwang hindi tinukoy ang protocol sa bawat client.

Nagbibigay ng konkretong halimbawa ang pinaghalong listener ng Glider: sinisilip nito ang isang byte nang hindi ito ginagamit, ipinapadala ang 0x05 sa handler nitong SOCKS5, at kung hindi ay tinatawag ang parser nitong HTTP. Vina-validate pa rin ng parser na iyon ang papasok na kahilingan; hindi ginagawang wastong HTTP ng pagpiling ipadala ang di-makatwirang input.

Ang pagbabahagi ng TCP listener ay hindi mismo nagbibigay ng UDP association ng SOCKS5. Hiwalay na sinisimulan ng Glider ang UDP listener nito. Ang pagpili ng protocol ng TCP at ang susunod na paghahatid ng datagram ay magkahiwalay na kakayahan.