Vì sao VPN có vẻ chậm khi tải lên: độ trễ hàng đợi

Một bản sao lưu bắt đầu tải lên, bộ đếm truyền tải trông khỏe mạnh, và cuộc gọi video trở nên hỗn loạn. Đường truyền không thiếu băng thông theo nghĩa mà con số đó gợi ý; các gói đang chờ trong một hàng đợi ở đâu đó và các gói tương tác nằm sau dữ liệu lớn. Đây là độ trễ hàng đợi, thường được gọi là bufferbloat. VPN có thể thêm hàng đợi của riêng nó, nhưng hiếm khi tự tạo ra vấn đề.

Băng thông và độ trễ là những phép đo khác nhau

Thông lượng trả lời bao nhiêu dữ liệu di chuyển mỗi giây, trong khi độ trễ trả lời một gói mất bao lâu để đi qua đường truyền. Một đường truyền bão hòa có thể giữ lượng tồn đọng lớn và vẫn báo thông lượng tốt, vì hàng đợi thoát ra với tốc độ đường dây khi đợt bùng phát kết thúc. Lưu lượng tương tác chịu thiệt hại trước, vì một cuộc gọi cần một gói vài mili giây một lần, không phải một tệp lớn cuối cùng. Vì vậy chỉ đo kết quả kiểm tra tốc độ sẽ che đi triệu chứng khiến bạn phải nhìn.

Cũng hãy chú ý đến hướng khi có tải. Một bộ đệm tải lên đầy có thể làm chậm mọi thứ khác trong khi dung lượng tải xuống đang rảnh.

Đo thời gian khứ hồi khi có tải

Lấy một đường cơ sở trên đường truyền yên tĩnh, sau đó lặp lại cùng phép đo trong khi một lần truyền được kiểm soát đang chạy. So sánh hai lần chạy thay vì các con số tuyệt đối.

ping -c 20 -i 0.2 203.0.113.5
dd if=/dev/zero bs=1M count=50 | ssh [email protected] "cat > /dev/null"

Lệnh đầu tiên lấy mẫu thời gian khứ hồi, và lệnh thứ hai tạo một lần tải lên liên tục mà không cần dịch vụ kiểm tra tốc độ. Một đường cơ sở phẳng, tiếp theo là một lần chạy có tải tăng thêm hàng trăm mili giây, chính là dấu hiệu cần tìm. Một số mạng hạ thấp ưu tiên ICMP, vì vậy hãy coi ping là manh mối và xác nhận bằng hiển thị độ trễ của chính ứng dụng. Giữ bài kiểm tra ngắn trên các đường truyền có hạn mức, vì độ tương phản lặp lại quan trọng hơn độ bão hòa dài.

Chuyển hàng đợi đến nơi có nút thắt

Quản lý hàng đợi chỉ giúp ích trên thiết bị thực sự giữ lượng tồn đọng. Kiểm tra giao diện đang làm gì trước khi thêm quy tắc.

tc -s qdisc show dev eth0
tc qdisc replace dev eth0 root fq_codel

Lệnh show báo cáo kỷ luật hiện tại cùng bộ đếm tồn đọng và loại bỏ, cho bạn biết giao diện này là nút thắt hay chỉ đang chuyển tiếp lưu lượng. Thay thế kỷ luật gốc bằng thuật toán hàng đợi công bằng cho các luồng ngắn lượt riêng thay vì một FIFO dùng chung với dữ liệu lớn. Áp dụng nó trên giao diện WAN của bộ định tuyến khi bộ định tuyến là nút thắt, không phải trên thiết bị đường hầm theo thói quen. Giữ cấu hình trước đó và kiểm tra lại cả khả năng phản hồi khi có tải và tốc độ truyền, vì tốc độ hàng loạt thấp hơn một chút là một trao đổi tốt cho các cuộc gọi dùng được.

Đường hầm thay đổi gì và che giấu gì

VPN thêm mã hóa và một chặng nữa, và nó cũng che giấu các luồng riêng lẻ khỏi thiết bị bên ngoài đường hầm. Điều này quan trọng khi một thiết bị thượng nguồn cung cấp ưu tiên theo ứng dụng, vì nó thấy các gói đã mã hóa thay vì các cuộc trò chuyện gốc. Một bộ định tuyến tự kết thúc đường hầm có góc nhìn và khối lượng công việc khác và có thể phân loại bên trong. Không cấu hình nào trong hai cấu hình loại bỏ hàng đợi ở đường truyền truy cập, nơi độ trễ thường tích tụ.

Nếu độ trễ không theo tải, hãy ngừng tinh chỉnh hàng đợi và nhìn nơi khác: điều kiện Wi-Fi, vấn đề kích thước gói hoặc một đường ra kém. Các cài đặt hàng đợi áp dụng mà không đo chỉ di chuyển điều bí ẩn.