Požadavek na připojení SOCKS4 uspěje, ale aplikace nikdy neuvidí úvodní pozdrav serveru. Jedním z míst, kam se podívat, je první čtení konektoru. Čtení šestnácti bajtů je pro osmibajtovou odpověď SOCKS4 příliš velké.

Pole odpovědiBajty
Pole verze odpovědi1
Kód výsledku1
Pole portu2
Pole adresy4

Kód výsledku 0x5a označuje, že požadavek byl schválen. SOCKS4a mění způsob, jakým požadavek nese název hostitele; nedělá z odpovědi šestnáct bajtů.

Po odpovědi nese stejný tok TCP protokol cíle. Poštovní server může svůj pozdrav odeslat okamžitě. Čtení, které spotřebuje šestnáct dostupných bajtů, proto může vzít úplnou odpověď proxy i prvních osm bajtů tohoto pozdravu. Pokud zatím nic nenásleduje, příliš velké blokující čtení může místo toho přidat zbytečné čekání.

Přesná délka je odpovědností parseru

Jednorázové vyžádání osmi bajtů není dostatečný důkaz, že osm bajtů dorazilo. Čtení toku může vrátit méně. Shromážděte přesně délku odpovědi v rámci lhůty, zastavte se při uzavřeném nebo selhaném toku, prohlédněte odpověď a následující bajty nechte aplikaci.

Pokud konektor používá větší bufferované čtení, zachovejte vše za hranicí a předejte to dalšímu spotřebiteli. Zahazování přebytku je stejná ztráta dat s jinou velikostí čtení.

SOCKS5 potřebuje vlastní parser. Adresa jeho odpovědi může mít podle typu adresy různou délku. Nahrazení každého čtení proxy pevným čtením osmi bajtů by opravilo jeden protokol, ale rozbilo jiný.

Související články