Korleis éin proxy-port kan ta imot både HTTP og SOCKS
Forklarer korleis ein medvite blanda lytar kan skilje HTTP og SOCKS, medan ein vanleg lytar for éin protokoll ikkje kan.
Ein blanda proxy-lytar kan ta imot HTTP og SOCKS på éin TCP-port fordi tenaren granskar dei innleiande protokollbyta. Portnummeret utfører ikkje den gjenkjenninga.
Ein HTTP-proxyførespurnad byrjar med ein HTTP-metode, til dømes GET eller CONNECT. Ein SOCKS-helsing byrjar med binære protokollfelt. Programvare laga for desse inngangane kan senda tilkoplinga vidare til rett handterar.
Dette er ein eksplisitt implementasjonsfunksjon. Ein vanleg Squid HTTP-lytar vert ikkje blanda fordi porten vert endra til 1080, og ein lytar som berre kan SOCKS, lærer ikkje HTTP av ei nettlesarinnstilling.
TLS legg til ei anna grense: ei kryptert proxy-tilkopling byrjar med TLS, ikkje med ein synleg HTTP-metode. Å støtte det på same endepunkt krev ekstra medviten handtering; å kjenne att klartekst-HTTP og SOCKS fastslår ikkje den eigenskapen.
Bruk klientprotokollen som er dokumentert for endepunktet. Viss begge verkar, er det eit prov om den blanda lytaren til den tenaren, ikkje ein grunn til å la protokollen vere uspesifisert i kvar klient.
Den blanda lytaren til Glider gjev eit konkret døme: han kikar på eitt byt utan å bruke det, sender 0x05 til sin SOCKS5-handterar og kallar elles HTTP-parsaren sin. Den parsaren validerer framleis den innkommande førespurnaden; valet av sending gjer ikkje vilkårleg inngang til gyldig HTTP.
Å dele TCP-lytaren gjev ikkje i seg sjølv SOCKS5 UDP-tilknyting. Glider startar UDP-lytaren sin separat. Val av TCP-protokoll og den seinare datagram-vidaresendinga er separate eigenskapar.