Vì sao ba bài kiểm tra tốc độ lại cho ra ba con số khác nhau

Ba câu trả lời, tất cả đều có cơ sở

Chạy thử trên ba trang khác nhau trong vòng một phút và bạn có thể thấy 300 Mbps, 180 Mbps và 90 Mbps. Rất dễ để cho rằng hai trong số đó đang bị hỏng. Trên thực tế, mỗi trang đang trả lời một câu hỏi hơi khác nhau, và độ chênh lệch giữa chúng mang nhiều thông tin hơn bất kỳ con số đơn lẻ nào.

Một bên đang đo dung lượng mà đường truyền có thể chở khi nó bị bão hòa một cách có chủ đích. Một bên đang đo một lượt tải xuống thực tế sẽ đi nhanh đến mức nào. Một bên khác có thể đang đo một tuyến đường không bao giờ rời khỏi mạng của chính nhà cung cấp của bạn. Đó là ba đại lượng hợp lệ với ba mục đích sử dụng hợp lệ.

Các kết nối song song làm thay đổi mức trần

Một kết nối TCP đơn lẻ cần thời gian để tăng tốc lên mức dung lượng tối đa của đường truyền. Mở tám hoặc mười sáu kết nối cùng lúc và mỗi kết nối sẽ tăng tốc song song, vì vậy tổng mức đạt tới trần nhanh hơn rất nhiều — và trong một bài đo ngắn, khác biệt đó là rất lớn. Do đó các bài kiểm tra đa luồng thường báo cáo con số cao hơn, và chúng là công cụ phù hợp khi câu hỏi là “tôi có nhận được đúng dung lượng mà mình đã trả tiền hay không.”

Các bài kiểm tra đơn luồng báo cáo con số thấp hơn và là công cụ phù hợp khi câu hỏi là “thực tế lượt tải này sẽ đi nhanh đến mức nào.” Một luồng video, một bản tải game, một tệp từ CDN và một cuộc gọi video trên thực tế đều là các luồng đơn. Khoảng cách giữa hai phương pháp không phải là lỗi đo lường; nó là sự khác biệt giữa một con số về dung lượng và một con số về mức phân phối thực tế.

Độ trễ (latency — thời gian khứ hồi của một gói tin) khuếch đại hiệu ứng này. Thời gian khứ hồi càng cao, một kết nối đơn lẻ càng mất nhiều thời gian để tăng tốc, vì vậy các đường truyền có độ trễ cao — vệ tinh, một số loại không dây cố định, các tuyến quốc tế dài — cho thấy độ chênh lệch lớn nhất giữa kết quả đơn luồng và đa luồng.

Vị trí máy chủ quyết định tuyến đường bạn đã đo

Các công cụ khác nhau dùng những mạng máy chủ khác nhau. Có công cụ chọn điểm cuối gần nhất hiện có, có công cụ dùng một mạng phân phối nội dung gắn với một dịch vụ cụ thể, và có công cụ dùng các máy chủ được đặt ngay trong mạng của một nhà cung cấp internet. Mỗi lựa chọn đo một tuyến đường khác nhau.

Một bài đo tới máy chủ nằm trong mạng của nhà cung cấp của bạn không bao giờ đi qua một điểm kết nối liên mạng, vì vậy nó hoàn toàn có thể báo cáo con số tốt nhất mà bạn từng thấy — và nó không nói lên điều gì về cách lưu lượng đi tới các dịch vụ nằm ngoài mạng đó. Một bài đo nhắm vào CDN của một nhà cung cấp nội dung cho bạn biết nhà cung cấp đó sẽ hoạt động ra sao, chứ không phải internet nói chung sẽ hoạt động ra sao. So sánh hai công cụ dùng những điểm cuối khác nhau là đang so sánh các tuyến đường không kém gì so sánh các kết nối.

Nguồn sai số lớn nhất thường nằm ngay tại chỗ

