Ein .NET-socket treng ein SOCKS-handtrykk

Å peike Socket.Connect() mot ein SOCKS-tenar opnar ei TCP-tilkopling til den tenaren. Dei neste byta må framleis snakke SOCKS. Å sende protokollen til applikasjonen med ein gong lèt tenaren vente på ein annan samtale.

Med SOCKS5 omfattar opprettinga av tilkoplinga metodeforhandling, eventuell vald autentiseringsutveksling og ein førespurnad som namngjev destinasjonen. Berre eit vellukka svar opnar vegen for byta til applikasjonen. Desse trinna er definerte i RFC 1928.

Hald forhandlinga i tilkoplingslaget

Ein applikasjon med sin eigen TCP-protokoll kan bruke ein proxyvitug kopling som returnerer ein etablert straum. Resten av applikasjonen les og skriv deretter gjennom den straumen. Ei kopling må ta omsyn til delvise lesingar, adresser med variabel lengd, autentiseringsfeil og ein frist for forhandlinga.

Ei handskriven implementering som les ein buffer med fast storleik og reknar med suksess, er skjør. TCP bevarer ikkje grensene mellom SOCKS-meldingar. Les det fullstendige svaret som er skildra av adressetypen, før du startar applikasjonsprotokollen. Ein .NET 7+ CONNECT-svarlesar illustrerer det trinnet.

Viss eit vedlikehalde bibliotek allereie leverer dette tilkoplingslaget, kontroller dei støtta SOCKS-versjonane, autentiseringsmetodane og målrammeverket. Ei ti år gammal forumlenkje er eit utgangspunkt for gransking, ikkje prov på gjeldande kompatibilitet.

HTTP-klientkonfigurasjon har eit eige omfang

Proxyinnstillinga til ein HTTP-klient konfigurerer den HTTP-klienten. Ho endrar ikkje kvar rå socket i prosessen. Socket-API-et godtek eit nettverksendepunkt og overlèt forhandling på høgare nivå til den som kallar.

For ein kryptert applikasjonsprotokoll, utfør TLS-handtrykket etter at proxy-tunnelen er etablert. Valider den tiltenkte destinasjonsidentiteten på det stadiet. Proxyautentisering og destinasjonsautentisering held fram som separate sjølv om dei brukar den same underliggjande straumen.