Hoe't ien proxy-poarte sawol HTTP as SOCKS akseptearje kin
Ferklearret hoe't in bewust mongen listener HTTP en SOCKS ûnderskiede kin, wylst in gewoane ienprotokol-listener dat net kin.
In mongen proxy-listener kin HTTP en SOCKS op ien TCP-poarte akseptearje, om't de tsjinner de earste protokolbytes besjocht. It poartenûmer docht dy deteksje net.
In HTTP-proxyfersyk begjint mei in HTTP-metoade, lykas GET of CONNECT. In SOCKS-groetnis begjint mei binêre protokolfjilden. Software ûntwurpen foar dizze ynfier kin de ferbining nei de passende handler stjoere.
Dit is in eksplisite ymplemintaasjeskaaimerk. In gewoane Squid HTTP-listener wurdt net mongen om't syn poarte nei 1080 feroare wurdt, en in listener mei allinnich SOCKS leart gjin HTTP fan in browserynstelling.
TLS foeget in oare grins ta: in fersifere proxyferbining begjint mei TLS, net mei in sichtbere HTTP-metoade. It stypjen dêrfan op itselde einpunt freget ekstra bewuste behanneling; it werkenjen fan platte tekst HTTP en SOCKS bewissiget dy kapasiteit net.
Brûk it klantprotokol dat dokumintearre is foar it einpunt. As beide wurkje, is dat bewiis oer de mongen listener fan dy tsjinner, net in reden om it protokol yn elke klant ûnspesifisearre te litten.
De mongen listener fan Glider jout in konkreet foarbyld: hy glûpt nei ien byte sûnder him te ferbrûken, stjoert 0x05 nei syn SOCKS5-handler en ropt oars syn HTTP-parser op. Dy parser falidearret de ynkommende oanfraach noch; de kar fan stjoeren makket willekeurige ynfier net jildich HTTP.
It dielen fan de TCP-listener leveret sels gjin SOCKS5 UDP-assosjaasje. Glider start syn UDP-listener apart. De kar fan TCP-protokol en it lettere datagram-relay binne aparte kapasiteiten.