Miten yksi välityspalvelimen portti voi hyväksyä sekä HTTP:n että SOCKS:n
Selittää, miten tarkoituksella yhdistetty kuuntelija voi erottaa HTTP:n ja SOCKS:n, kun taas tavallinen yhden protokollan kuuntelija ei voi.
Yhdistetty välityspalvelimen kuuntelija voi hyväksyä HTTP:n ja SOCKS:n yhdellä TCP-portilla, koska palvelin tutkii protokollan alkuperäiset tavut. Portin numero ei tee tätä tunnistusta.
HTTP-välityspalvelinpyyntö alkaa HTTP-menetelmällä, kuten GET tai CONNECT. SOCKS-tervehdys alkaa binäärisillä protokollakentillä. Näille syötteille suunniteltu ohjelmisto voi ohjata yhteyden sopivalle käsittelijälle.
Tämä on nimenomainen toteutusominaisuus. Tavallisesta Squid HTTP -kuuntelijasta ei tule yhdistettyä, koska sen portti vaihdetaan 1080:ksi, eikä vain SOCKS-kuuntelija opi HTTP:tä selaimen asetuksesta.
TLS lisää toisen rajan: salattu välityspalvelinyhteys alkaa TLS:llä, ei näkyvällä HTTP-menetelmällä. Sen tukeminen samassa päätepisteessä vaatii lisää tarkoituksellista käsittelyä; selkokielisen HTTP:n ja SOCKS:n tunnistaminen ei osoita tätä kykyä.
Käytä päätepisteelle dokumentoitua asiakasprotokollaa. Jos molemmat toimivat, se on todiste kyseisen palvelimen yhdistetystä kuuntelijasta, ei syy jättää protokolla määrittelemättä jokaisessa asiakkaassa.
Gliderin yhdistetty kuuntelija tarjoaa konkreettisen esimerkin: se kurkistaa yhtä tavua kuluttamatta sitä, lähettää 0x05:n SOCKS5-käsittelijälleen ja muuten kutsuu HTTP-jäsentäjäänsä. Tämä jäsentäjä validoi edelleen saapuvan pyynnön; lähetyksen valinta ei tee mielivaltaisesta syötteestä kelvollista HTTP:tä.
TCP-kuuntelijan jakaminen ei sinänsä tarjoa SOCKS5:n UDP-liitosta. Glider käynnistää UDP-kuuntelijansa erikseen. TCP-protokollan valinta ja myöhempi datagrammien välitys ovat erillisiä ominaisuuksia.