Phân Tích Sâu: Mạng Proxy Residential Hoạt Động Như Thế Nào? Giải Thích Kiến Trúc
Mạng proxy residential thực sự hoạt động như thế nào? Phân tích kỹ thuật về SDK, định tuyến ngang hàng, cân bằng tải và tối ưu hóa.
Đây là một câu hỏi mà nhiều người trong ngành công nghiệp proxy thường đặt ra. Dưới đây là giải thích về kiến trúc gần đúng đằng sau mỗi mạng proxy residential.
Để bắt đầu, hãy định nghĩa mạng residential là gì: một mạng các nút (peer) có khả năng định tuyến các gói dữ liệu đến các đích đến.
Nói một cách đơn giản, mạng proxy residential định tuyến các yêu cầu internet của bạn qua các thiết bị của những người thực tế. Những thiết bị này được tuyển dụng thông qua các ứng dụng mà họ đã đồng ý sử dụng, mạng chọn thiết bị tốt nhất cho mỗi yêu cầu, và phản hồi quay lại với bạn như thể bạn đã duyệt từ vị trí đó. Sự phức tạp bên dưới bề mặt là điều phân biệt giữa một mạng proxy residential nhanh, đáng tin cậy và một mạng chậm, không đáng tin cậy.
1. SDK
Các nút được tuyển dụng thông qua một SDK (Software Development Kit), được tích hợp vào các ứng dụng dành cho người tiêu dùng. Dựa trên sự đồng ý của người dùng, SDK cho phép mạng proxy residential định tuyến các gói dữ liệu qua thiết bị đến các đích đến. Đây là yếu tố cơ bản tạo điều kiện cho việc định tuyến các yêu cầu qua các thiết bị residential thực tế.
2. Yêu Cầu Tiêu Chuẩn Và Yêu Cầu Qua Proxy
Đây là cách một yêu cầu HTTPS tiêu chuẩn được định tuyến (L4 đến L7). Các số RTT dưới đây là tích lũy; mỗi lớp cộng vào tổng số đang chạy và giả định một kết nối mới:
Bắt Tay TCP (Bước: 1 RTT | Tích Lũy: 1 RTT)
Người dùng gửi SYN đến Đích
Đích gửi SYN-ACK đến Người dùng
Người dùng gửi ACK đến Đích (dữ liệu có thể đi kèm trong phân đoạn cuối cùng này)
Chi Phí Bước: 1 RTT, đưa thời gian tích lũy đang chạy lên 1 RTT. RFC 9293.
L5/L6: (Bước: 1 RTT cho TLS 1,3 / 2 RTT cho TLS 1,2 | Tích Lũy: 2 RTT với TLS 1,3 / 3 RTT với TLS 1,2)
Người dùng gửi ClientHello đến Đích
Đích gửi ServerHello, EncryptedExtensions, Certificate, CertificateVerify, Finished đến Người dùng
Chi Phí Bước: 1 RTT cho TLS 1,3 hiện đại (Tích Lũy: 2 RTT), hoặc 2 RTT cho TLS 1,2 cũ (Tích Lũy: 3 RTT)
Tự nó, TLS 1,3 là bắt tay 1-RTT, và TLS 1,2 là 2-RTT; các tổng số ở đây là tích lũy và bao gồm vòng khứ hồi TCP, vì vậy TLS 1,2 thêm một RTT đầy đủ (tổng cộng 3 RTT). TLS 1,3 cũng có thể thực hiện khôi phục 0-RTT trên các kết nối lặp lại, với sự đánh đổi replay đã biết.
L7: Lớp Ứng Dụng (Bước: 1 RTT | Tích Lũy: 3 RTT với TLS 1,3 / 4 RTT với TLS 1,2)
Người dùng gửi Yêu cầu + Tiêu đề đến Đích
Đích gửi Phản hồi + Tiêu đề đến Người dùng
Chi Phí Bước: 1 RTT, đưa thời gian cuối cùng đến byte dữ liệu đầu tiên là 3 RTT theo TLS 1,3 hoặc 4 RTT theo TLS 1,2
Khi bạn thêm proxy, nó luôn thêm ít nhất một hop và một lượng độ trễ: con đường dài hơn (người dùng → proxy → đích, và quay lại), và proxy thêm thời gian xử lý của riêng nó. Việc nó có thêm vòng khứ hồi hay không phụ thuộc vào loại proxy.
Một proxy kết thúc (một forward proxy HTTP sử dụng CONNECT, hoặc một gateway residential mở kết nối upstream của riêng nó) sẽ thêm chúng: client bắt tay với proxy trước, và đối với HTTPS, yêu cầu CONNECT và phản hồi «200 Connection Established» của nó là một vòng khứ hồi riêng trước khi quá trình bắt tay TLS end-to-end thậm chí bắt đầu, sau đó proxy tiếp tục bắt tay đến đích.
Một forwarder L3/L4 trong suốt không kết thúc kết nối để lại các quá trình bắt tay end-to-end và không thêm vòng khứ hồi bổ sung, chỉ là con đường dài hơn. Dù bằng cách nào, khoảng cách lớn hơn và nhiều trung gian hơn đồng nghĩa với độ trễ lớn hơn, và đó chính xác là điều mà phần còn lại của bài viết này hướng đến việc giảm thiểu.
3. Vấn Đề «Tắc Đường»
Mạng residential rất phức tạp vì có nhiều sắc thái trong việc định tuyến các yêu cầu một cách thông minh mà không làm chậm mạng.
Một phép so sánh tốt là mạng lưới đường bộ. Nếu quá nhiều ô tô chọn một tuyến đường, nó trở nên tắc nghẽn. Lý tưởng là không có tắc nghẽn trên mỗi tuyến đường, điều này chỉ có thể đạt được bằng cách thông minh định tuyến các yêu cầu dựa trên dung lượng của mỗi tuyến đường.
Mỗi nút có dung lượng hạn chế trước khi bị tắc nghẽn. Mạng proxy residential phải liên tục thu thập thông tin về dung lượng cấp mạng của mỗi thiết bị để cân bằng tải trên các nút, thỏa mãn khách hàng mà không làm tắc nghẽn các nút.
4. Tối Ưu Hóa Phía Nhà Cung Cấp
4a. DNS & Trung Tâm Dữ Liệu
Mạng residential nên tận dụng vận chuyển cấp trung tâm dữ liệu ở những nơi có thể. Ví dụ, nếu một khách hàng ở Tây Âu định tuyến qua các nút Đông Âu, mạng nên sử dụng bộ cân bằng tải DNS để nhận các gói đó ở Tây Âu và truyền chúng qua một tuyến trung tâm dữ liệu trực tiếp đến gateway gần nhất, giảm thiểu chi phí độ trễ đáng kể.
4b. Tối Ưu Hóa Lớp 4 Nội Bộ
Trên các nút gateway trung tâm dữ liệu, mạng nên sử dụng các tuyến trực tiếp và phân phối gateway trên toàn cầu để có độ phủ tốt. Giữa các gateway và các nút, mỗi gateway nên duy trì các kết nối TCP đã được khởi động sẵn và sử dụng mã hóa TLS lẫn nhau để bảo mật cả thiết bị và gateway.
4c. Tối Ưu Hóa Lớp 4 Bên Ngoài
SDK có thể duy trì các kết nối TCP đã được khởi động sẵn đến các đích phổ biến để tiết kiệm 1 RTT giữa nút và đích, vì lớp ứng dụng luôn có thể được xây dựng lại trên một kết nối TCP hiện có.
4d. Cấu Hình Thông Số
Các thông số TCP có thể được điều chỉnh trong thời gian thực để làm cho việc truyền gói hiệu quả hơn và giảm sử dụng CPU/RAM bởi SDK. Giảm thiểu tiêu thụ tài nguyên là điều quan trọng. Nếu SDK tạo ra trải nghiệm tiêu cực trên thiết bị của nút, các nhà xuất bản sẽ hủy hợp đồng SDK.
4e. Thuật Toán Định Tuyến Thông Minh (Dựa Trên Hiệu Suất)
Đây là tối ưu hóa khó nhất nhưng hiệu quả nhất. Mạng duy trì một cơ sở dữ liệu trong bộ nhớ theo thời gian thực trên tất cả các gateway, có thể được truy vấn ngay lập tức để trả lời: «Thiết bị nào phù hợp nhất để định tuyến yêu cầu này?»
Không có thuật toán này, cứ mỗi yêu cầu thứ hai có nguy cơ được định tuyến đến một nút chậm hoặc bị tắc nghẽn, và mạng sẽ sập dưới tải vừa phải.
4f. Thuật Toán IP Capping (Dựa Trên Danh Tiếng)
Mạng residential có lợi ích trong việc bảo vệ danh tiếng IP theo từng đích. Nếu một phần ba của nhóm bị đưa vào danh sách đen từ Đích A, B và C, người dùng nhắm mục tiêu vào những đích đó sẽ thấy tỷ lệ lỗi 33 %. Bằng cách chỉ định tuyến qua 67 % còn lại và đặt các IP bị đưa vào danh sách đen ở trạng thái cooldown, mạng cung cấp trải nghiệm khách hàng tốt hơn đáng kể.
Thuật toán IP Capping rất phức tạp để xây dựng và duy trì, nhưng mang lại những cải tiến đáng kể về chất lượng mạng khi thực hiện đúng cách.
5. Tối Ưu Hóa Phía Khách Hàng
5a. Trung Tâm Dữ Liệu
Khách hàng nên sử dụng máy chủ trong trung tâm dữ liệu nằm càng gần càng tốt với gateway gần nhất cho vùng nút mục tiêu của họ. Đối với các nút ở Hà Lan, trung tâm dữ liệu Amsterdam là lựa chọn hợp lý. Bạn cũng có thể traceroute đến gateway và chọn nhà cung cấp có đường đi ngắn nhất.
5b. DNS
Truyền chính tên miền thay vì địa chỉ IP đã được phân giải của nó. Điều này cho phép nút thực hiện phân giải DNS, có thể dẫn đến định tuyến hiệu quả hơn. Luôn bao gồm tên miền trong trường SNI để quá trình bắt tay TLS có thể thành công.
5c. Định Hướng Địa Lý
Mặc dù định hướng địa lý có thể giảm độ trễ đến các nút mục tiêu, nhưng nó cũng có nhược điểm. Nếu một khu vực địa lý cụ thể không có đủ nút để đáp ứng mức đồng thời của bạn, các yêu cầu sẽ thất bại hoặc độ trễ sẽ tăng đột ngột. Hãy nghiên cứu các giới hạn của khu vực địa lý mục tiêu và theo dõi các chỉ số tình trạng của nó trước khi phụ thuộc hoàn toàn vào nó.
5d. Tối Ưu Hóa L4 & Phiên Dính
Theo tiêu chuẩn ngành, xác thực được chuyển qua tiêu đề Proxy-Authorization được mã hóa Base64, cùng với các thông số yêu cầu như phiên dính và định hướng địa lý. Khi các yêu cầu đến gateway, các thông số này được giải mã và áp dụng.
Một người dùng proxy chuyên nghiệp duy trì một kết nối cho mỗi IP, giám sát IP thoát mỗi 10 đến 20 giây để xác nhận nút vẫn còn hoạt động, và cân bằng tải trên các nút dựa trên hiệu suất. Ví dụ, nếu một đích giới hạn tốc độ sau 50 yêu cầu, hãy dừng lại ở 25 đến 30, hoặc xoay vòng khi đạt đến giới hạn.
Nguyên tắc cốt lõi: khi không có đủ nút khả dụng, hãy tối đa hóa khả năng của mỗi nút, về giới hạn tốc độ, tốc độ mạng và quản lý tắc nghẽn.
Đăng bởi Alon Levi, CEO tại FlashProxy
Về tác giả: Alon Levi là CEO của FlashProxy và có kinh nghiệm sâu rộng về cơ sở hạ tầng proxy, kiến trúc mạng và các công nghệ định tuyến IP quy mô lớn.
Kết Nối Trên LinkedIn · Liên Hệ: [email protected]
Câu Hỏi Thường Gặp
Tại Sao Proxy Residential Chậm Hơn Proxy Trung Tâm Dữ Liệu?
Proxy residential định tuyến các yêu cầu qua các thiết bị người tiêu dùng thực trên các kết nối internet gia đình. Điều này thêm ít nhất một hop mạng bổ sung, và đối với các gateway kết thúc, các vòng khứ hồi thiết lập bổ sung, cộng thêm tốc độ biến động của băng thông gia đình, làm cho chúng chậm hơn so với proxy được lưu trữ trực tiếp trong các trung tâm dữ liệu.
Phiên Dính Trong Proxy Là Gì?
Phiên dính giữ các yêu cầu được định tuyến qua cùng một địa chỉ IP trong một khoảng thời gian đã đặt. Điều này hữu ích cho các tác vụ yêu cầu tính liên tục của phiên, chẳng hạn như duy trì trạng thái đăng nhập hoặc giữ một giỏ hàng.
Tại Sao Các IP Proxy Residential Bị Đưa Vào Danh Sách Đen?
Khi một IP residential gửi quá nhiều yêu cầu đến một đích cụ thể, trang web đó có thể đánh dấu và chặn nó. Mạng bị bão hòa quá mức hoặc được quản lý kém sẽ đẩy nhanh quá trình này, giảm nhóm IP có thể sử dụng cho tất cả người dùng.
Nút Proxy Là Gì?
Nút proxy là một thiết bị người tiêu dùng thực (điện thoại, máy tính hoặc TV thông minh) có kết nối internet được sử dụng để định tuyến lưu lượng proxy, với sự đồng ý của chủ sở hữu thiết bị, thông qua một SDK được tích hợp vào một ứng dụng mà họ đã cài đặt.
Nguồn & Tài Liệu Tham Khảo
IETF RFC 9293, Transmission Control Protocol: https://datatracker.ietf.org/doc/html/rfc9293
IETF RFC 8446, TLS 1,3 (1-RTT handshake; 0-RTT resumption): https://datatracker.ietf.org/doc/html/rfc8446
IETF RFC 5246, TLS 1,2 (2-RTT handshake): https://datatracker.ietf.org/doc/html/rfc5246
IETF RFC 9110, HTTP Semantics (CONNECT method): https://datatracker.ietf.org/doc/html/rfc9110
IETF RFC 6066, TLS Server Name Indication (SNI): https://datatracker.ietf.org/doc/html/rfc6066
IETF RFC 7235, HTTP/1,1 Authentication (Proxy-Authorization): https://datatracker.ietf.org/doc/html/rfc7235
MDN Web Docs, HTTP CONNECT method: https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Methods/CONNECT
Cloudflare, forward-proxy latency: https://blog.cloudflare.com/how-we-think-about-zero-trust-performance/
Cloudflare Learning Center, What is SNI?: https://www.cloudflare.com/learning/ssl/what-is-sni/
Ilya Grigorik, High Performance Browser Networking: https://hpbn.co/
