SOCKS5 წინა ნაწილს შეუძლია HTTP პროქსი გამოიყენოს როგორც თავისი შემდგომი ტრანსპორტი. ის მოქმედებს როგორც SOCKS სერვერი კლიენტის მიმართ და როგორც HTTP CONNECT კლიენტი მშობლის მიმართ. ორივე მართვის გაცვლა მთავრდება მანამ, სანამ აპლიკაციის ნაკადი დაიწყება.

SOCKS CONNECT მოთხოვნა უკვე იძლევა დანიშნულების ჰოსტს ან მისამართს და პორტს. საილუსტრაციო HTTP/1.1 გაცვლისთვის მშობელთან:

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

თარგმნეთ შედეგი საზღვარზე

ადაპტერი ასრულებს მშობლის მიერ მოთხოვნილ ნებისმიერ ავთენტიფიკაციას და ელოდება CONNECT შედეგს. წარმატებული 2xx პასუხი ამყარებს მშობლის გვირაბს. მხოლოდ ამის შემდეგ უნდა დააბრუნოს შესაბამისი SOCKS წარმატების პასუხი ქვედა დინების კლიენტთან.

თუ მშობელი უარყოფს ოპერაციას, გაგზავნეთ განსაზღვრული SOCKS წარუმატებლობის პასუხი, შემდეგ კი დაუყოვნებლივ შეწყვიტეთ კლიენტის კავშირი. SOCKS5 მოითხოვს ამ დახურვას უკმარისობის გამოვლენიდან ათი წამის განმავლობაში. შეინახეთ მშობლის HTTP სტატუსი როგორც დიაგნოსტიკური ინფორმაცია ადაპტერისთვის. იმ სტატუსის ხაზის აპლიკაციის მონაცემებად გადაცემა ჩასვამდა HTTP მართვის შეტყობინებას იმ ნაკადში, რომლის კლიენტიც SOCKS ჩარჩოებას ელოდება.

წარმატებული CONNECT შედეგის წინ მშობელი ჯერ კიდევ HTTP-ზე საუბრობს, მათ შორის ნებისმიერი გამოწვევის ან შეცდომის პასუხის ჩარჩოება. წარმატებული შედეგის სათაურების გამყოფის შემდეგ კავშირი გვირაბი ხდება; წინასწარ არ არის მოსახმარი HTTP პასუხის სხეული.

შეინახეთ სათაურების შემდგომი ბაიტები

ერთი წაკითხვა შეიძლება შეიცავდეს მშობლის სათაურების დასასრულს და დანიშნულებიდან მოსულ ბაიტებს ერთად. შეინახეთ ეს დამატებითი ბაიტები ქვედა დინების აპლიკაციისთვის. პროტოკოლები, სადაც სერვერი პირველი ლაპარაკობს, შეიძლება მაშინვე მიესალმოს კავშირის გახსნისთანავე.

SOCKS წარმატების პასუხის გაგზავნის შემდეგ გადააწოდეთ აპლიკაციის ნაკადი ორივე მიმართულებით. ადაპტერს არ სჭირდება ერთი კლიენტის შეტყობინების ერთი სერვერის შეტყობინებით მონაცვლეობა და არც TLS ჩანაწერების გაგება მათი გადაცემისთვის. მისი პროტოკოლური სამუშაო იყო ორი გვირაბის მოლაპარაკების დამყარება და თარგმნა.

დაკავშირებული სტატიები