Prečítajte osem bajtov a potom odovzdajte tunel SOCKS4
Vyhnite sa prehltnutiu pozdravu cieľa alebo čakaniu na neexistujúce bajty analýzou pevnej hranice odpovede SOCKS4.
Požiadavka na pripojenie SOCKS4 uspeje, ale aplikácia nikdy neuvidí úvodný pozdrav servera. Jedným z miest, kam sa pozrieť, je prvé čítanie konektora. Čítanie šestnástich bajtov je pre osembajtovú odpoveď SOCKS4 príliš veľké.
| Pole odpovede | Bajty |
|---|---|
| Pole verzie odpovede | 1 |
| Kód výsledku | 1 |
| Pole portu | 2 |
| Pole adresy | 4 |
Kód výsledku 0x5a označuje, že požiadavka bola schválená. SOCKS4a mení spôsob, akým požiadavka nesie názov hostiteľa; nerobí z odpovede šestnásť bajtov.
Po odpovedi nesie ten istý tok TCP protokol cieľa. Poštový server môže svoj pozdrav odoslať okamžite. Čítanie, ktoré spotrebuje šestnásť dostupných bajtov, preto môže vziať úplnú odpoveď proxy aj prvých osem bajtov tohto pozdravu. Ak zatiaľ nič nenasleduje, príliš veľké blokujúce čítanie môže namiesto toho pridať zbytočné čakanie.
Presná dĺžka je zodpovednosťou parsera
Jednorazové vyžiadanie ôsmich bajtov nie je dostatočným dôkazom, že osem bajtov dorazilo. Čítania toku môžu vrátiť menej. Zozbierajte presne dĺžku odpovede v rámci lehoty, zastavte sa pri uzavretom alebo zlyhanom toku, preskúmajte odpoveď a nasledujúce bajty nechajte aplikácii.
Ak konektor používa väčšie bufferované čítanie, zachovajte všetko za hranicou a odovzdajte to ďalšiemu spotrebiteľovi. Zahadzovanie prebytku je tá istá strata údajov s inou veľkosťou čítania.
SOCKS5 potrebuje vlastný parser. Adresa jeho odpovede môže mať podľa typu adresy rôznu dĺžku. Nahradenie každého čítania proxy pevným čítaním ôsmich bajtov by opravilo jeden protokol, ale pokazilo iný.