ทำไมคะแนน Wi-Fi ของเราเตอร์จึงไม่ทำนายอัตราการส่งข้อมูลของ VPN
อัตรา Wi-Fi ที่โฆษณาและอัตรา VPN ที่วัดได้อธิบายชั้นที่ต่างกัน ทำตามการตรวจสอบตามลำดับนี้ก่อนซื้อเราเตอร์ที่เร็วกว่า
เราเตอร์ที่มีป้าย Wi-Fi 3,000 Mbps ยังส่งข้อมูลที่เข้ารหัสได้ด้วยความเร็วเพียงเศษเสี้ยวของตัวเลขนั้น และตัวเลขทั้งสองก็ไม่ได้หลอกลวง คะแนนวิทยุอธิบายการมอดูเลตที่ดีที่สุดของลิงก์ไร้สายที่ชิปเซ็ตรองรับ ส่วนตัวเลข VPN อธิบายว่าอุปกรณ์เดียวสามารถดันแพ็กเก็ตที่เข้ารหัสผ่านซีพียูของเราเตอร์และออกจากวงจรเข้าถึงของคุณได้เร็วแค่ไหน สิ่งเหล่านี้เป็นชั้นที่ต่างกัน ขนาดแพ็กเก็ตที่ต่างกัน และวิธีการวัดที่ต่างกัน มองตัวเลขบนกล่องเป็นเพดานที่ไม่มีใครไปถึง ไม่ใช่การพยากรณ์ความเร็วอุโมงค์ของคุณ
ขั้นตอนที่ 1: ทำแผนที่สี่ชั้นที่จำกัดตัวเลขนั้น
เกือบทุกข้อร้องเรียนเรื่องเราเตอร์ช้าที่ผมเคยจัดการจะตกอยู่ในหนึ่งในสี่ชั้น คือ ลิงก์ไร้สาย อัตราการเข้าถึง WAN เส้นทางการส่งต่อ (NAT ไฟร์วอลล์ การติดตามการเชื่อมต่อ) หรือเส้นทางเข้ารหัสของ VPN สิ่งเหล่านี้ซ้อนกัน และชั้นที่ช้าที่สุดเป็นตัวกำหนดผลลัพธ์ อัตรา Wi-Fi ที่โฆษณาพูดถึงเฉพาะชั้นแรก และพูดถึงอย่างใจกว้าง
ตัวเลขนั้นมาจากจำนวนสตรีมคูณความกว้างช่องสัญญาณคูณการมอดูเลตสูงสุดที่ชิปเซ็ตสามารถเจรจาได้ วิทยุ 2x2 บน 5 GHz ที่ 80 MHz ด้วย 1024-QAM ถูกโฆษณาใกล้ 1,200 Mbps แต่ Wi-Fi เป็นสื่อร่วมแบบครึ่งสองทิศทาง ไคลเอนต์ผลัดกัน การส่งซ้ำและทราฟฟิกจัดการเผาเวลาอากาศ และ TCP เพิ่มภาระของตัวเอง ไคลเอนต์ที่เจรจาอัตราสูงสุดในสภาพเหมาะมักวัดได้ต่ำกว่าครึ่งมาก และน้อยลงอีกเมื่อเครือข่ายข้างเคียงปรากฏขึ้น
| 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 |
ถ้าตารางชี้ไปที่วิทยุ ให้แก้ฝั่งไร้สายก่อน คือ แบนด์ ความกว้างช่องสัญญาณ ระยะทาง ถ้าชี้ไปใต้วิทยุ สี่ขั้นตอนถัดไปคือสิ่งสำคัญ และการซื้อเสาอากาศไม่ว่าจะมากแค่ไหนก็ไม่เปลี่ยน
ขั้นตอนที่ 2: เก็บเส้นฐานแบบมีสายก่อนแตะวิทยุ
ต่อแล็ปท็อปกับ Ethernet และวัดเส้นทางที่ไม่มีอุโมงค์ก่อน เพราะจะทำให้คุณได้ตัวส่วน รันเครื่องมือวัดอัตราส่งข้อมูลที่ปลายอีกด้าน บน VPS หรือเซิร์ฟเวอร์บ้านที่สิ้นสุด VPN และชี้ไคลเอนต์ไปที่ที่อยู่สาธารณะของมัน เพื่อให้ทราฟฟิกผ่านเราเตอร์และวงจรเข้าถึงของคุณ
# 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
ตัวเลขสองตัวจากบล็อกนั้นตอบคำถามที่ต่างกัน สตรีมเดียวแสดงเพดานต่อการเชื่อมต่อ ซึ่งรวมพฤติกรรมหน้าต่าง TCP และการปรับรูปร่างต่อโฟลว์บนเส้นทาง สี่สตรีมแสดงว่าลิงก์มีความจุที่คุณไม่ได้ใช้หรือไม่ เพราะโฟลว์ขนานสามารถเติมท่อที่โฟลว์เดียวเติมไม่ได้
รักษาความซื่อตรง: โฮสต์เดิม เวลาของวันและระยะเวลาเดิม และไม่มีสิ่งอื่นสตรีมในบ้าน การถ่ายโอนก้อนใหญ่สามสิบวินาทีคือหน่วยที่ถูกต้องตรงนี้ และ RFC 6349 กรอบการทดสอบอัตราส่งข้อมูล TCP ก็สร้างบนเหตุผลเดียวกัน เพราะการระเบิดสั้นและการร้องขอเล็กทำให้ลิงก์ดูดีเกินจริง เขียนเส้นฐานไว้ก่อนเปลี่ยนแปลงอะไร
ขั้นตอนที่ 3: รันการทดสอบเดิมผ่านอุโมงค์
ตอนนี้ทำซ้ำกับที่อยู่อุโมงค์ของปลายทาง ด้วยไคลเอนต์ ระยะเวลา และจำนวนสตรีมเดิม โดยอุโมงค์เปิดอยู่และไม่มีทราฟฟิกอื่น อัตราส่วนระหว่างผลลัพธ์ทั้งสองบอกคุณว่าการเข้ารหัสและการห่อหุ้มมีต้นทุนเท่าไรบนฮาร์ดแวร์นั้น และตัวเลขสัมบูรณ์บอกว่าพอสำหรับงานหรือไม่
ดูตัวนับขณะการถ่ายโอนทำงาน บน WireGuard wg show รายงานไบต์ที่ถ่ายโอนต่อเพียร์ บน OpenVPN ไฟล์สถานะที่เขียนเป็นช่วงเวลาจะให้ภาพเดียวกัน
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
ถ้าตัวเลขอุโมงค์ใกล้เส้นฐานแบบมีสาย VPN ไม่ใช่คอขวดของคุณ และคุณเลิกโทษมันได้ ถ้าเป็นเพียงเศษเสี้ยวของเส้นฐาน การสูญเสียเกิดขึ้นภายในเส้นทางเข้ารหัสและการส่งต่อของเราเตอร์ และขั้นตอนถัดไปบอกว่าส่วนไหน
ข้อควรระวังหนึ่งข้อ: เมื่อ IP ขาออกเปลี่ยน บริการทดสอบความเร็วบางรายจะเลือกเซิร์ฟเวอร์วัดอื่นอย่างเงียบ ๆ คุณจึงเปรียบเทียบปลายทางสองแห่งที่ต่างกัน ปักหมุดที่อยู่เซิร์ฟเวอร์ด้วยตัวเอง
ขั้นตอนที่ 4: อ่านซีพียูเป็นเส้นทาง ไม่ใช่ค่าเฉลี่ย
เราเตอร์ที่แสดงซีพียูรวม 30 เปอร์เซ็นต์ยังอิ่มตัวได้ งานของอุโมงค์หนึ่งมักตกบนคอร์เดียว คิวอินเทอร์รัปต์เดียว หรือเธรดเคอร์เนลเดียว ค่าเฉลี่ยจึงซ่อนเพดาน ดูตัวเลขต่อคอร์และ softirq แทนมาตรวัดบนแดชบอร์ด
mpstat -P ALL 1
top -H -p $(pgrep -f 'openvpn')
grep -o -m1 aes /proc/cpuinfoสามสิ่งสำคัญในผลลัพธ์นั้น คอร์เดียวถูกปักใกล้ 100 เปอร์เซ็นต์ในขณะที่ตัวอื่นว่าง บ่งชี้ขีดจำกัดต่อการเชื่อมต่อ %soft หนักหรือ ksoftirqd ที่ยุ่งบนซีพียูหนึ่งตัวบ่งชี้การประมวลผลแพ็กเก็ตฝั่งรับที่ไม่กระจายไปตามคิว และการไม่มีแฟล็ก aes หมายความว่าซีพียูไม่มีคำสั่ง AES การเข้ารหัสสมมาตรจึงทำงานในซอฟต์แวร์และมีต้นทุนต่อแพ็กเก็ตสูงกว่ามาก
การนำไปใช้ก็สำคัญ อินสแตนซ์ OpenVPN แบบผู้ใช้ทั่วไปประมวลผลแพ็กเก็ตของอุโมงค์หนึ่งส่วนใหญ่ในที่เดียว กล่องหลายคอร์ที่เร็วจึงอาจทำงานเหมือนคอร์เดียวสำหรับอุโมงค์นั้น WireGuard ในเคอร์เนลกระจายงานไปยังซีพียู และการออฟโหลดช่องทางข้อมูลของ OpenVPN ก็ย้ายการจัดการแพ็กเก็ตเข้าเคอร์เนลด้วย แต่เฉพาะบนบิลด์และแพลตฟอร์มที่รองรับ การอ้างว่าเร่งด้วยฮาร์ดแวร์บนหน้าตลาดไม่ใช่หลักฐานว่าเส้นทางโค้ดที่คุณรันใช้มัน
ขั้นตอนที่ 5: ตัดสินใจว่าจะเปลี่ยนอะไร ตามลำดับนั้น
ไล่รายการนี้ลงมาและหยุดที่บรรทัดแรกที่เป็นจริง เพราะการเปลี่ยนสิ่งใดใต้มันจะไม่ขยับตัวเลข
1. อัตราส่งข้อมูลแบบมีสายตรงนั้นต่ำกว่าที่คุณจ่ายไป คุยกับผู้ให้บริการ เพราะอุโมงค์สร้างความจุที่วงจรเข้าถึงไม่ให้ไม่ได้ 2. แบบมีสายตรงปกติดีแต่มีคอร์หนึ่งถูกปักระหว่างทดสอบอุโมงค์ เส้นทางเข้ารหัสของเราเตอร์คือขีดจำกัด 3. ซีพียูว่างแต่อุโมงค์ช้า ตรวจ MTU และการแตกแฟรกเมนต์ แล้วดูความจุของปลายทางไกลเอง 4. มีเพียงไคลเอนต์ Wi-Fi ที่ช้า เปลี่ยนแบนด์หรือความกว้างช่องสัญญาณ และยอมรับว่าอัตราที่โฆษณาไม่เคยเป็นตัวเลข VPN
เมื่อเราเตอร์เป็นขีดจำกัดจริง ทางเลือกที่ซื่อตรงคืออุปกรณ์ที่มีคำสั่ง AES และเส้นทางส่งต่อที่เร็วกว่า อุโมงค์ฝั่งเคอร์เนลอย่าง WireGuard แทนแบบผู้ใช้ หรือย้ายไคลเอนต์ไปบนอุปกรณ์เองเพื่อให้เราเตอร์เลิกเข้ารหัส การปิดการเข้ารหัสที่พิสูจน์ตัวตนเพื่อชนะการทดสอบมาตรฐานไม่ใช่หนึ่งในนั้น เพราะแลกคุณสมบัติด้านความปลอดภัยกับตัวเลขที่ก็ยังไม่ตรงกับกล่องอยู่ดี
ก่อนซื้ออะไร ให้รันขั้นตอนที่ 2 และ 3 บนอุปกรณ์ใหม่ด้วยเซิร์ฟเวอร์และระยะเวลาเดิม แล้วเปรียบเทียบอัตราส่วนไม่ใช่ยอดสูงสุด