Hur en enda proxy-port kan ta emot både HTTP och SOCKS
Förklarar hur en medvetet blandad lyssnare kan skilja HTTP från SOCKS, medan en vanlig lyssnare för ett enda protokoll inte kan.
En blandad proxy-lyssnare kan ta emot HTTP och SOCKS på en enda TCP-port eftersom servern granskar de inledande protokollbyten. Portnumret utför inte den identifieringen.
En HTTP-proxybegäran börjar med en HTTP-metod, till exempel GET eller CONNECT. En SOCKS-hälsning börjar med binära protokollfält. Programvara utformad för dessa indata kan skicka anslutningen till rätt hanterare.
Detta är en explicit implementeringsfunktion. En vanlig Squid HTTP-lyssnare blir inte blandad för att dess port ändras till 1080, och en lyssnare som bara kan SOCKS lär sig inte HTTP från en webbläsarinställning.
TLS lägger till en annan gräns: en krypterad proxyanslutning börjar med TLS, inte med en synlig HTTP-metod. Att stödja det på samma slutpunkt kräver ytterligare medveten hantering; att känna igen klartext-HTTP och SOCKS fastställer inte den förmågan.
Använd klientprotokollet som är dokumenterat för slutpunkten. Om båda fungerar är det ett bevis om den serverns blandade lyssnare, inte en anledning att lämna protokollet ospecificerat i varje klient.
Gliders blandade lyssnare ger ett konkret exempel: den kikar på en byte utan att förbruka den, skickar 0x05 till sin SOCKS5-hanterare och anropar annars sin HTTP-parser. Den parsern validerar fortfarande den inkommande begäran; valet av sändning gör inte godtycklig indata till giltig HTTP.
Att dela TCP-lyssnaren ger inte i sig SOCKS5 UDP-association. Glider startar sin UDP-lyssnare separat. Val av TCP-protokoll och den senare datagram-vidarebefordran är separata förmågor.