Å oversette en SOCKS5-forespørsel til en HTTP-tunnel

Fullfør CONNECT-utvekslingen med forelderen, returner en SOCKS-respons til klienten og send først etterpå applikasjonsbytes.

En SOCKS5-frontend kan bruke en HTTP-proxy som sin videre transport. Den opptrer som SOCKS-tjener overfor klienten og som HTTP CONNECT-klient overfor forelderen. De to kontrollutvekslingene avsluttes før applikasjonsstrømmen starter.

SOCKS CONNECT-forespørselen leverer allerede destinasjonsverten eller -adressen og porten. For en illustrerende HTTP/1.1-utveksling med forelderen:

client → adapter: SOCKS5 CONNECT service.example.net:443
adapter → parent:
    CONNECT service.example.net:443 HTTP/1.1
    Host: service.example.net:443

parent → adapter: HTTP/1.1 200 Connection Established
                 [end of headers]
adapter → client: SOCKS5 success reply

client ↔ adapter ↔ parent ↔ service: application bytes

Oversett resultatet ved grensen

Adapteren fullfører all påkrevd autentisering hos forelderen og venter på CONNECT-resultatet. Et vellykket 2xx-svar etablerer tunnelen til forelderen. Først deretter bør den returnere den tilsvarende SOCKS-suksessresponsen til klienten nedstrøms.

Hvis forelderen avviser operasjonen, send en definert SOCKS-feilrespons, og avslutt deretter klientforbindelsen umiddelbart. SOCKS5 krever den lukkingen innen ti sekunder etter at feilen er oppdaget. Behold forelderens HTTP-status som diagnostisk informasjon for adapteren. Å videresende den statuslinjen som applikasjonsdata ville plassere en HTTP-kontrollmelding i en strøm der klienten forventer SOCKS-innramming.

Før et vellykket CONNECT-resultat snakker forelderen fortsatt HTTP, inkludert innrammingen av enhver utfordrings- eller feilrespons. Etter header-skilletegnet i et vellykket resultat blir forbindelsen tunnelen; det er ingen HTTP-responskropp å bruke først.

Bevar bytene etter headerne

Én lesing kan inneholde slutten av forelderens headere og bytes fra destinasjonen samtidig. Behold disse ekstra bytene for applikasjonen nedstrøms. Protokoller der tjeneren snakker først, kan hilse umiddelbart etter at forbindelsen deres åpnes.

Etter at SOCKS-suksessresponsen er sendt, videresend applikasjonsstrømmen i begge retninger. Adapteren trenger ikke veksle mellom én klientmelding og én tjenerrespons, og den trenger ikke forstå TLS-poster for å videresende dem. Protokollarbeidet dens var å etablere og oversette de to tunnel-forhandlingene.

Relaterte artikler