Vì sao hai bài kiểm tra tốc độ VPN trên cùng một đường hầm lại không khớp

Hai lần chạy, một đường hầm, và các con số lệch nhau ba lần. Đường hầm không đổi giữa hai lần. Thứ đã đổi là phép đo: một trang kiểm tra chọn máy chủ dựa trên vị trí bề ngoài của bạn, số luồng quyết định một khởi đầu chậm hay sáu khởi đầu đang làm đầy ống, và thời lượng đủ ngắn để kết thúc trước khi tuyến được dùng đúng cách. Các bài kiểm tra tốc độ không sai, nhưng chúng trả lời một câu hỏi hẹp hơn câu hỏi mà người ta đặt ra cho chúng.

Địa chỉ ra mới đổi đích đến của bài kiểm tra

Phần lớn các trang kiểm tra tự động chọn máy chủ đo, và họ chọn một phần dựa trên việc kết nối của bạn có vẻ đến từ đâu. Bật đường hầm lên và quốc gia bề ngoài của bạn thay đổi, nên máy chủ được chọn thay đổi, và phép so sánh giờ trải trên hai tuyến khác nhau tới hai máy chủ khác nhau.

Kết quả hoàn toàn không phải là phép đo VPN. Đó là phép đo tuyến của bạn tới một máy chủ mà bạn không chọn, và khác biệt giữa hai lần chạy có thể bị chi phối bởi việc kết nối mạng của máy chủ đó hơn là bởi bất cứ điều gì đường hầm đã làm.

Hãy cố định đích đến trước khi đổi bất cứ điều gì khác. Mọi công cụ đáng tin đều cho phép bạn chọn máy chủ một cách rõ ràng, và khi không cho, trang kết quả thường nêu tên máy chủ đã dùng, đủ để nhận ra hai lần chạy không so sánh được. Hãy xác nhận những gì trang đã thấy trước khi tin vào lựa chọn của nó:

curl -sS https://ipinfo.io/json | grep -E '"ip"|"org"|"country"'

Nếu quốc gia thay đổi giữa các lần chạy thì mọi thứ bài kiểm tra chọn sau đó cũng đổi. Ghi lối ra quan sát được bên cạnh từng kết quả và sự nhầm lẫn phần lớn biến mất.

Khởi đầu chậm kết thúc sau khi phần lớn các bài kiểm tra ngắn đã kết thúc

Một kết nối TCP không bắt đầu ở tốc độ của tuyến. Nó bắt đầu với một cửa sổ tắc nghẽn nhỏ, tăng gấp đôi cửa sổ đó gần như mỗi vòng khứ hồi, và chỉ đạt dung lượng của tuyến sau vài vòng. Một bài kiểm tra mười giây trên tuyến có độ trễ cao có thể dành một phần đáng kể vòng đời của nó trong giai đoạn leo dốc đó.

Đó là lý do một đường hầm có độ trễ cao hơn ghi điểm kém hơn mức nó xứng đáng trong một bài kiểm tra ngắn, và cũng là lý do một lần chạy dài hơn thường báo con số cao hơn mà không cần đổi cấu hình nào. Khung thông lượng RFC 6349 xử lý điều này một cách rõ ràng, và vì thế các phép đo nghiêm túc kéo dài đủ lâu để đạt trạng thái ổn định. Một lần chạy năm giây trên tuyến vệ tinh đo bộ tăng tốc, không phải con đường.

Hãy xem các giai đoạn của kết nối thay vì tin vào một con số duy nhất. Curl báo từng giai đoạn riêng, nên bạn thấy được thời gian đi vào bắt tay, vào giai đoạn leo dốc hay vào việc truyền:

curl -sS -o /dev/null -w 'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} total=%{time_total} bytes/s=%{speed_download}\n' \
  https://mirror.example.net/testfile.bin

Chạy nó hai lần liên tiếp tới cùng đích. Nếu lần thứ hai nhanh hơn nhiều thì bạn đang đo giai đoạn leo dốc chứ không phải tuyến, và mọi so sánh chỉ dùng lần đầu đều đáng ngờ.

