Kako jedan proxy port može primati i HTTP i SOCKS
Objašnjava kako namjerno mješoviti slušalac može razlikovati HTTP i SOCKS, dok običan jednoprotokolni slušalac to ne može.
Mješoviti proxy slušalac može primati HTTP i SOCKS na jednom TCP portu jer server pregleda 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 obrađivač.
To je izričita karakteristika implementacije. Običan Squid HTTP slušalac ne postaje mješovit zato što mu je port promijenjen na 1080, a slušalac 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 tački zahtijeva dodatno namjerno rukovanje; prepoznavanje običnog HTTP-a i SOCKS-a ne dokazuje tu sposobnost.
Koristite klijentski protokol dokumentovan za krajnju tačku. Ako oba rade, to je dokaz o mješovitom slušaocu tog servera, a ne razlog da protokol ostane neodređen u svakom klijentu.
Gliderov mješoviti slušalac daje konkretan primjer: zaviri u jedan bajt bez da ga troši, prosljeđuje 0x05 svom SOCKS5 obrađivaču, 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šaoca samo po sebi ne pruža SOCKS5 UDP asocijaciju. Glider pokreće svoj UDP slušalac odvojeno. Odabir TCP protokola i kasnije prenošenje datagrama su odvojene sposobnosti.