Bạn đang khởi chạy một trình phân tích hoặc làm nóng tài khoản qua proxy, tính toán chi phí dựa trên kích thước trang - và nhận được hóa đơn cao gấp 2-3 lần so với dự kiến. Vấn đề không phải là sự lừa dối từ nhà cung cấp: tất cả những gì thực sự đi qua kênh đều được tính vào lưu lượng - tiêu đề yêu cầu, bắt tay TLS, các lần thử lại kết nối và các gói điều khiển. Chúng ta sẽ phân tích những gì tạo nên "hóa đơn" cho lưu lượng và cách giảm chi phí mà không làm giảm chất lượng công việc.
Nhà cung cấp thực sự tính lưu lượng như thế nào
Khi bạn đánh giá chi phí "bằng mắt", trong đầu bạn thường có công thức: kích thước trang HTML cộng với hình ảnh. Nhưng nhà cung cấp proxy tính tổng khối lượng dữ liệu đã đi qua cả hai hướng của kênh - hướng ra (yêu cầu) và hướng vào (phản hồi). Trong khối lượng này không chỉ bao gồm tải hữu ích mà còn toàn bộ lưu lượng điều khiển: tiêu đề giao thức, siêu dữ liệu TLS, gói ACK TCP, các lần thử lại kết nối khi hết thời gian.
Đối với một yêu cầu đến một trang thông thường, tỷ lệ "dữ liệu hữu ích" so với "dữ liệu điều khiển" có thể là 80/20. Nhưng nếu bạn làm việc với API, nơi các phản hồi nhỏ (vài kilobyte JSON), và có nhiều tiêu đề và bắt tay - tỷ lệ này dễ dàng đảo ngược. Đó là lý do tại sao các nhà môi giới, những người gửi hàng chục nghìn yêu cầu nhỏ đến các API quảng cáo hoặc thị trường, thường ngạc nhiên với hóa đơn: mỗi yêu cầu đều mang một "thuế" cố định bất kể kích thước tải hữu ích.
Một điểm quan trọng khác: nhà cung cấp tính lưu lượng ở cấp độ máy chủ proxy, tức là toàn bộ lưu lượng thực sự đã đi qua IP - bao gồm cả các lần thử không thành công, chuyển hướng, tải lại tài nguyên trên trang (kiểu, kịch bản, trình theo dõi), mà script hoặc trình duyệt của bạn đã yêu cầu tự động, ngay cả khi bạn chỉ cần văn bản.
Tiêu đề HTTP/HTTPS: trọng lượng ẩn của mỗi yêu cầu
Mỗi yêu cầu HTTP và mỗi phản hồi đều mang một tập hợp các tiêu đề: User-Agent, Cookie, Accept-Language, Referer, Content-Type và hàng chục tiêu đề khác. Trong các trình duyệt hiện đại và các công cụ chống phát hiện (Dolphin Anty, AdsPower, Multilogin), tập hợp tiêu đề có thể chiếm từ 500 byte đến 2-3 KB cho mỗi yêu cầu - đặc biệt nếu trong cookie đã tích lũy một phiên với hàng chục giá trị.
Ví dụ: nếu bạn thực hiện 10.000 yêu cầu đến API của một thị trường với cookie phiên có kích thước 1.5 KB, chỉ riêng tiêu đề đã tiêu tốn khoảng 15 MB lưu lượng - và điều này chưa tính đến nội dung phản hồi. Khi mở rộng cho nhiều tài khoản và hồ sơ, con số này tăng theo tỷ lệ.
| Loại tiêu đề | Kích thước trung bình | Tác động đến lưu lượng |
|---|---|---|
| User-Agent | 100-150 byte | Thấp, nhưng tích lũy khi mở rộng |
| Cookie (phiên) | 500-2000 byte | Cao trong các phiên dài |
| Referer / Origin | 50-200 byte | Thấp |
| Tiêu đề Accept-* | 150-300 byte | Thấp |
| Tiêu đề phản hồi từ máy chủ | 300-800 byte | Trung bình, không phụ thuộc vào bạn |
Kết luận thực tiễn: nếu bạn viết một script để theo dõi giá trên Wildberries hoặc Ozon, hãy làm sạch cookie khỏi các giá trị không sử dụng và không kéo theo các tiêu đề thừa, được sao chép "phòng trường hợp" từ DevTools của trình duyệt.
Bắt tay TLS: bao nhiêu lưu lượng bị tiêu tốn cho mã hóa
Hầu hết các trang web hiện đại hoạt động qua HTTPS, có nghĩa là mỗi kết nối mới bắt đầu bằng một cuộc bắt tay TLS - trao đổi chứng chỉ, khóa mã hóa và các tham số giao thức. Một cuộc bắt tay TLS hoàn chỉnh (TLS 1.2 hoặc 1.3) có kích thước từ 4 đến 8 KB tùy thuộc vào kích thước chứng chỉ của trang web và các phần mở rộng giao thức được sử dụng.
Nếu bạn mở một kết nối mới cho mỗi yêu cầu (và không sử dụng kết nối cố định), cuộc bắt tay TLS sẽ lặp lại mỗi lần. Với 10.000 yêu cầu mà không tái sử dụng kết nối, bạn sẽ nhận thêm 40-80 MB lưu lượng chỉ cho mã hóa - điều này có thể nhiều hơn cả nội dung hữu ích.
TLS 1.3 nhẹ hơn một chút so với TLS 1.2 nhờ vào số lượng vòng đi vòng lại được rút ngắn, nhưng sự khác biệt chỉ rõ ràng khi có nhiều kết nối. Đối với các proxy di động, nơi mà chính mạng của nhà cung cấp thêm độ trễ và tái thiết lập phiên, overhead của TLS cảm nhận rõ ràng hơn - điều này cần được xem xét khi chọn proxy di động cho các nhiệm vụ có yêu cầu ngắn và thường xuyên.
Thử lại: cách các yêu cầu lặp lại làm tăng gấp đôi chi phí
Thử lại là mục chi phí lưu lượng khó nhận thấy nhất và cũng là đắt đỏ nhất. Nếu trình phân tích hoặc script của bạn được cấu hình để tự động thử lại khi hết thời gian hoặc gặp lỗi 429/503, mỗi yêu cầu không thành công đã tiêu tốn lưu lượng cho việc thiết lập kết nối, bắt tay TLS và tiêu đề - và sau đó toàn bộ quá trình này lại lặp lại.
Một lỗi phổ biến trong tự động hóa SMM và phân tích thị trường là chính sách thử lại quá mạnh mà không có độ trễ theo cấp số nhân: script thực hiện 5 lần thử liên tiếp với khoảng thời gian một giây khi có dấu hiệu đầu tiên của việc chặn IP. Kết quả là, cho một phản hồi "hữu ích", lưu lượng tiêu tốn cho năm lần thử không thành công cộng với yêu cầu thành công cuối cùng.
Điều này đặc biệt nghiêm trọng khi làm việc với proxy trung tâm dữ liệu trên các trang web có bảo vệ mạnh (ví dụ: Avito hoặc các thị trường lớn), có thể trả về captcha hoặc chặn hầu hết các yêu cầu từ IP "nóng". Trong trường hợp này, có lý do để xem xét proxy cư trú - chúng ít bị chặn ngay từ yêu cầu đầu tiên, điều này giảm số lần thử lại và do đó giảm chi phí lưu lượng thực tế.
Keep-Alive so với các kết nối mới
HTTP Keep-Alive cho phép tái sử dụng một kết nối TCP/TLS cho nhiều yêu cầu liên tiếp, tránh việc bắt tay lại. Đây là một trong những tối ưu hóa lưu lượng hiệu quả nhất, có sẵn trong hầu hết các khách hàng HTTP và trình duyệt chống phát hiện.
Nếu bạn sử dụng các thư viện để phân tích (requests, httpx, axios) mà không chỉ định rõ ràng phiên với kết nối cố định, mỗi yêu cầu theo mặc định có thể mở một kết nối TCP mới. Khi kết hợp với proxy, điều này có nghĩa là: một kết nối mới đến máy chủ proxy, một TLS mới đến trang web mục tiêu, và toàn bộ overhead lại lặp lại cho mỗi lần gọi.
| Chế độ kết nối | Overhead trên 1000 yêu cầu |
|---|---|
| Kết nối mới cho mỗi yêu cầu | 4-8 MB (chỉ TLS) |
| Keep-Alive, một phiên cho 50 yêu cầu | 0.1-0.2 MB (một bắt tay cho nhóm) |
Sự khác biệt là rất lớn - và đây là tiết kiệm lưu lượng thuần túy mà không làm thay đổi tải hữu ích của các yêu cầu.
Cách các loại proxy tính lưu lượng
Mô hình thanh toán lưu lượng phụ thuộc vào loại proxy. Proxy trung tâm dữ liệu thường có hình thức tính phí theo khối lượng lưu lượng hoặc theo số lượng IP/cổng - cơ sở hạ tầng tự nó nhanh hơn và thêm overhead tối thiểu cho việc định tuyến. Đối với proxy cư trú và di động, lưu lượng thường được tính phí chặt chẽ hơn, vì IP thực của người dùng là một tài nguyên đắt đỏ và hạn chế hơn, trong khi lộ trình qua nhà cung cấp hoặc nhà cung cấp dịch vụ tại nhà thêm các bước nhảy bổ sung và do đó một chút dữ liệu điều khiển nhiều hơn.
Proxy di động trong nghĩa này là "đắt đỏ" nhất về lưu lượng: mạng di động thêm các cơ chế tái thiết lập phiên riêng, chuyển đổi NAT và đôi khi nén/giải nén lưu lượng ở cấp độ nhà cung cấp, điều này làm tăng số liệu dữ liệu đã đi qua so với cùng một yêu cầu qua mạng cố định.
Nếu nhiệm vụ là duy trì một khối lượng yêu cầu ổn định cao với overhead tối thiểu (ví dụ: phân tích giá hàng loạt trên Wildberries hoặc Ozon), thì proxy trung tâm dữ liệu là lựa chọn tốt nhất - chúng nhanh hơn và dự đoán được hơn về chi phí lưu lượng cho các nhiệm vụ tương tự.
Cách giảm chi phí lưu lượng trong thực tế
Chúng ta sẽ xem xét các bước cụ thể làm giảm chi phí lưu lượng thực tế mà không làm mất chức năng của trình phân tích, tự động hóa hoặc nhiều tài khoản.
1. Tắt tải các tài nguyên không cần thiết. Nếu bạn chỉ cần văn bản của trang hoặc phản hồi JSON từ API, hãy tắt tải hình ảnh, phông chữ, script phân tích và trình theo dõi quảng cáo trong cài đặt của trình duyệt chống phát hiện hoặc công cụ headless. Điều này thường giảm chi phí lưu lượng từ 60-80% cho các nhiệm vụ phân tích.
2. Sử dụng Keep-Alive và nhóm kết nối. Cấu hình khách hàng HTTP để tái sử dụng phiên cho một nhóm yêu cầu đến một máy chủ - điều này giảm mạnh số lượng bắt tay TLS.
3. Thiết lập chính sách thử lại hợp lý. Độ trễ theo cấp số nhân (1 giây → 2 giây → 4 giây) với giới hạn 3 lần thử thay vì 5-10 lần thử liên tiếp mạnh mẽ làm giảm lưu lượng không cần thiết từ các yêu cầu không thành công và đồng thời giảm nguy cơ bị chặn IP thêm.
4. Làm sạch cookie và tiêu đề phiên. Thỉnh thoảng xóa các giá trị cookie tích lũy không được sử dụng bởi trang web mục tiêu - đặc biệt quan trọng cho các phiên dài làm nóng tài khoản trên Instagram hoặc TikTok qua trình duyệt chống phát hiện.
5. Lưu trữ các phản hồi tĩnh. Nếu dữ liệu (ví dụ: danh mục sản phẩm) không thay đổi mỗi phút, hãy lưu trữ phản hồi cục bộ thay vì gửi yêu cầu lại qua proxy trong mỗi chu kỳ theo dõi.
6. Sử dụng nén. Kiểm tra xem tiêu đề Accept-Encoding: gzip có được gửi đi và máy chủ thực sự trả về phản hồi nén hay không - điều này giảm khối lượng lưu lượng đầu vào trên các trang có nhiều văn bản hoặc JSON.
Công cụ theo dõi lưu lượng
Để hiểu lưu lượng thực sự đi đâu, hữu ích không chỉ nhìn vào đồng hồ của nhà cung cấp mà còn vào phân tích chi tiết các yêu cầu. Các công cụ phù hợp bao gồm:
- Charles Proxy / Fiddler - hiển thị kích thước của mỗi yêu cầu và phản hồi, bao gồm cả tiêu đề, giúp tìm ra các cookie "nặng" hoặc tài nguyên thừa.
- Wireshark - để phân tích sâu về overhead TCP/TLS ở cấp độ gói, nếu cần đánh giá trọng lượng thực sự của bắt tay.
- Các đồng hồ lưu lượng tích hợp trong trình duyệt chống phát hiện (Dolphin Anty, AdsPower, GoLogin) - nhiều công cụ hiển thị chi phí cho từng hồ sơ riêng biệt, điều này thuận tiện cho việc phân bổ ngân sách giữa các tài khoản.
- Ghi log ở cấp độ khách hàng HTTP - khi viết các script phân tích riêng, hữu ích để ghi lại kích thước yêu cầu/phản hồi cho mỗi lần gọi, để tìm ra các bất thường.
So sánh số liệu của các công cụ của bạn với đồng hồ của nhà cung cấp proxy giúp nhanh chóng hiểu nơi lưu lượng bị mất - trong các lần thử lại, TLS hoặc tải các tài nguyên thừa.
Danh sách kiểm tra tối ưu hóa trước khi khởi chạy
Trước khi khởi chạy quy mô lớn trình phân tích, tự động hóa SMM hoặc làm nóng tài khoản quảng cáo, hãy kiểm tra danh sách ngắn sau:
- Tắt tải hình ảnh, phông chữ, phân tích ở những nơi không cần thiết;
- Cấu hình Keep-Alive / tái sử dụng phiên cho một loạt yêu cầu đến một máy chủ;
- Chính sách thử lại bị giới hạn trong 2-3 lần thử với độ trễ, thay vì lặp lại vô tận;
- Cookie phiên được làm sạch định kỳ khỏi các giá trị không sử dụng;
- Bật nén phản hồi (gzip/deflate/br);
- Có lưu trữ cục bộ cho các yêu cầu tĩnh lặp lại;
- Loại proxy được chọn theo nhiệm vụ: trung tâm dữ liệu cho tốc độ và khối lượng, cư trú để vượt qua các chặn, di động cho mạng xã hội và nền tảng quảng cáo.
Kết luận
Chi phí lưu lượng qua proxy không chỉ là dữ liệu hữu ích của trang mà còn là toàn bộ overhead điều khiển: tiêu đề, bắt tay TLS, các lần thử lại khi gặp lỗi. Hiểu được cơ chế này cho phép lập kế hoạch ngân sách cho proxy chính xác hơn và tránh những bất ngờ khó chịu trong hóa đơn, đặc biệt khi mở rộng phân tích thị trường, tự động hóa SMM hoặc làm nóng tài khoản quảng cáo.
Nếu nhiệm vụ của bạn là phân tích ổn định với chi phí lưu lượng dự đoán được, hãy chú ý đến proxy trung tâm dữ liệu. Đối với việc làm việc với mạng xã hội và nền tảng quảng cáo, nơi tần suất chặn thấp là quan trọng, proxy di động là lựa chọn tốt hơn. Và nếu bạn cần sự cân bằng giữa tính ẩn danh và sự ổn định để vượt qua bảo vệ của các trang web - hãy xem xét proxy cư trú, giúp giảm số lần thử lại nhờ vào việc ít bị chặn hơn.