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

Bạn bắt đầu một bản tải lớn, vài giây đầu có vẻ bình thường, rồi tốc độ ổn định ở khoảng một nửa mức mà đường truyền phải cung cấp. Bạn kết nối đường hầm, lặp lại đúng bản tải đó, và nó giữ tốc độ cao hơn suốt cả tệp. Đó vừa là một phép đo thật vừa là một kết luận gây nhầm lẫn, vì đường hầm không làm đường đi nhanh hơn. Nó chỉ chuyển lưu lượng của bạn ra khỏi một cổng mà thứ gì đó trên đường đang giới hạn.

Hình dạng của đường cong tố cáo điều đó

Hãy nhìn quá trình truyền chứ không phải con số cuối. Một đường bị giới hạn thường bắt đầu gần tốc độ đường truyền, tiêu hết hạn mức bùng nổ rồi ổn định ở mức trần, nên giá trị trung bình phụ thuộc vào việc bạn quan sát bao lâu. Một đường hầm thực sự cải thiện đường đi sẽ cho thấy tốc độ tốt hơn ngay từ giây đầu và giữ được nó. Vùng phẳng chính là dấu vân tay, và rất dễ bỏ sót nếu bạn chỉ ghi lại đỉnh.

Hai lần chạy cùng một tệp, một trực tiếp và một qua đường hầm, là đủ để xem có vùng phẳng hay không.

Ghi lại khi nào vùng phẳng bắt đầu, kéo dài bao lâu và giữ tốc độ nào. Ba giá trị đó phân biệt một bộ định hình với một đường bị tắc nghẽn, vì tắc nghẽn để tốc độ dao động trong khi bộ định hình ghim nó vào một con số. Nếu lần chạy trực tiếp xấu dần và lần chạy qua đường hầm vẫn ổn định, bạn đang xem chính sách chứ không phải vật lý.

Ba phép so sánh, mỗi phép một biến số

Mỗi lần chạy chỉ đổi một thứ, nếu không bạn chẳng học được gì. Tải cùng tệp đó qua đường web thông thường, rồi qua một công cụ truyền dùng cổng khác, từ một máy chủ có dung lượng tương đương và vào cùng giờ. Giữ nguyên máy khách, vì một laptop di chuyển giữa các mạng sẽ thêm một biến số bạn không kiểm soát được.

curl -o /dev/null -w '%{speed_download}' https://files.example/big.iso
scp [email protected]:/exports/big.iso /dev/null

Dùng một tệp đã nén sẵn, chẳng hạn ảnh đĩa, để việc nén khi truyền không thể giải thích sự khác biệt. Sau đó, nếu bạn kiểm soát máy chủ, hãy chuyển trình lắng nghe của nó sang cổng mà bạn nghi bị giới hạn, cập nhật hồ sơ máy khách và lặp lại. Nếu đường hầm giờ tụt xuống tốc độ bị giới hạn, giới hạn đi theo cổng chứ không theo đường hầm, và câu hỏi được giải quyết. Chạy mỗi phép so sánh hai lần và giữ các con số của vùng phẳng, không phải các đỉnh.

Ghi cả giờ nữa, vì bộ định hình có thể dựa trên thời gian và một bài kiểm tra buổi tối có thể không khớp với bài kiểm tra buổi sáng. Hai lần chạy cùng giờ đáng giá hơn mười lần rải rác trong ngày.

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

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 không bị giới hạn. Nó mô tả một lần truyền trên một đường trong một giờ. Các giới hạn có thể theo phiên, theo thuê bao hoặc theo thời gian, và nhà mạng có thể thay đổi mà không thông báo.

Nó cũng không cho thấy đường trực tiếp bị lỗi. Một đường bị giới hạn hoạt động đúng như thiết kế, nó chỉ bị giới hạn bởi chính sách.

Sự phân biệt đó quan trọng khi bạn viết báo cáo. Một sự cố cần phiếu sửa chữa, còn một chính sách cần câu hỏi về hợp đồng hoặc quyết định đi vòng qua nó. Gọi một giới hạn là sự cố tạo ra cuộc trò chuyện với hỗ trợ bắt đầu từ tiền đề sai. Gọi nó là chính sách cho phép bạn hỏi một câu cụ thể có câu trả lời cụ thể.

Biến phát hiện thành một yêu cầu hỗ trợ

Dùng các con số và bỏ kết luận đi. Một yêu cầu nói rằng các bản truyền lớn qua cổng 80 giữ ở khoảng một nửa tốc độ mong đợi trong những giờ này, kèm các con số của vùng phẳng, là khả thi. Một yêu cầu nói rằng VPN nhanh hơn thì không, vì nó được đọc như một khẳng định về đường hầm chứ không phải quan sát về đường truyền. Đính kèm cả hai lần chạy và dấu thời gian của chúng, rồi để nhà mạng mô tả chính sách.

Đừng đẩy mọi ứng dụng vào đường hầm chỉ để đuổi theo con số đó.

Đường hầm vẫn khiến bạn tốn thêm một chặng, mã hóa và một bộ kiểu hỏng mới, trong khi cổng bị giới hạn vẫn bị giới hạn cho mọi thứ khác dùng nó. Khi các bản truyền lớn phải hoàn tất một cách đáng tin cậy, hãy tự ghi lại cổng nào mang giới hạn. Chuyển trình lắng nghe sang cổng 80 cũng đụng với bất kỳ máy chủ web nào đã gắn vào đó, và điều đó tạo ra một sự cố mới thay vì một bản sửa.