Một luồng và sáu luồng đo những thứ khác nhau

Một luồng TCP bị giới hạn bởi cửa sổ mà nó giữ được trên đường truyền, tức là xấp xỉ thời gian khứ hồi nhân với tốc độ. Trên một tuyến dài, tích đó vượt quá mức một luồng sẽ dùng, nên một lần tải xuống báo thấp hơn dung lượng thực có. Sáu luồng song song lấp khoảng trống đó và cho con số lớn hơn.

iperf3 -c speed.example.net -t 20
iperf3 -c speed.example.net -t 20 -P 6
mtr -rwc 50 speed.example.net

Cả hai con số đều đúng. Con số một luồng cho biết một lần tải xuống sẽ làm được gì, đó là mức một thẻ trình duyệt thường nhận. Con số song song cho biết tuyến có thể chở tổng cộng bao nhiêu, đó là mức một torrent hay một lần tải nhiều phần có thể dùng. Trích dẫn cái này như thể là cái kia chính là cách một đường hầm khỏe mạnh bị thay thế mà không có lý do.

So sánh kết quả song song với kết quả một luồng là cách phổ biến nhất để người ta kết luận rằng VPN đã giảm một nửa tốc độ của họ. Hãy canh phương pháp cho bằng nhau rồi mới so sánh. Dấu vết trong lệnh thứ ba thêm phần bối cảnh còn thiếu: một tuyến có rung động cao sẽ cho kết quả không nhất quán ở cả hai chế độ, và không số luồng nào sửa được điều đó.

Mã hóa tốn thời gian bộ xử lý, đóng gói tốn byte

Hai cơ chế chạy trên mọi gói tin bất kể tuyến nhanh đến đâu. Mã hóa tiêu tốn bộ xử lý trên mỗi byte, và đóng gói thêm byte tiêu đề mà tuyến vẫn phải chở. Cả hai đều hiện ra như một mức trần, và chúng có triệu chứng khác nhau.

Mức trần bộ xử lý hiện ra như một cao nguyên: thông lượng ngừng tăng dù bạn thêm bao nhiêu luồng, và bộ xử lý của máy bận trong khi tuyến thì không. Trên một router nhỏ hay một chiếc điện thoại, đó thường là giới hạn thật, và vì thế một đường truyền nhanh vẫn có thể cho một đường hầm khiêm tốn.

Chi phí byte nhỏ hơn nhưng không đổi. Tiêu đề thêm nghĩa là ít tải hữu ích hơn trên mỗi gói, và trên một tuyến có đơn vị truyền tối đa cố định, chúng cũng có thể gây phân mảnh hoặc lỗ đen, biểu hiện như một lần đứng hình khi truyền lớn chứ không phải như một mức trung bình chậm.

Ba thứ này thường bị nhầm lẫn vì người dùng mô tả cả ba là VPN chậm. Chỉ cái thứ nhất phản ứng với một máy mạnh hơn, chỉ cái thứ hai phản ứng với MTU nhỏ hơn, và chỉ cái thứ ba phản ứng với việc quản lý hàng đợi.

Ghi phương pháp vào biên bản

Một kết quả đáng lưu nêu tên thiết bị, mạng truy cập, lối ra, máy chủ đo, hướng, số luồng và thời lượng. Không có những thứ đó, hai con số không thể so sánh, và một phiếu chỉ có một con số thật ra chỉ là một tâm trạng.

Hãy giữ cả những lần chạy tệ. Một chuỗi trong đó một lối ra gây đứng hình mỗi lần có nhiều thông tin hơn một mức trung bình, và những lần đứng hình chính là thứ mà các mức trung bình che giấu.

Sau đó hãy kiểm tra điều bạn thực sự quan tâm. Nếu mục tiêu là một lần tải xuống lớn, hãy tải tệp. Nếu mục tiêu là một cuộc gọi, hãy đo độ trễ dưới tải thay vì thông lượng khi rảnh, vì một đường hầm có thể đạt điểm tốt trong bài kiểm tra tốc độ mà vẫn khiến mọi cuộc họp không nghe được.