.NET-socket tarvitsee SOCKS-kättelyn

Socket.Connect()-osoituksen kohdistaminen SOCKS-palvelimeen avaa TCP-yhteyden siihen palvelimeen. Seuraavien tavujen on silti puhuttava SOCKSia. Sovelluksen protokollan lähettäminen heti jättää palvelimen odottamaan toisenlaista keskustelua.

SOCKS5:ssä yhteyden muodostus sisältää menetelmäneuvottelun, mahdollisen valitun todennuksenvaihdon ja kohteen nimeävän pyynnön. Vain onnistunut vastaus avaa tien sovelluksen tavuille. Nämä vaiheet määritellään kohdassa RFC 1928.

Pidä neuvottelu yhteyskerroksessa

Sovellus, jolla on oma TCP-protokollansa, voi käyttää välityspalvelintietoista liitintä, joka palauttaa muodostetun virran. Sovelluksen muu osa lukee ja kirjoittaa sen virran kautta. Liittimen on otettava huomioon osittaiset luvut, vaihtelevan pituiset osoitteet, todennusvirheet ja neuvottelun määräaika.

Käsin kirjoitettu toteutus, joka lukee yhden kiinteäkokoisen puskurin ja olettaa onnistumisen, on hauras. TCP ei säilytä SOCKS-viestien rajoja. Lue täydellinen vastaus, jonka sen osoitetyyppi kuvaa, ennen sovellusprotokollan aloittamista. .NET 7+ -version CONNECT-vastauksen lukija havainnollistaa tämän vaiheen.

Jos ylläpidetty kirjasto tarjoaa jo tämän yhteyskerroksen, tarkista sen tuetut SOCKS-versiot, todennusmenetelmät ja kohdekehys. Vuosikymmenen vanha foorumilinkki on tutkimuksen lähtökohta, ei todiste nykyisestä yhteensopivuudesta.

HTTP-asiakkaan asetuksilla on erillinen alueensa

HTTP-asiakkaan välityspalvelinasetus määrittää kyseisen HTTP-asiakkaan. Se ei muuta jokaista prosessin raakaa socketia. Socket-API ottaa vastaan verkkopäätepisteen ja jättää ylemmän tason neuvottelun kutsujalle.

Salatun sovellusprotokollan osalta suorita sen TLS-kättely sen jälkeen, kun välityspalvelintunneli on muodostettu. Vahvista aiotun kohteen identiteetti siinä vaiheessa. Välityspalvelimen todennus ja kohteen todennus pysyvät erillisinä, vaikka ne käyttävät samaa taustavirtaa.