Những khác biệt về phương pháp thường được chú ý nhiều, nhưng trong việc đo lường hằng ngày, phần lớn sai số đến từ môi trường xung quanh:

• Dùng Wi-Fi thay vì Ethernet. Kết nối không dây bổ sung thêm độ trễ, jitter và sự biến thiên, vốn tăng lên theo khoảng cách, số bức tường và số thiết bị đang dùng chung băng tần. Với một gói cước nhanh, một bài đo có dây và một bài đo không dây trong cùng một phòng có thể chênh nhau một khoảng đáng kể.
• Lưu lượng chạy nền. Một tiến trình đồng bộ đám mây, một bản cập nhật hệ thống, một bản vá game hay luồng 4K của người khác đều tiêu thụ dung lượng trong khoảng thời gian đo.
• Tiện ích mở rộng của trình duyệt và VPN. Cả hai nằm ngay trên đường truyền và có thể giới hạn tốc độ hoặc đổi hướng lưu lượng của bài đo.
• Thời điểm trong ngày. Trên các kết nối dùng chung môi trường truyền dẫn, cùng một bài đo chạy lúc 10:00 và lúc 21:00 đang đo hai mạng khác nhau.

Đọc một con số trong bối cảnh của nó

Một bài kiểm tra tốc độ đo một tuyến đường, tới một máy chủ, tại một thời điểm, bằng một phương pháp truyền tải. Nó không chứng minh rằng mọi trang sẽ tải nhanh, rằng một máy chủ game sẽ cho cảm giác phản hồi tốt, rằng mạng gia đình được cấu hình hợp lý, hay rằng dung lượng sẽ được giữ vững trong giờ cao điểm. Hãy coi một kết quả như một ảnh chụp nhanh để chẩn đoán và coi phương pháp là một phần của kết quả — một con số thiếu đi các điều kiện của nó thì không phải là một phép đo.

Cũng đáng để tách biệt: throughput (lượng dữ liệu truyền được trong một đơn vị thời gian) và mức độ phản hồi là hai thứ độc lập. Một đường truyền có dung lượng rất cao nhưng độ trễ 200 ms tới CDN gần nhất sẽ cho cảm giác tệ hơn khi làm việc tương tác so với một đường truyền khiêm tốn với 10 ms. Nếu phàn nàn là “cứ thấy chậm,” thì con số Mbps thường là con số ít hữu dụng nhất trên màn hình.

Một quy trình đo có thể lặp lại

Việc chuẩn hóa các điều kiện quan trọng hơn chuyện bạn chọn công cụ nào.

1. Kết nối bằng Ethernet nếu có thể. Nếu bắt buộc dùng Wi-Fi, hãy ở cùng phòng với điểm truy cập và dùng băng tần 5 GHz hoặc 6 GHz.
2. Đóng mọi thứ đang di chuyển dữ liệu — sao lưu, trình đồng bộ, cập nhật, các luồng phát — trên thiết bị đo và trên bất kỳ thiết bị nào khác đang dùng chung kết nối.
3. Đo bằng một hồ sơ trình duyệt sạch, không có tiện ích mở rộng, không có VPN.
4. Chạy ba lần và lấy kết quả ở giữa thay vì kết quả tốt nhất.
5. Ghi lại thời điểm trong ngày, và lặp lại vào giờ bận rộn nhất mà bạn thường dùng mạng. Chênh lệch giữa hai lần chính là con số dự đoán trải nghiệm thực tế của bạn.
6. Nếu hai dịch vụ cho kết quả khác nhau, hãy thử cả hai với cùng một máy chủ ở gần trước khi kết luận rằng đường truyền có lỗi.

Làm điều này một lần vào khoảng giữa buổi sáng và một lần vào buổi tối, và bạn sẽ có một bức tranh về kết nối của mình chính xác hơn bất kỳ con số nổi bật đơn lẻ nào có thể mang lại.