წაიკითხე რვა ბაიტი და შემდეგ გადაეცი SOCKS4 გვირაბი
აირიდე დანიშნულების მისალმების ჩაყლაპვა ან არარსებული ბაიტების ლოდინი SOCKS4 პასუხის ფიქსირებული საზღვრის ანალიზით.
SOCKS4 კავშირის მოთხოვნა წარმატებით სრულდება, მაგრამ აპლიკაცია ვერასოდეს ხედავს სერვერის შესავალ მისალმებას. ერთი ადგილი, სადაც უნდა გაიხედოს, კონექტორის პირველი წაკითხვაა. თექვსმეტი ბაიტის წაკითხვა ძალიან დიდია რვაბაიტიანი SOCKS4 პასუხისთვის.
| პასუხის ველი | ბაიტი |
|---|---|
| პასუხის ვერსიის ველი | 1 |
| შედეგის კოდი | 1 |
| პორტის ველი | 2 |
| მისამართის ველი | 4 |
შედეგის კოდი 0x5a მიუთითებს, რომ მოთხოვნა დაკმაყოფილდა. SOCKS4a ცვლის, თუ როგორ ატარებს მოთხოვნა ჰოსტის სახელს; ის პასუხს თექვსმეტ ბაიტად არ აქცევს.
პასუხის შემდეგ იგივე TCP ნაკადი ატარებს დანიშნულების პროტოკოლს. საფოსტო სერვერმა შეიძლება თავისი მისალმება მაშინვე გამოგზავნოს. ამიტომ თექვსმეტი ხელმისაწვდომი ბაიტის მჭამელმა წაკითხვამ შეიძლება წაიღოს პროქსის სრული პასუხი და ამ მისალმების პირველი რვა ბაიტი. თუ ჯერ არაფერი მოჰყვება, ზედმეტად დიდმა ბლოკირებულმა წაკითხვამ შეიძლება ნაცვლად არასაჭირო ლოდინი დაამატოს.
ზუსტი სიგრძე პარსერის პასუხისმგებლობაა
რვა ბაიტის ერთხელ მოთხოვნა საკმარისი მტკიცებულება არ არის, რომ რვა ბაიტი ჩამოვიდა. ნაკადის წაკითხვებმა შეიძლება ნაკლები დააბრუნოს. შეაგროვე პასუხის სიგრძე ზუსტად ვადის განმავლობაში, გაჩერდი დახურულ ან წარუმატებელ ნაკადზე, შეამოწმე პასუხი და დარჩენილი ბაიტები აპლიკაციას დაუტოვე.
თუ კონექტორი უფრო დიდ ბუფერულ წაკითხვას იყენებს, შეინახე ყველაფერი საზღვრის შემდეგ და გადაეცი შემდეგ მომხმარებელს. ნამეტის გადაგდება იგივე მონაცემთა დაკარგვაა სხვა წაკითხვის ზომით.
SOCKS5-ს საკუთარი პარსერი სჭირდება. მისი პასუხის მისამართის სიგრძე მისამართის ტიპის მიხედვით შეიძლება განსხვავდებოდეს. ყოველი პროქსის წაკითხვის ფიქსირებული რვაბაიტიანი წაკითხვით ჩანაცვლება ერთ პროტოკოლს გაასწორებდა და მეორეს გააფუჭებდა.