Tải lên qua VPN chậm hơn tải xuống? Xác định bạn đang chạm giới hạn nào

Hầu hết đường truyền truy cập là không đối xứng, nên một đường hầm thường tải lên chậm hơn tải xuống, và đó là câu trả lời mong đợi chứ không phải lỗi. Câu hỏi thú vị là liệu tải lên của bạn bị giới hạn bởi đường truyền, bởi thứ khác đang dùng nó, hay bởi một luồng bị đứng thay vì chạy đều. Ba thứ đó tạo ra cùng một phàn nàn và cần công việc khác nhau.

Ba giới hạn trông giống nhau từ thanh tiến trình

Dung lượng là giới hạn đầu tiên, và đó là thuộc tính của sản phẩm truy cập chứ không phải của đường hầm. Đường lên vài megabit là bình thường với cáp quang gia đình và nhiều gói di động, và chi phí mã hóa nhỏ so với khoảng cách đó. Đóng gói cũng thêm byte cho mỗi gói, làm giảm thông lượng hữu ích ở cả hai chiều chứ không chỉ một chiều, nên nó không thể tự mình giải thích một sự bất đối xứng lớn.

Tranh chấp là giới hạn thứ hai. Đồng bộ đám mây, thư viện ảnh và tác nhân cập nhật tải lên trong khi máy trông rảnh, và thiết bị thứ hai trên cùng đường truyền cũng làm vậy. Hàng đợi là giới hạn thứ ba: một đường lên bão hòa đẩy lưu lượng tương tác ra sau dữ liệu lớn, nên cuộc gọi bị ngắt trong khi chính quá trình truyền báo cáo tiến độ khỏe mạnh.

Đo một chiều một lần

Dùng cùng thiết bị, cùng hồ sơ và cùng đích, và không bao giờ chạy cả hai chiều cùng lúc trừ khi tranh chấp chính là thứ bạn muốn quan sát. Tạm dừng các bản truyền tùy chọn của bạn trước lần chạy đầu tiên. Hai lần chạy với một cờ ở giữa giải quyết phần lớn.

iperf3 gửi từ máy khách theo mặc định, nên lần chạy thường đo đường lên của bạn; -R đảo chiều và đo tải xuống. Chạy chúng cách nhau vài phút và ghi lại cả hai con số thay vì lấy trung bình:

iperf3 -c speed.example.net -t 30 -P 4
iperf3 -c speed.example.net -t 30 -P 4 -R

Nếu con số tải lên là một phần nhỏ của con số tải xuống và giữ ổn định giữa các lần chạy, hình dạng khớp với một đường truy cập không đối xứng và đường hầm không phải là câu chuyện. Nếu tải lên dao động giữa các lần chạy hoặc sụp sau mười giây, hãy đọc tiếp.

Quyết định dựa trên nơi tải lên thay đổi

Thay đổi một biến mỗi lần và xem chiều nào di chuyển. Một điểm cuối VPN thứ hai tải lên tốt hơn chỉ ra điểm cuối đó hoặc tuyến đến nó. Cùng một tải lên chậm từ thiết bị thứ hai trên cùng đường truyền chỉ ra đường truyền. Một thiết bị khác trên đường truyền khác cũng chậm chỉ ra chính sách vào của đích, thứ bạn không thể sửa cục bộ.

Ghi lại byte mỗi giây và thời gian trôi qua cho cùng khối lượng công việc, không phải một điểm số tốc độ. Ứng dụng sao lưu và bài kiểm tra tốc độ dùng đích và mức đồng thời khác nhau, nên so sánh các con số của chúng không trả lời gì. Nếu các yêu cầu nhỏ ổn và chỉ các bản truyền lớn bò, giới hạn có lẽ không phải băng thông.

Với việc dùng hàng ngày, giới hạn một bản tải lên nền hoặc lên lịch nó ngoài giờ họp thường giúp nhiều hơn mọi cài đặt đường hầm. Đánh giá thay đổi đó theo khối lượng công việc kết hợp: một bản sao lưu kết thúc muộn hơn nhưng không còn phá cuộc gọi thường là sự đánh đổi tốt hơn.

Khi đứng yên thắng sự chậm

Một bản truyền đóng băng ở một điểm lặp lại rồi tiếp tục hành xử như vấn đề MTU của đường đi chứ không phải giới hạn tốc độ. Đường hầm giảm tải trọng hữu ích mỗi gói, và thiết bị bỏ thông điệp ICMP sinh ra khiến bên gửi phải đoán. Kiểu đó xứng đáng có bài kiểm tra riêng, vì cách sửa khác với chỉnh tốc độ. Một con số thấp ổn định chỉ ra dung lượng, trong khi một đợt bùng nổ rồi im lặng chỉ ra tải trọng mà đường đi không thể mang.

Kiểm tra đường đi bằng tải trọng không được phân mảnh, rồi so sánh MTU của giao diện đường hầm với giá trị đi qua:

ping -M do -s 1400 -c 3 203.0.113.10
ip link show dev tun0 | grep -o "mtu [0-9]*"

Nếu đầu dò lớn biến mất trong khi đầu dò nhỏ thành công, hãy siết TCP MSS trên đường hầm thay vì hạ MTU giao diện cho mọi giao thức. Tình trạng đứng kéo dài sau điểm đó thuộc về lưu trữ hoặc nhịp của ứng dụng nhận, không thuộc về đường mạng.

Cần thay đổi gì và để yên gì

Thay đổi những gì bạn kiểm soát: lịch truyền nền, lựa chọn điểm cuối và MSS cho một đường bị đứng. Giữ mỗi thay đổi có thể đảo ngược và giới hạn trong một khối lượng công việc. Để yên những thứ mà phép đo nói là ổn, kể cả tốc độ tải xuống đã khớp với đường truyền.

Ghi lại các con số trước và sau cùng với hồ sơ, điểm cuối và thời điểm trong ngày, vì vấn đề tải lên di chuyển theo điểm cuối là câu hỏi định tuyến, còn vấn đề di chuyển theo thiết bị là cục bộ. Chính bản ghi đó biến một phàn nàn mơ hồ thành quyết định, và nó chỉ tốn hai lần chạy cùng một lệnh.