Prevajanje zahteve SOCKS5 v tunel HTTP

Dokončajte izmenjavo CONNECT s staršem, vrnite odjemalcu odgovor SOCKS in šele nato posredujte bajte aplikacije.

Čelni del SOCKS5 lahko uporablja proxy HTTP kot svoj nadaljnji transport. Deluje kot strežnik SOCKS proti odjemalcu in kot odjemalec HTTP CONNECT proti staršu. Izmenjavi nadzora se končata preden se začne tok aplikacije.

Zahteva SOCKS CONNECT že prinaša ciljnega gostitelja ali naslov in vrata. Za ponazoritveno izmenjavo HTTP/1.1 s staršem:

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

Prevedite rezultat na meji

Adapter opravi vso zahtevano overjanje pri staršu in počaka na rezultat CONNECT. Uspešen odgovor 2xx vzpostavi tunel do starša. Šele nato mora odjemalcu nižje poslati ustrezni odgovor SOCKS o uspehu.

Če starš operacijo zavrne, pošljite določen odgovor SOCKS o neuspehu in nato takoj prekinite povezavo odjemalca. SOCKS5 zahteva to zaprtje v desetih sekundah po zaznavi neuspeha. Status HTTP starša hranite kot diagnostično informacijo za adapter. Posredovanje te statusne vrstice kot podatkov aplikacije bi v tok, katerega odjemalec pričakuje okvirjanje SOCKS, vstavilo nadzorno sporočilo HTTP.

Pred uspešnim rezultatom CONNECT starš še vedno govori HTTP, vključno z okvirjanjem vsakega odgovora z izzivom ali napako. Po ločilu glav uspešnega rezultata povezava postane tunel; najprej ni nobenega telesa odgovora HTTP za porabo.

Ohranite bajte za glavami

Eno branje lahko vsebuje konec glav starša in bajte iz cilja skupaj. Te dodatne bajte ohranite za aplikacijo nižje. Protokoli, kjer strežnik govori prvi, lahko pozdravijo takoj po odprtju povezave.

Po pošiljanju odgovora SOCKS o uspehu posredujte tok aplikacije v obe smeri. Adapterju ni treba izmenjevati enega odjemalčevega sporočila z enim strežnikovim sporočilom in mu ni treba razumeti zapisov TLS, da bi jih posredoval. Njegovo protokolarno delo je bilo vzpostavitev in prevajanje obeh tunelskih pogajanj.

Sorodni članki