วิธีทดสอบความเร็ว VPN ให้ตัวเลขมีความหมาย
ตรึงเซิร์ฟเวอร์ทดสอบ ให้ชั้นล่างอยู่นิ่ง และอ่านความหน่วงแยกจากปริมาณงาน สิ่งที่อุโมงค์เปลี่ยนคือเส้นทางก่อนจะวัดอะไรทั้งสิ้น
การทดสอบความเร็วนั้นไม่เคยวัด VPN เลย มันวัดเส้นทางหนึ่ง และการเปิดอุโมงค์จะแทนที่ส่วนหนึ่งของเส้นทางนั้นก่อนที่ไบต์แรกจะขยับ นี่คือเหตุผลที่แล็ปท็อปเครื่องหนึ่งแสดงตัวเลขที่ดีกับไซต์หนึ่งและแย่กับอีกไซต์หนึ่ง ทั้งที่ไม่มีอะไรเปลี่ยนไปทั้งสองฝั่ง จงอ่านผลลัพธ์เป็นหลักฐานเกี่ยวกับเส้นทาง ไม่ใช่คะแนนของผลิตภัณฑ์
สามสิ่งตัดสินว่าการเปรียบเทียบมีค่าหรือไม่ คือ ทั้งสองรอบวิ่งไปถึงเป้าหมายเดียวกันหรือเปล่า เครือข่ายการเข้าถึงยังอยู่นิ่งหรือเปล่า และคุณบันทึกความหน่วงควบคู่กับปริมาตรหรือเปล่า
สิ่งที่อุโมงค์เขียนใหม่ก่อนไบต์แรก
ไคลเอนต์ห่อทุกแพ็กเก็ตด้วยเฮดเดอร์อีกชั้นหนึ่ง เพย์โหลดที่ใช้ได้ต่อแพ็กเก็ตจึงลดลง ต้นทุนนี้เกิดต่อแพ็กเก็ต ไม่ใช่ต่อการถ่ายโอน ซึ่งหมายความว่าไฟล์ใหญ่ต้องใช้แพ็กเก็ตมากกว่าไฟล์เดียวกันที่ส่งโดยไม่มีอุโมงค์ ภาระส่วนเกินแบบนี้ปรากฏเป็นจำนวนแพ็กเก็ต ไม่ใช่เป็นการตั้งค่าที่มองเห็นได้
ผลตามมาสองข้อ การทดสอบที่สร้างจากบล็อกใหญ่จะรู้สึกถึงต้นทุนต่อแพ็กเก็ต ส่วนการทดสอบจากคำขอเล็ก ๆ จำนวนมากจะรู้สึกถึงการไปกลับแทน และถ้าการค้นหา MTU ของเส้นทางถูกบล็อกที่ใดที่หนึ่งระหว่างทาง อุโมงค์จะลงเอยที่ขนาดแพ็กเก็ตที่เล็กลง และอัตราส่งข้อมูลจะตกด้วยเหตุผลที่ไม่เกี่ยวอะไรกับอัลกอริทึมเข้ารหัสเลย
คุณดูเพดานได้โดยตรง บนลินุกซ์ให้ขอเพย์โหลดที่ใหญ่ที่สุดที่ผ่านได้โดยไม่แตกแฟรกเมนต์ แล้วทำซ้ำขณะเปิดอุโมงค์:
ping -M do -s 1472 -c 3 203.0.113.10
ถ้าล้มเหลว ให้ลดลงไปที่ 1,400 แล้วลองอีกครั้ง อุโมงค์ที่รับได้เพียง 1,380 ไบต์กำลังบอกคุณว่ามีอะไรบางอย่างบีบเพิ่มลงไปอีกตามเส้นทาง และการปรับแต่งใด ๆ ที่ไคลเอนต์ก็ยกขึ้นไม่ได้
ทำไมเซิร์ฟเวอร์ทดสอบถึงย้ายเมื่อเปิดอุโมงค์
เครื่องมือส่วนใหญ่เลือกเซิร์ฟเวอร์ใกล้เคียงจากที่อยู่สาธารณะที่มันเห็น เมื่อเปิดอุโมงค์ ที่อยู่นั้นเป็นของโหนดทางออก เครื่องมือจึงอาจเลือกโฮสต์ในเมืองหรือประเทศอื่น คุณกำลังเปรียบเทียบปลายทางสองแห่ง และช่องว่างระหว่างทั้งสองรวมระยะทางจากทางออกถึงโฮสต์ทดสอบด้วย
ตรึงเซิร์ฟเวอร์ด้วยชื่อหรือ ID ก่อนรอบแรก และคงไว้ในทุกรอบถัดไป ถ้าเครื่องมือไม่ยอมตรึงไว้ ให้เลือกเป้าหมายที่คุณควบคุมเองและขับมันเอง: iperf3 -c test.example.net -R -t 20 ตรึงปลายทางไว้และให้ตัวเลขที่คุณเทียบกับเมื่อวานได้
เปลี่ยนตัวแปรเดียว และชั้นล่างไม่ใช่ตัวเดียว
ไร้สายคือการเปลี่ยนแปลงที่ซ่อนอยู่ตามปกติ ความแรงสัญญาณเปลี่ยนเมื่อแล็ปท็อปเคลื่อนที่ และความหนาแน่นของช่องสัญญาณเปลี่ยนเมื่อเพื่อนบ้านเริ่มโทร ดังนั้นสองรอบที่ห่างกันสิบนาทีบน Wi-Fi จึงไม่ใช่การทำซ้ำของการทดสอบเดียวกัน สาย LAN หรือตำแหน่งคงที่ที่จดระดับสัญญาณไว้ ช่วยขจัดเสียงรบกวนส่วนใหญ่ออกไป การจดระดับสัญญาณตอนเริ่มและจบแต่ละรอบมักพอจะบอกได้ว่าสองรอบนั้นอยู่ด้วยกันหรือไม่
ภาระของอุปกรณ์ก็อยู่ในตะกร้าเดียวกัน ไคลเอนต์ที่เข้ารหัสบนคอร์เดียวจะชนเพดานของตัวเองก่อนลิงก์มาก และการซิงก์เบื้องหลังจะชนเร็วกว่านั้น ดู CPU ระหว่างรอบและจดว่ามีอะไรเปิดอยู่อีก การตั้งค่าพลังงานก็กัดได้ตรงนี้ เพราะแล็ปท็อปที่ใช้แบตเตอรี่อาจจำกัดโปรเซสเซอร์ก่อนที่ลิงก์จะใกล้เต็มที่
| Measurement | What it answers | What it misses |
|---|---|---|
| Download | Bulk capacity along the path | Any question about responsiveness |
| Upload | Capacity from client to exit | Download health |
| RTT to a fixed target | Distance plus queueing | Whether capacity is available |
| Jitter or loss | Stability under load | How much the link can carry |
ให้ชั้นล่างอยู่นิ่งแทนที่จะเฉลี่ยข้ามมัน สามรอบที่ตรงกันบอกได้มากกว่าสิบรอบที่ทำในห้องต่างกัน
ความหน่วง การสูญหาย และ ICMP ตอบคำถามคนละแบบ
Ping ส่งโพรบเล็ก ๆ ไปยังที่อยู่คงที่ และหลายเครือข่ายตอบ ICMP ด้วยลำดับความสำคัญต่ำหรือเพิกเฉยไปเลย คำตอบที่หายไปอธิบายโพรบ ไม่ใช่แพ็กเก็ตของแอปพลิเคชัน เวลาไปกลับที่เพิ่มขึ้นภายใต้ภาระมักหมายถึงคิวกำลังเต็ม ไม่ใช่เส้นทางยาวขึ้น
ถ้าอยากรู้ว่าอุโมงค์เพิ่มความหน่วงหรือไม่ ให้เทียบเป้าหมายหนึ่งกับและไม่มีอุโมงค์ หรือเทียบทางออกสองทางที่เข้าถึงได้จากเครือข่ายการเข้าถึงเดียวกัน รันโพรบซ้ำหลายครั้งแล้วดูการกระจาย เพราะค่าเฉลี่ยซ่อนความแปรปรวนที่ทำให้การโทรใช้งานไม่ได้ไว้พอดี
กลับไปที่งานที่รู้สึกช้า
ตัวชี้วัดที่ดีขึ้นขณะที่การโทรยังสะดุด ได้ตอบคำถามอื่นไปแล้ว ให้รันงานที่เริ่มการสอบสวนซ้ำ ไม่ว่าจะเป็นการประชุม การแชร์ไฟล์ หรือเซสชันเดสก์ท็อประยะไกล หากตัวเลขดีขึ้นแต่ยังงานยังแย่ คอขวดอยู่ที่จุดที่การทดสอบไปไม่ถึง เช่นเซิร์ฟเวอร์หลังอุโมงค์หรืออัปลิงก์ฝั่งคุณ
บันทึกทุกรอบพร้อมอุปกรณ์ เครือข่ายการเข้าถึง ปลายทาง โปรโตคอล เป้าหมาย และเวลา รอบที่ไม่เคยเชื่อมต่อเลยเป็นผลลัพธ์เรื่องการเข้าถึง ไม่ใช่อัตราส่งข้อมูลศูนย์ จึงควรเก็บไว้ใต้ป้ายนั้นแทนที่จะลบทิ้ง
รายการสั้น ๆ ก่อนการเปรียบเทียบครั้งถัดไป
ตรึงเป้าหมายและจดว่าทำไมจึงเลือกมัน บันทึกขนาดแพ็กเก็ตที่เส้นทางอนุญาตไว้ เพื่อให้การตกในภายหลังมีคำอธิบาย คงเครือข่ายการเข้าถึงให้เหมือนเดิม จดภาระ CPU และทำสามรอบก่อนจะเชื่อความแตกต่าง
จากนั้นเปลี่ยนเพียงอย่างเดียวและทำซ้ำ การเปรียบเทียบที่คุณอธิบายได้ย่อมดีกว่าอันที่ตัวเลขมากกว่า