Vì sao tải xuống qua VPN lại nhanh hơn kết nối trực tiếp

Kết nối đường hầm, bắt đầu một lượt tải lớn và nó chạy với tốc độ gần gấp đôi tốc độ mà cùng tệp đó đạt được khi không có đường hầm. Nghe như quảng cáo, nhưng trên một đường truyền tại nhà đây có thể là phép đo thật. Nguyên nhân thường gặp là một giới hạn tốc độ gắn với một cổng: đường hầm mang dữ liệu của bạn đến nơi bộ định hình không nhìn tới, và dung lượng thật của đường truyền lần đầu xuất hiện.

Nghĩa là con số đáng quan tâm không phải VPN nhanh đến đâu. Mà là bạn đã không nhận được bao nhiêu phần đường truyền của mình, và vì sao.

Một giới hạn đi theo cổng, không phải theo tuyến

Nhà cung cấp truy cập có thể giới hạn thông lượng trên mỗi thuê bao theo giao thức hoặc cổng đích, và cổng 80 là mục tiêu ưa thích vì phần lớn việc duyệt web thông thường dùng nó. Giới hạn thường không áp dụng từ gói đầu tiên: quá trình truyền bắt đầu gần tốc độ đường truyền, đốt hết hạn mức bùng nổ rồi mới ổn định ở con số bị giới hạn. Những giây đầu trông khỏe mạnh còn phần còn lại thì không.

Gửi đúng số byte đó qua một cổng khác và bộ định hình ở cổng 80 không bao giờ thấy chúng. Đường hầm trông như đánh bại kết nối trực tiếp dù đã thêm một chặng, mã hóa và chi phí riêng của nó. Thứ được cải thiện không phải đường đi mà là việc không có một quy tắc.

Đó cũng là lý do hiệu ứng này rất nhất quán giữa các tệp và đích đến. Nếu giới hạn nằm ở cổng, mọi thứ đi qua cổng đó đều hành xử như nhau, bất kể kích thước tệp và ai là máy chủ. Một đích đến thu hút quy tắc khác sẽ cho một đường cong khác, và chính sự khác biệt đó đã là chẩn đoán.

Đo đoạn bằng phẳng, không đo đỉnh

Đỉnh là phần ít thông tin nhất của một lượt truyền, vì mọi kết nối đều trông tốt khi bộ đệm đang đầy lên. Ghi lại nơi tốc độ ổn định và nó giữ được bao lâu.

curl -o /dev/null -w '%{speed_download} %{time_total}\n' https://<host>/test.bin
scp user@<transfer-host>:/data/test.bin /tmp/

Chạy hai phép đo liền nhau trên cùng một máy, vào cùng giờ, hướng tới các máy chủ trong những mạng tương đương. Một mẫu không chứng minh được gì; hình dạng đường cong qua hai lần chạy của mỗi bên mới là thứ phân biệt hạn mức bùng nổ với một giới hạn ổn định. Ghi lại nơi tốc độ bằng phẳng thay vì những gì giây đầu tiên cho thấy, vì bùng nổ chính là thứ bộ định hình dành cho bạn trước khi bắt đầu giới hạn. Một đoạn bằng phẳng êm ả giữ được đến cuối lượt truyền là con số để so sánh.

Giữ tệp đã được nén sẵn để không thể lấy nén vận chuyển làm lời giải thích. Một tệp PDF hoặc một kho lưu trữ loại bỏ biến số đó, và cũng ngăn bất kỳ ai lập luận rằng đường hầm đã nén dữ liệu. Nếu hai lượt truyền dùng cùng một tệp, khác biệt duy nhất còn lại là tuyến và cổng. Ghi lại công cụ và cổng bên cạnh mỗi con số, nếu không lần chạy thứ hai sẽ không so sánh được với lần đầu.

Ba phép so sánh cô lập nguyên nhân

Làm theo thứ tự và dừng ngay khi hình mẫu rõ ràng, vì mỗi phép loại trừ một câu chuyện khác.

1. Lặp lại cùng lượt tải đó qua đường web thông thường và qua một công cụ truyền trên cổng khác, từ một máy chủ có dung lượng tương đương.
2. Lặp lại cả hai với một tệp không nén được, để nén không còn là ứng viên.
3. Nếu bạn tự vận hành máy chủ đường hầm, hãy gắn lại nó vào cổng 80, chỉnh hồ sơ máy khách để hai đầu khớp nhau, rồi truyền lại. Nếu đường hầm giờ nằm ở tốc độ web bị giới hạn, thì giới hạn đi theo cổng chứ không phải VPN.

Bước thứ ba là bước quyết định, và cũng là bước người ta bỏ qua vì nó đòi hỏi thay đổi cấu hình. Không có bước đó, bạn mới chỉ cho thấy hai thứ khác nhau, chứ không phải cổng là nguyên nhân.

Điều phép đo này không thể chống đỡ

Nó không cho thấy đường hầm nói chung nhanh hơn, rằng nó nén thứ gì, hay rằng các cổng khác trên đường truyền không bị giới hạn. Nó mô tả lượt truyền này, trên đường truyền này, vào giờ này. Giới hạn có thể áp theo phiên, theo thuê bao hoặc theo thời điểm trong ngày, và chúng có thể thay đổi mà không báo trước.

Nó cũng không chứng minh tuyến trực tiếp bị hỏng. Một tuyến bị giới hạn vẫn hoạt động; nó bị giới hạn có chủ đích, và một chính sách có chủ đích không phải sự cố đang chờ sửa.

Và nó chắc chắn không biện minh cho việc định tuyến mọi thứ qua đường hầm. Mọi ứng dụng trên cổng 80 vẫn bị giới hạn, trong khi mọi thứ bạn chuyển hướng giờ phụ thuộc vào thêm một chặng và thêm một kiểu hỏng.

Biến phát hiện thành việc có thể làm

Viết quan sát như một phép đo chứ không phải phán quyết: các lượt truyền lớn qua cổng 80 ổn định ở khoảng một nửa tốc độ mà cùng tệp đạt được trên cổng khác, vào những giờ này, trên đường truyền này, kèm theo những mẫu này. Đó là một yêu cầu hỗ trợ mà ai đó có thể điều tra.

«VPN nhanh hơn» thì không phải. Câu đó mời một phản hồi về chi phí mã hóa, và phản hồi ấy đúng về kỹ thuật trong khi không nói với ai điều gì hữu ích. Đính kèm số mẫu, giờ và cổng, để người đọc có thể tái tạo hình mẫu.

Nếu bạn quyết định tiếp tục dùng cổng khác cho các lượt truyền lớn, hãy ghi lưu ý đó vào hồ sơ của mình: chuyển một trình lắng nghe sang cổng 80 sẽ xung đột với bất kỳ máy chủ web nào đã gắn ở đó, và sự cố phát sinh trông giống một đường hầm hỏng hơn là xung đột cổng.