Proxy SOCKS và HTTP: Khác biệt, tốc độ và chọn giao thức
Proxy HTTP và SOCKS kết nối ứng dụng với đích qua trung gian. Với trình duyệt, công cụ thu thập web hoặc máy khách API, proxy HTTP có CONNECT là lựa chọn khởi đầu thực tế. SOCKS5 hữu ích khi ứng dụng yêu cầu SOCKS, cần giao thức TCP khác hoặc hỗ trợ chuyển tiếp UDP. Cả hai đều mang được lưu lượng đến website HTTPS.
Giao thức quyết định cách chương trình giao tiếp với proxy. Nguồn gốc IP đầu ra, xoay và quyền dùng chung hay chuyên dụng là các lựa chọn riêng, được giải thích trong hướng dẫn loại proxy và chọn cấu hình. Đổi HTTP sang SOCKS không tự thay các thuộc tính đó.
Cách HTTP và SOCKS xử lý kết nối
Chuyển tiếp HTTP: proxy xử lý yêu cầu web
Với yêu cầu HTTP thông thường không mã hóa, máy khách gửi URL đích, phương thức và tiêu đề cho proxy. Proxy xử lý yêu cầu rồi lấy phản hồi từ đích. Nó có thể áp quy tắc HTTP, sửa tiêu đề hoặc dùng bộ nhớ đệm nếu được cấu hình. Đây là chức năng có thể có của proxy HTTP; dịch vụ không nhất thiết bật tất cả.
SOCKS5: proxy mở kết nối cho ứng dụng
Máy khách thỏa thuận phương thức xác thực, xác thực nếu cần rồi gửi địa chỉ và cổng đích. Proxy thiết lập kết nối TCP được yêu cầu và chuyển tiếp các byte của ứng dụng. Cùng cơ chế có thể mang HTTPS, SSH hoặc giao thức ứng dụng TCP được hỗ trợ khác. Proxy không cần diễn giải yêu cầu HTTP để chuyển tiếp.
HTTPS qua CONNECT: hai cách trở nên gần nhau hơn
Khi mở website HTTPS qua proxy HTTP thông thường, máy khách thường gửi yêu cầu CONNECT. Sau khi proxy chấp nhận đường hầm, máy khách thiết lập TLS với website bên trong. Proxy chuyển tiếp dữ liệu mã hóa. SOCKS5 có thể chuyển tiếp cùng trao đổi TLS sau các bước thiết lập riêng.
Điều này quan trọng khi so tốc độ và riêng tư: proxy HTTP mang HTTPS trong đường hầm không phân tích từng yêu cầu trang được mã hóa. Cả hai loại chuyển tiếp lưu lượng được bảo vệ. Trình tự và khác biệt giữa chuyển tiếp HTTP với đường hầm có trong Proxy HTTP và HTTPS.
Tổng quan HTTP và SOCKS5
So sánh bên dưới dùng SOCKS5. SOCKS4 và SOCKS4a cũ hơn có ít tính năng và chủ yếu liên quan khi phần mềm hiện có yêu cầu chúng.
| Khả năng | Proxy HTTP / HTTPS | Proxy SOCKS5 |
|---|---|---|
| Yêu cầu web | Chuyển tiếp HTTP; HTTPS thường dùng đường hầm CONNECT. | Ứng dụng gửi HTTP hoặc HTTPS qua kết nối đã thiết lập. |
| Ứng dụng TCP khác | Có thể qua CONNECT nếu máy khách hỗ trợ và cổng đích được cho phép. | Phù hợp tự nhiên với ứng dụng hỗ trợ SOCKS; quy tắc dịch vụ vẫn áp dụng. |
| DNS đích | Proxy có thể phân giải tên máy nhận trong yêu cầu hoặc đích CONNECT. | Máy khách có thể gửi tên máy để phân giải từ xa hoặc tự phân giải cục bộ trước. |
| Bảo vệ đường đến proxy | Proxy HTTPS dùng TLS trên kết nối này. Proxy HTTP thuần không dùng. | Chế độ thông thường không xác thực và tên người dùng/mật khẩu không mã hóa kết nối này. |
| Kiểm soát truy cập | Phương thức xác thực HTTP và/hoặc quy tắc dịch vụ như danh sách IP được phép. | Phương thức xác thực đã thương lượng và/hoặc quy tắc dịch vụ như danh sách IP được phép. |
| UDP | CONNECT thông thường không đủ. UDP cần cơ chế đường hầm bổ sung được hỗ trợ. | Giao thức có định nghĩa, nhưng máy khách và dịch vụ phải triển khai. |
| Hiệu năng | Với đường hầm HTTPS mới, thiết lập có thể cần ít lượt khứ hồi hơn. Tốc độ truyền cũng phụ thuộc triển khai và tuyến đường. | Có trao đổi thiết lập riêng. Không phân tích HTTP không đảm bảo truyền HTTPS nhanh hơn. |
HTTP hay SOCKS5 nhanh hơn?
Kết nối HTTPS mới có thể sẵn sàng sớm hơn qua HTTP CONNECT vì thiết lập thông thường cần ít trao đổi với proxy hơn. So sánh bên dưới nêu các giả định đằng sau khác biệt. Khi đường hầm đã mở, lượt tải dài hoặc yêu cầu sau có thể dùng lại. Không giao thức nào có lợi thế cố định về tốc độ truyền duy trì.
Kết nối mới: đếm số trao đổi
Đếm thông điệp thiết lập sau khi kết nối TCP đến proxy sẵn sàng, mỗi yêu cầu chờ phản hồi của nó. So sánh này không có lớp TLS đến proxy. Xác thực HTTP hoặc không cần, hoặc thành công với thông tin xác thực kèm ngay yêu cầu CONNECT đầu.
| Cách kết nối | Trao đổi trước khi đường hầm sẵn sàng |
|---|---|
HTTP CONNECT | 1: yêu cầu CONNECT và phản hồi thành công. |
| SOCKS5 không xác thực ở cấp giao thức | 2: chọn phương thức, rồi yêu cầu kết nối và phản hồi. |
| SOCKS5 dùng tên người dùng và mật khẩu | 3: chọn phương thức, xác minh tên người dùng/mật khẩu, rồi yêu cầu kết nối và phản hồi. |
Do đó, theo các giả định này SOCKS5 thêm một lượt khứ hồi máy khách–proxy khi không xác thực, hoặc hai lượt với xác thực tên người dùng/mật khẩu tiêu chuẩn. Lượt khứ hồi, hay RTT, là thời gian thông điệp đến proxy và phản hồi quay lại. Với RTT minh họa 50 ms, trao đổi thêm chiếm khoảng 50 hoặc 100 ms. Đây là ước tính từ trình tự giao thức, không phải phép đo chuẩn dịch vụ proxy hay tổng thời gian yêu cầu.
Cả hai đường vẫn cần proxy kết nối đích và máy khách hoàn tất TLS của website. Thời gian DNS, xử lý và tắc nghẽn có thể khác. Thử thách xác thực HTTP thêm trao đổi; TLS đến proxy HTTPS có thiết lập riêng. Cần tính những trường hợp này khi so cấu hình thực tế.
Dùng lại kết nối: khác biệt ban đầu được phân bổ qua nhiều yêu cầu
Nhóm kết nối giữ các kết nối phù hợp cho yêu cầu sau. Dùng lại kết nối HTTPS tránh lặp TCP, thương lượng proxy và bắt tay TLS website cho từng yêu cầu. Nếu máy khách và đích hỗ trợ HTTP/2, nhiều luồng yêu cầu có thể chung một kết nối đã thiết lập. Điều này hoạt động trong cả đường hầm HTTP CONNECT lẫn kết nối SOCKS5; proxy không phải phân tích thông điệp HTTP/2 trong TLS.
Tạo đối tượng máy khách HTTP mới cho từng URL có thể bỏ nhóm kết nối của nó. Ở đây, dùng lại máy khách nghĩa là giữ đối tượng phần mềm và kết nối, không phải yêu cầu proxy giữ IP đầu ra. Khi một đợt công việc liên tục liên hệ cùng tên máy, dùng lại kết nối có thể tiết kiệm nhiều thao tác thiết lập hơn đổi giao thức proxy. Đích mới, kết nối bị đóng và thiết lập proxy đổi vẫn có thể cần đường hầm mới.
Truyền dữ liệu lớn: xem băng thông khả dụng
Khi đường hầm đã thiết lập, tốc độ tải phụ thuộc tuyến đường, mất gói, băng thông sẵn có, tải proxy và giới hạn dịch vụ. Chuyển tiếp HTTPS qua CONNECT vốn đã là chuyển tiếp byte. Nói SOCKS5 nhanh hơn vì “không đọc HTTP” bỏ sót trường hợp này.
Với HTTP không mã hóa, bộ nhớ đệm hoặc xử lý nội dung được cấu hình có thể đổi kết quả. Phản hồi từ bộ nhớ đệm là tải khác với tải cùng nội dung từ máy chủ gốc. So sánh công bằng phải tính khác biệt này.
Tập lệnh web quy mô lớn nên dùng giao thức nào?
Tập lệnh web vẫn gửi yêu cầu HTTP khi dùng SOCKS5; lựa chọn proxy đổi cách nó đến máy chủ. Với tập lệnh mới lấy trang hoặc gọi API HTTPS, bắt đầu bằng máy khách HTTP đã hoàn thiện và HTTP CONNECT, trừ khi nhu cầu cụ thể chỉ hướng khác. Đặt lựa chọn proxy trong cấu hình để thử SOCKS5 bằng cùng logic yêu cầu. Chọn thư viện hỗ trợ cả hai nếu so sánh này quan trọng với dự án.
| Khối lượng công việc | Lựa chọn khởi đầu thực tế |
|---|---|
| Nhiều yêu cầu ngắn, thường đến tên máy mới | Thử HTTP CONNECT trước. Thương lượng ngắn hơn có thể giúp khi thường mở đường hầm mới. Đo các yêu cầu hoàn tất thành công. |
| Nhiều yêu cầu tới tập nhỏ API hoặc website | Dùng máy khách tồn tại lâu, nhóm kết nối và HTTP/2 nếu hỗ trợ. So HTTP và SOCKS5 sau khi kiểm tra khả năng dùng lại. |
| Tệp lớn hoặc phiên TCP kéo dài | Chọn giao thức được hỗ trợ tốt và thử thông lượng duy trì cùng gián đoạn. Thời gian thiết lập là phần nhỏ hơn của công việc. |
| Giao thức TCP khác hoặc tính năng UDP bắt buộc | Cân nhắc SOCKS5 nếu ứng dụng hỗ trợ chế độ cần. Nếu UDP thiết yếu, xác minh ứng dụng và dịch vụ trao đổi được datagram qua proxy. |
Phần mềm bất đồng bộ dùng được cả HTTP lẫn SOCKS5. Giao thức proxy không quyết định yêu cầu chạy đồng thời hay không. Kiểm tra thư viện máy khách dùng được chế độ đã chọn cho yêu cầu đồng thời, giữ nhóm kết nối và giới hạn số thao tác đang chạy. Tăng mức đồng thời trong khi theo dõi công việc hoàn tất và lỗi: khi proxy, mạng hoặc đích chạm giới hạn, thêm kết nối có thể khiến hàng đợi dài và phải thử lại nhiều hơn.
Cách so tốc độ trước khi tăng quy mô
- Dùng cùng chương trình, yêu cầu đích, kích thước phản hồi và mức đồng thời. Nếu có thể, so các điểm kết nối giao thức với cùng IP đầu ra và tuyến đường; nếu không, giữ vùng đầu ra và giới hạn dịch vụ tương đương rồi ghi khác biệt.
- Chạy một loạt với kết nối mới, loạt khác với nhóm kết nối bình thường sau khởi động làm nóng. Giữ hành vi DNS, bảo vệ TLS, xác thực, phiên bản HTTP và chính sách thử lại tương đương hoặc ghi lý do khác.
- Đo số thao tác hoàn tất thành công mỗi giây và thời gian cả đợt, gồm thử lại. Cũng ghi thời gian hoàn tất trung vị và phân vị thứ 95, số lần hết thời gian chờ và thao tác lỗi. Phân vị thứ 95 cho biết thời gian mà 95% thao tác được đo đã hoàn tất.
- Với tải tệp, ghi byte hữu ích nhận mỗi giây. Với yêu cầu ngắn, tách thiết lập kết nối khỏi thời gian đến byte đầu và tổng thời gian phản hồi. Thời gian đến byte đầu cũng gồm chờ đích tạo phản hồi.
- Lặp xen kẽ hai cấu hình và xác minh tuyến proxy dự kiến. Nếu một lần thử dùng nhóm đầu ra khác hoặc quay về kết nối trực tiếp, kết quả không tách riêng tác động giao thức proxy.
Chọn cấu hình hoàn tất công việc thực nhanh hơn với tỷ lệ lỗi chấp nhận được. Xác thực lỗi nhanh hoặc phản hồi thiếu không phải thông lượng hữu ích. Nếu cả hai tương tự, ưu tiên cách đơn giản hơn để hỗ trợ trong ứng dụng đã chọn.
Vì sao cần xét hỗ trợ ứng dụng trước
Ô có nhãn “proxy” không hứa mọi giao thức hoặc cách xác thực. Ví dụ, SOCKS5 tích hợp trong Chrome hỗ trợ yêu cầu TCP nhưng không triển khai xác thực tên người dùng/mật khẩu SOCKS5 hay chuyển tiếp UDP. Dịch vụ SOCKS5 có các tính năng đó không thể khiến chế độ trình duyệt không hỗ trợ dùng được chúng.
Với SSH, truyền tệp hoặc ứng dụng TCP khác, hỗ trợ SOCKS sẵn có có thể thuận tiện. HTTP CONNECT cũng mang giao thức TCP khác nếu chương trình tạo được đường hầm và proxy cho phép cổng đích. Vì vậy, “proxy HTTP” không phải luôn nghĩa là “chỉ lưu lượng web”.
Cài proxy trình duyệt cũng không tự bao phủ chương trình khác hay mọi tính năng của trình duyệt. Bộ điều hợp bên ngoài có phạm vi và hạn chế riêng. Khác biệt phiên bản và thương lượng có trong Proxy SOCKS5 và SOCKS4.
Ai phân giải tên máy đích?
Với SOCKS5, ứng dụng có thể phân giải đích cục bộ rồi gửi IP, hoặc gửi tên máy để proxy phân giải. Trong curl, socks5:// chọn phân giải đích cục bộ, còn socks5h:// yêu cầu phân giải qua proxy. Chữ thêm chọn hành vi máy khách, không tạo giao thức SOCKS mới.
Proxy HTTP cũng tra được tên đích trong URL hoặc yêu cầu CONNECT. Vì vậy, cả hai giao thức đều có DNS đích từ xa. Tra từ phía proxy có thể trả địa chỉ máy chủ khác và tránh tra cục bộ cho đích đó. Máy khách vẫn có thể cần phân giải tên proxy, ứng dụng khác giữ cấu hình DNS riêng. Chọn hành vi DNS trong máy khách thay vì suy ra từ giao thức proxy.
Kết nối nào được mã hóa?
Tách bảo vệ nội dung website khỏi bảo vệ đường đến proxy. Website HTTPS thông thường giữ dữ liệu ứng dụng mã hóa giữa máy khách và website qua cả hai loại đường hầm. Điều này giả định kiểm tra chứng chỉ bình thường và không cấu hình chặn giải mã TLS.
Proxy HTTPS thêm TLS giữa máy khách và proxy. Nó bảo vệ yêu cầu proxy và thông tin xác thực trên đoạn đó. Trong địa chỉ proxy, https:// thường chỉ kết nối được bảo vệ này. Thiết lập chỉ mô tả là “proxy cho website HTTPS” có thể thực chất là proxy HTTP thuần hỗ trợ CONNECT.
Thông tin xác thực HTTP Basic gửi đến proxy HTTP thuần và trao đổi tên người dùng/mật khẩu SOCKS5 tiêu chuẩn có thể được đọc bởi người quan sát đường mạng không bảo vệ. TLS website thiết lập sau không bảo vệ ngược phần đăng nhập proxy trước đó. SOCKS5 thông thường cần phương thức truyền an toàn riêng khi cần bảo vệ này.
Proxy vẫn là đầu cuối của kết nối TLS riêng và biết nơi nó được yêu cầu kết nối. Nếu đích cuối dùng HTTP thuần, TLS đến proxy không mã hóa đoạn HTTP tiếp theo. Tương tự, chuyển tiếp SOCKS không che nội dung chưa mã hóa chỉ vì proxy không cần phân tích.
UDP hoặc HTTP/3 có đổi lựa chọn không?
Với ứng dụng thực sự cần UDP, SOCKS5 định nghĩa UDP ASSOCIATE. Máy khách và dịch vụ phải triển khai, đường mạng phải mang được datagram. HTTP CONNECT thông thường mang đường hầm TCP. Chuyển tiếp UDP dựa trên HTTP có thể dùng cơ chế bổ sung như CONNECT-UDP, nhưng cả hai đầu phải triển khai.
HTTP/3 dùng QUIC trên UDP. Trang HTTPS tải thành công qua proxy không chứng minh HTTP/3 hoạt động: máy khách có thể dùng HTTP/2 hoặc HTTP/1.1 qua TCP. Cách dự phòng này có thể phù hợp tập lệnh web, nhưng không thay UDP cho tính năng cần datagram. Xem UDP và QUIC qua proxy về đường chuyển tiếp và hạn chế.
SOCKS có giấu máy khách tốt hơn không?
Với chuyển tiếp HTTP không mã hóa, proxy có thể thêm tiêu đề như Forwarded mang thông tin máy khách gốc. Đường hầm HTTPS CONNECT thông thường không thể chèn tiêu đề vào yêu cầu mã hóa nếu không kết thúc TLS của website tại proxy. SOCKS5 cũng không tự thêm tiêu đề HTTP.
Điều này không khiến giao thức nào đảm bảo ẩn danh hay được website chấp nhận. Bên vận hành proxy có thể quan sát siêu dữ liệu kết nối, còn đích nhận ra tài khoản, cookie hoặc hành vi ứng dụng. Uy tín IP đầu ra và số người dùng chung là yếu tố riêng. Chuyển HTTP sang SOCKS trên cùng dịch vụ không tự bỏ chặn hay đặt lại phiên website.
Cách quyết định cuối cùng
Bắt đầu với giao thức và cách truy cập ứng dụng hỗ trợ. Với tự động hóa web thông thường, HTTP CONNECT là lựa chọn đầu hợp lý; với ứng dụng xây dựng quanh SOCKS hoặc chế độ UDP được hỗ trợ, SOCKS5 có thể phù hợp hơn. Sau đó chọn hành vi DNS và bảo vệ đến proxy cần thiết rồi so hiệu năng với tải thật.
Dùng tên máy và cổng thật của dịch vụ cho giao thức đã chọn. Đổi http:// thành socks5:// trong cấu hình không bật SOCKS trên máy chủ không cung cấp. Trước khi tăng quy mô, xác nhận yêu cầu ra qua proxy dự kiến và proxy lỗi không âm thầm kích hoạt đường trực tiếp ngoài ý muốn.