Kako jedan proxy port može primati i HTTP i SOCKS

Mješoviti proxy slušatelj može primati HTTP i SOCKS na jednom TCP portu jer poslužitelj pregledava početne bajtove protokola. Broj porta ne obavlja to prepoznavanje.

HTTP proxy zahtjev počinje HTTP metodom, kao što su GET ili CONNECT. SOCKS pozdrav počinje binarnim poljima protokola. Softver namijenjen tim ulazima može usmjeriti vezu na odgovarajući rukovatelj.

To je izričito svojstvo implementacije. Obični Squid HTTP slušatelj ne postaje mješovit zato što mu se port promijeni na 1080, a slušatelj samo za SOCKS ne nauči HTTP iz postavke preglednika.

TLS dodaje još jednu granicu: šifrirana proxy veza počinje TLS-om, a ne vidljivom HTTP metodom. Podrška za to na istoj krajnjoj točki zahtijeva dodatno namjerno rukovanje; prepoznavanje običnog HTTP-a i SOCKS-a ne dokazuje tu sposobnost.

Koristite klijentski protokol dokumentiran za krajnju točku. Ako oba rade, to je dokaz o mješovitom slušatelju tog poslužitelja, a ne razlog da protokol ostane neodređen u svakom klijentu.

Gliderov mješoviti slušatelj daje konkretan primjer: zaviri u jedan bajt bez da ga troši, prosljeđuje 0x05 svom SOCKS5 rukovatelju, a inače poziva svoj HTTP parser. Taj parser i dalje provjerava dolazni zahtjev; izbor prosljeđivanja ne čini proizvoljan ulaz valjanim HTTP-om.

Dijeljenje TCP slušatelja samo po sebi ne pruža SOCKS5 UDP pridruživanje. Glider pokreće svoj UDP slušatelj odvojeno. Odabir TCP protokola i kasniji prijenos datagrama odvojene su sposobnosti.