ทำไมการทดสอบความเร็ว VPN สองครั้งบนอุโมงค์เดียวกันจึงไม่ตรงกัน
ทางออกใหม่เปลี่ยนเซิร์ฟเวอร์ทดสอบ และการเริ่มช้าทำให้ผลเปลี่ยน ตรึงปลายทาง ปรับจำนวนสตรีมให้เท่ากัน และแยกต้นทุนซีพียูออกจากความจุของลิงก์
สองรอบ หนึ่งอุโมงค์ และตัวเลขต่างกันถึงสามเท่า อุโมงค์ไม่ได้เปลี่ยนระหว่างสองรอบ สิ่งที่เปลี่ยนคือการวัด ไซต์ทดสอบที่เลือกเซิร์ฟเวอร์ตามตำแหน่งที่คุณดูเหมือนอยู่ จำนวนสตรีมที่กำหนดว่าการเริ่มช้าหนึ่งครั้งหรือหกครั้งเป็นตัวเติมท่อ และระยะเวลาที่สั้นพอจะจบก่อนที่เส้นทางจะถูกใช้อย่างเหมาะสม การทดสอบความเร็วจึงไม่ได้ผิด แต่พวกมัน ตอบคำถามที่แคบกว่าคำถามที่คนถามมัน
ที่อยู่ทางออกใหม่เปลี่ยนปลายทางการทดสอบ
ไซต์ทดสอบส่วนใหญ่เลือกเซิร์ฟเวอร์วัดผลอัตโนมัติ และเลือกโดยดูว่าการเชื่อมต่อของคุณดูเหมือนมาจากที่ใด เมื่อเปิดอุโมงค์ ประเทศที่คุณดูเหมือนอยู่ก็เปลี่ยน เซิร์ฟเวอร์ที่เลือกจึงเปลี่ยน และการเปรียบเทียบก็ครอบคลุมสองเส้นทางที่ต่างกันไปยังสองโฮสต์ที่ต่างกัน
ผลลัพธ์ไม่ใช่การวัด VPN เลย มันคือการวัดเส้นทางของคุณไปยังเซิร์ฟเวอร์ที่คุณไม่ได้เลือก และความต่างระหว่างสองรอบอาจถูกกำหนดโดยการเชื่อมต่อระหว่างเครือข่ายของเซิร์ฟเวอร์นั้น มากกว่าสิ่งที่อุโมงค์ทำ
ตรึงปลายทางก่อนจะเปลี่ยนอย่างอื่น ทุกเครื่องมือที่เชื่อถือได้ให้คุณเลือกเซิร์ฟเวอร์อย่างชัดเจน และเมื่อไม่ให้ หน้าผลลัพธ์มักระบุตัวที่ใช้ ซึ่งพอจะสังเกตได้ว่าสองรอบเทียบกันไม่ได้ ยืนยันสิ่งที่ไซต์เห็นก่อนจะเชื่อในการเลือกของมัน
curl -sS https://ipinfo.io/json | grep -E '"ip"|"org"|"country"'ถ้าประเทศเปลี่ยนระหว่างสองรอบ ทุกอย่างที่การทดสอบเลือกหลังจากนั้นก็เปลี่ยนด้วย จดทางออกที่สังเกตได้ข้างผลแต่ละรายการ แล้วความสับสนก็หายไปเกือบหมด
การเริ่มช้าจบลงหลังการทดสอบสั้นส่วนใหญ่จบแล้ว
การเชื่อมต่อ TCP ไม่ได้เริ่มที่ความเร็วของลิงก์ มันเริ่มด้วยหน้าต่างควบคุมความคับคั่งเล็ก ๆ เพิ่มเป็นสองเท่าประมาณทุกรอบไปกลับ และกว่าจะถึงความจุของเส้นทางก็ต่อเมื่อผ่านไปหลายรอบ การทดสอบสิบนวินาทีบนเส้นทางที่มีความหน่วงสูงอาจใช้เวลาส่วนใหญ่ของมันไปกับการไต่ระดับนั้น
นี่คือเหตุผลที่อุโมงค์ที่มีความหน่วงสูงกว่าทำคะแนนได้แย่กว่าที่ควรในการทดสอบสั้น และเป็นเหตุผลที่การรันนานกว่ามักรายงานตัวเลขสูงกว่าโดยไม่มีการเปลี่ยนการตั้งค่าใด ๆ กรอบการวัดปริมาณส่งข้อมูล RFC 6349 จัดการเรื่องนี้อย่างชัดเจน จึงเป็นการวัดที่จริงจังจึงใช้เวลานานพอจะถึงสภาวะคงที่ การรันห้าวินาทีบนเส้นทางดาวเทียมวัดตัวเร่ง ไม่ใช่วัดถนน
ดูที่เฟสของการเชื่อมต่อแทนที่จะเชื่อตัวเลขเดียว Curl รายงานแต่ละขั้นแยกกัน คุณจึงเห็นว่าเวลาไปที่การจับมือ การไต่ระดับ หรือการถ่ายโอน
curl -sS -o /dev/null -w 'dns=%{time_namelookup} tcp=%{time_connect} tls=%{time_appconnect} total=%{time_total} bytes/s=%{speed_download}\n' \
https://mirror.example.net/testfile.binรันมันสองครั้งติดกันไปยังปลายทางเดิม ถ้าการรันครั้งที่สองเร็วขึ้นมาก แสดงว่าคุณกำลังวัดการไต่ระดับ ไม่ใช่เส้นทาง และการเปรียบเทียบใดที่ใช้แค่ครั้งแรกก็น่าสงสัย
สตรีมเดียวกับหกสตรีมวัดสิ่งที่ต่างกัน
สตรีม TCP เดียวถูกจำกัดด้วยหน้าต่างที่มันรักษาไว้ระหว่างทาง ซึ่งประมาณเวลารอบไปกลับคูณด้วยอัตรา บนเส้นทางยาว ผลคูณนั้นเกินสิ่งที่สตรีมเดียวจะใช้ การดาวน์โหลดครั้งเดียวจึงรายงานต่ำกว่าความจุที่มีอยู่ หกสตรีมขนานกันเติมช่องว่างนั้นและให้ตัวเลขที่ใหญ่กว่า
iperf3 -c speed.example.net -t 20
iperf3 -c speed.example.net -t 20 -P 6
mtr -rwc 50 speed.example.netทั้งสองตัวเลขเป็นความจริง ตัวเลขสตรีมเดียวบอกว่าการดาวน์โหลดหนึ่งครั้งจะทำอะไร ซึ่งโดยปกติแท็บเบราว์เซอร์ได้รับ ตัวเลขแบบขนานบอกว่าเส้นทางรับได้ทั้งหมดเท่าไร ซึ่งทอร์เรนต์หรือการดาวน์โหลดหลายส่วนใช้ได้ การอ้างตัวหนึ่งราวกับเป็นอีกตัวคือวิธีที่อุโมงค์ที่แข็งแรงถูกเปลี่ยนโดยไม่มีเหตุผล
การเทียบผลแบบขนานกับผลสตรีมเดียวเป็นวิธีที่พบบ่อยที่สุดที่คนสรุปว่า VPN ลดความเร็วลงครึ่งหนึ่ง ปรับวิธีให้ตรงกันแล้วจึงเปรียบเทียบ ร่องรอยในคำสั่งที่สามเพิ่มบริบทที่ขาดไป เส้นทางที่มีความแปรปรวนสูงจะให้ผลไม่สม่ำเสมอในทั้งสองแบบ และจำนวนสตรีมก็แก้ไม่ได้
การเข้ารหัสกินเวลาซีพียู การห่อหุ้มกินไบต์
กลไกสองอย่างทำงานบนทุกแพ็กเก็ตไม่ว่าลิงก์จะเร็วแค่ไหน การเข้ารหัสใช้ซีพียูต่อไบต์ และการห่อหุ้มเพิ่มไบต์ส่วนหัวที่ลิงก์ยังต้องพาไป ทั้งสองแสดงออกเป็นเพดาน และมีอาการต่างกัน
เพดานซีพียูปรากฏเป็นที่ราบ ปริมาณส่งข้อมูลหยุดเพิ่มไม่ว่าคุณจะเพิ่มสตรีมเท่าไร และซีพียูของเครื่องทำงานหนักในขณะที่ลิงก์ว่าง บนเราเตอร์เล็กหรือโทรศัพท์ นี่มักเป็นขีดจำกัดจริง และเป็นเหตุผลที่สายเร็วก็ยังให้อุโมงค์แบบพอประมาณได้
ต้นทุนไบต์เล็กกว่าแต่คงที่ ส่วนหัวที่เพิ่มขึ้นหมายถึงเพย์โหลดต่อแพ็กเก็ตน้อยลง และบนเส้นทางที่มีหน่วยส่งสูงสุดคงที่ มันยังอาจทำให้เกิดการแบ่งส่วนหรือหลุมดำซึ่งแสดงเป็นอาการค้างในการถ่ายโอนขนาดใหญ่ ไม่ใช่ค่าเฉลี่ยที่ช้า
| Observation | Likely mechanism | What to measure |
|---|---|---|
| Throughput flat as streams increase | CPU per packet on one core | Per-core utilisation during the test |
| Fast small transfers, stalled large ones | MTU and fragmentation | Payload size at which it breaks |
| Good average, unusable calls | Queueing delay behind a full buffer | Latency under load |
สามอย่างนี้มักถูกสับสนเพราะผู้ใช้อธิบายทั้งหมดว่า VPN ช้า มีเพียงอย่างแรกที่ตอบสนองต่อเครื่องที่ใหญ่ขึ้น มีเพียงอย่างที่สองที่ตอบสนองต่อ MTU ที่เล็กลง และมีเพียงอย่างที่สามที่ตอบสนองต่อการจัดการคิว
บันทึกวิธีการลงในระเบียน
ผลลัพธ์ที่ควรค่าแก่การเก็บระบุอุปกรณ์ เครือข่ายเข้าถึง ทางออก เซิร์ฟเวอร์วัดผล ทิศทาง จำนวนสตรีม และระยะเวลา หากไม่มีสิ่งเหล่านี้ ตัวเลขสองตัวก็เทียบกันไม่ได้ และตั๋วที่มีตัวเลขเดียวก็คืออารมณ์
เก็บการรันที่แย่ไว้ด้วย ชุดที่ทางออกหนึ่งทำให้เกิดอาการค้างทุกครั้งให้ข้อมูลมากกว่าค่าเฉลี่ย และอาการค้างคือสิ่งที่ค่าเฉลี่ยซ่อนไว้
แล้วทดสอบสิ่งที่คุณสนใจจริง ๆ ถ้าเป้าหมายคือการดาวน์โหลดขนาดใหญ่ ก็ดาวน์โหลดไฟล์ ถ้าเป้าหมายคือการโทร ให้วัดความหน่วงภายใต้ภาระแทนปริมาณส่งข้อมูลตอนว่าง เพราะอุโมงค์อาจทำคะแนนได้ดีในการทดสอบความเร็วแต่ก็ยังทำให้ทุกการประชุมฟังไม่ได้