Cách một cổng proxy có thể nhận cả HTTP và SOCKS

Một trình lắng nghe proxy hỗn hợp có thể nhận HTTP và SOCKS trên một cổng TCP vì máy chủ kiểm tra các byte giao thức đầu tiên. Số cổng không thực hiện việc nhận diện đó.

Một yêu cầu proxy HTTP bắt đầu bằng một phương thức HTTP, chẳng hạn GET hoặc CONNECT. Lời chào SOCKS bắt đầu bằng các trường giao thức nhị phân. Phần mềm được thiết kế cho các đầu vào này có thể chuyển kết nối đến trình xử lý thích hợp.

Đây là một đặc điểm triển khai rõ ràng. Một trình lắng nghe HTTP thông thường của Squid không trở nên hỗn hợp chỉ vì cổng của nó được đổi thành 1080, và một trình lắng nghe chỉ SOCKS không học HTTP từ cài đặt của trình duyệt.

TLS thêm một ranh giới khác: một kết nối proxy được mã hóa bắt đầu bằng TLS, không phải bằng một phương thức HTTP nhìn thấy được. Hỗ trợ nó trên cùng một điểm cuối đòi hỏi cách xử lý có chủ đích bổ sung; việc nhận ra HTTP văn bản thuần và SOCKS không chứng minh khả năng đó.

Hãy dùng giao thức máy khách được ghi trong tài liệu cho điểm cuối. Nếu cả hai đều hoạt động, đó là bằng chứng về trình lắng nghe hỗn hợp của máy chủ đó, không phải lý do để bỏ trống giao thức trong mọi máy khách.

Trình lắng nghe hỗn hợp của Glider đưa ra một ví dụ cụ thể: nó nhìn vào một byte mà không tiêu thụ nó, gửi 0x05 đến trình xử lý SOCKS5 của mình, và nếu không thì gọi trình phân tích cú pháp HTTP của nó. Trình phân tích đó vẫn xác thực yêu cầu đến; việc lựa chọn gửi đi không làm cho đầu vào tùy ý trở thành HTTP hợp lệ.

Việc chia sẻ trình lắng nghe TCP tự nó không cung cấp liên kết UDP của SOCKS5. Glider khởi động trình lắng nghe UDP của mình riêng. Việc chọn giao thức TCP và việc chuyển tiếp datagram sau đó là những khả năng riêng biệt.