SOCKS5-fronto povas uzi HTTP-prokurilon kiel sian pluan transporton. Ĝi agas kiel SOCKS-servilo rilate al la kliento kaj kiel HTTP CONNECT-kliento rilate al la gepatra servilo. La du regadaj interŝanĝoj finiĝas antaŭ ol la aplikaĵa fluo komenciĝas.

La peto SOCKS CONNECT jam liveras la celan gastigan nomon aŭ adreson kaj la pordon. Por ilustra HTTP/1.1-interŝanĝo kun la gepatra servilo:

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

Traduku la rezulton ĉe la limo

La adaptilo plenumas ĉiun postulatan aŭtentigon ĉe la gepatra servilo kaj atendas la CONNECT-rezulton. Sukcesa 2xx-respondo starigas la gepatran tunelon. Nur tiam ĝi resendu la konforman SOCKS-sukcesrespondon al la malsupra kliento.

Se la gepatra servilo rifuzas la operacion, sendu difinitan SOCKS-malsukcesrespondon, poste tuj finu la klientan konekton. SOCKS5 postulas tiun fermon ene de dek sekundoj post la konstato de la malsukceso. Konservu la HTTP-statuson de la gepatra servilo kiel diagnostikan informon por la adaptilo. Transdoni tiun statuslinion kiel aplikaĵajn datumojn metus HTTP-regadmesaĝon en fluon, kies kliento atendas SOCKS-kadrigon.

Antaŭ sukcesa CONNECT-rezulto, la gepatra servilo ankoraŭ parolas HTTP, inkluzive de la kadrigo de iu ajn defia aŭ erara respondo. Post la kaplinia disigilo de sukcesa rezulto, la konekto fariĝas la tunelo; ne estas HTTP-respondkorpo por unue konsumi.

Konservu la bajtojn post la kaplinioj

Unu legado povas enhavi la finon de la gepatraj kaplinioj kaj bajtojn de la celo kune. Konservu tiujn kromajn bajtojn por la malsupra aplikaĵo. Protokoloj, en kiuj la servilo parolas unue, povas saluti tuj post kiam ilia konekto malfermiĝas.

Post kiam la SOCKS-sukcesrespondo estas sendita, transdonu la aplikaĵan fluon en ambaŭ direktojn. La adaptilo ne bezonas alternigi unu klientan mesaĝon kun unu servilan mesaĝon, kaj ĝi ne bezonas kompreni TLS-rikordojn por transdoni ilin. Ĝia protokola laboro estis starigi kaj traduki la du tunelajn intertraktadojn.

Rilataj artikoloj