Vì sao xếp hạng Wi-Fi của router không dự đoán được thông lượng VPN
Tốc độ Wi-Fi được quảng cáo và tốc độ VPN đo được mô tả những lớp khác nhau. Hãy làm theo bước kiểm tra có thứ tự này trước khi mua router nhanh hơn.
Một router mang nhãn Wi-Fi 3,000 Mbps vẫn có thể chuyển lưu lượng đã mã hóa với tốc độ chỉ bằng một phần nhỏ con số đó, và cả hai con số đều không gian dối. Xếp hạng vô tuyến mô tả cách điều chế tốt nhất mà chipset hỗ trợ cho liên kết không dây; con số VPN mô tả tốc độ một thiết bị có thể đẩy gói tin đã mã hóa qua CPU của router và ra khỏi đường truy cập của bạn. Đó là những lớp khác nhau, kích thước gói tin khác nhau và phương pháp đo khác nhau. Hãy coi con số trên hộp là mức trần không ai chạm tới, không phải dự báo tốc độ đường hầm của bạn.
Bước 1: Vẽ bản đồ bốn lớp giới hạn con số
Gần như mọi phàn nàn về router chậm mà tôi từng xử lý đều rơi vào một trong bốn tầng: liên kết không dây, tốc độ truy cập WAN, đường chuyển tiếp (NAT, tường lửa, theo dõi kết nối) hoặc đường mã hóa của VPN. Chúng chồng lên nhau, và tầng chậm nhất quyết định kết quả. Tốc độ Wi-Fi được quảng cáo chỉ nói về tầng đầu tiên, và nói về nó một cách hào phóng.
Con số đó đến từ số luồng nhân với độ rộng kênh nhân với mức điều chế cao nhất mà chipset có thể thương lượng. Một radio 2x2 ở 5 GHz với 80 MHz và 1024-QAM được quảng cáo gần 1,200 Mbps, nhưng Wi-Fi là môi trường chia sẻ bán song công: các máy khách thay phiên nhau, truyền lại và lưu lượng quản lý đốt thời gian không gian, còn TCP thêm phần chi phí của riêng nó. Một máy khách thương lượng được tốc độ cao nhất trong điều kiện lý tưởng thường đo được thấp hơn nửa rất nhiều, và còn thấp hơn khi các mạng lân cận xuất hiện.
| Symptom | Tier to suspect first |
|---|---|
| Wired clients are slow too | WAN access or forwarding path |
| Only Wi-Fi clients are slow | Radio, airtime, or channel width |
| One stream is slow, four parallel streams add up | Per-connection CPU path, not the link |
| Every stream is slow and one core sits at 100% | Crypto path |
| Fast to LAN hosts, slow to the internet | WAN, not the tunnel |
Nếu bảng chỉ vào radio, hãy sửa phía không dây trước: băng tần, độ rộng kênh, khoảng cách. Nếu nó chỉ xuống dưới radio, bốn bước tiếp theo mới quan trọng, và không lượng mua ăng-ten nào thay đổi được điều đó.
Bước 2: Lấy đường cơ sở có dây trước khi chạm vào radio
Cắm laptop vào Ethernet và đo đường đi không có đường hầm trước, vì điều đó cho bạn một mẫu số. Chạy công cụ thông lượng ở phía bên kia, trên VPS hoặc máy chủ tại nhà nơi kết thúc VPN, và trỏ máy khách tới địa chỉ công khai của nó để lưu lượng đi qua router và đường truy cập của bạn.
# on the far host (VPN endpoint)
iperf3 -s
# wired client, direct to the endpoint's public address
iperf3 -c 203.0.113.10 -t 30
# same client, four parallel streams
iperf3 -c 203.0.113.10 -t 30 -P 4
Hai con số từ khối đó trả lời hai câu hỏi khác nhau. Một luồng cho thấy mức trần trên mỗi kết nối, bao gồm hành vi cửa sổ TCP và mọi định hình theo luồng trên đường đi. Bốn luồng cho thấy liên kết có dung lượng mà bạn chưa dùng hay không, vì các luồng song song có thể lấp đầy một đường ống mà một luồng không lấp được.
Hãy giữ cho trung thực: cùng máy chủ, thời điểm trong ngày và thời lượng, không có gì khác đang phát trong nhà. Truyền khối ba mươi giây là đơn vị đúng ở đây, và RFC 6349, khung thử nghiệm thông lượng TCP, được xây dựng trên chính lập luận đó, vì các đợt ngắn và yêu cầu nhỏ làm liên kết trông đẹp hơn thực tế. Ghi lại đường cơ sở trước khi bạn thay đổi bất cứ điều gì.
Bước 3: Chạy lại bài thử đó qua đường hầm
Bây giờ lặp lại với địa chỉ đường hầm của điểm cuối, cùng máy khách, thời lượng và số luồng, đường hầm đang mở và không có lưu lượng khác. Tỷ lệ giữa hai kết quả cho biết mã hóa và đóng gói tốn bao nhiêu trên phần cứng đó; con số tuyệt đối cho biết liệu có đủ cho công việc hay không.
Theo dõi các bộ đếm trong khi truyền. Trên WireGuard, wg show báo cáo số byte đã truyền cho mỗi đối tác; trên OpenVPN, tệp trạng thái được ghi theo chu kỳ cho bạn cùng một góc nhìn.
watch -n 1 'wg show wg0 transfer'
# OpenVPN: add --status /run/openvpn/server.status 10 to the server config
tail -f /run/openvpn/server.status
Nếu con số đường hầm gần với đường cơ sở có dây, VPN không phải nút cổ chai của bạn và bạn có thể ngừng đổ lỗi cho nó. Nếu nó chỉ là một phần nhỏ của đường cơ sở, mất mát xảy ra bên trong đường mã hóa và chuyển tiếp của router, và bước tiếp theo cho biết phần nào.
Một lưu ý: ngay khi IP ra thay đổi, một số dịch vụ thử tốc độ lặng lẽ chọn máy chủ đo khác, nên cuối cùng bạn so sánh hai điểm đến khác nhau. Hãy tự ghim địa chỉ máy chủ.
Bước 4: Đọc CPU như một đường đi, không phải số trung bình
Một router hiển thị 30 phần trăm CPU tổng vẫn có thể đã bão hòa: công việc của một đường hầm thường rơi vào một lõi, một hàng đợi ngắt hoặc một luồng hạt nhân, nên số trung bình che mất mức trần. Hãy xem số liệu theo từng lõi và softirq thay vì đồng hồ trên bảng điều khiển.
mpstat -P ALL 1
top -H -p $(pgrep -f 'openvpn')
grep -o -m1 aes /proc/cpuinfo
Ba điều quan trọng trong kết quả đó. Một lõi bị ghim gần 100 phần trăm trong khi những lõi khác rảnh rỗi cho thấy giới hạn trên mỗi kết nối. Một %soft nặng hoặc một ksoftirqd bận trên một CPU cho thấy xử lý gói ở phía nhận không trải đều trên các hàng đợi. Và thiếu cờ aes nghĩa là CPU không có lệnh AES, nên mã hóa đối xứng chạy bằng phần mềm và tốn nhiều hơn cho mỗi gói.
Cách triển khai cũng quan trọng. Một phiên bản OpenVPN truyền thống trong không gian người dùng xử lý gói của một đường hầm phần lớn ở một chỗ, nên một hộp đa lõi nhanh có thể hành xử như đơn lõi với đường hầm đó. WireGuard trong hạt nhân phân tán công việc trên các CPU, và việc giảm tải kênh dữ liệu của OpenVPN cũng đưa xử lý gói vào hạt nhân, nhưng chỉ trên các bản dựng và nền tảng hỗ trợ. Một tuyên bố về tăng tốc phần cứng trên trang tiếp thị không phải bằng chứng rằng đường mã bạn đang chạy dùng nó.
Bước 5: Quyết định thay đổi điều gì, theo đúng thứ tự đó
Đi xuống danh sách này và dừng ở dòng đầu tiên đúng, vì thay đổi bất cứ thứ gì bên dưới sẽ không làm con số nhúc nhích.
1. Thông lượng trực tiếp có dây thấp hơn mức bạn trả tiền: hãy nói chuyện với nhà cung cấp, vì đường hầm không thể tạo ra dung lượng mà đường truy cập không cung cấp. 2. Có dây trực tiếp thì ổn nhưng một lõi bị ghim trong bài thử đường hầm: đường mã hóa của router là giới hạn. 3. CPU rảnh nhưng đường hầm chậm: kiểm tra MTU và phân mảnh, rồi dung lượng của chính điểm cuối từ xa. 4. Chỉ máy khách Wi-Fi chậm: đổi băng tần hoặc độ rộng kênh, và chấp nhận rằng tốc độ được quảng cáo chưa bao giờ là con số VPN.
Khi router thực sự là giới hạn, các lựa chọn trung thực là một thiết bị có lệnh AES và đường chuyển tiếp nhanh hơn, một đường hầm phía hạt nhân như WireGuard thay vì một đường hầm trong không gian người dùng, hoặc chuyển máy khách vào chính thiết bị để router ngừng mã hóa. Tắt mã hóa có xác thực để thắng một bài đo chuẩn không nằm trong số đó; nó đánh đổi một thuộc tính bảo mật lấy một con số vẫn sẽ không khớp với hộp.
Trước khi mua bất cứ thứ gì, hãy chạy lại bước 2 và 3 trên thiết bị mới với cùng máy chủ và thời lượng, rồi so sánh tỷ lệ chứ không phải đỉnh.