ทดสอบ WireGuard ต้องวัดค่าอะไรบ้าง

มีคนบอกว่า "WireGuard เร็ว" อีกคนโพสต์ภาพหน้าจอที่ตัวเลขสูงลิ่ว พอคุณลองเองกลับได้ผลคนละเรื่อง การเปรียบเทียบความเร็วของโปรโตคอลมักล้มเหลวด้วยเหตุผลง่ายๆ คือวัดสิ่งเดียวในสภาพที่ไม่มีใครควบคุม ตัวเลขเดียวจากการรันครั้งเดียวในวันเดียวคือเรื่องเล่า ไม่ใช่การทดสอบ

บทความนี้อธิบายว่าควรวัดอะไรเมื่อทดสอบอุโมงค์ WireGuard ออกแบบการทดสอบที่ทำซ้ำได้อย่างไร อ่านผลอย่างไร และความผิดพลาดแบบไหนทำให้ตัวเลขหลอกตา ใช้ได้กับอุโมงค์ใดก็ตามที่คุณมีสิทธิ์ทดสอบ ไม่ได้อ้างว่าบริการใดใช้ WireGuard หรือโปรโตคอลใดโดยเฉพาะ และไม่สัญญาความเร็วใดๆ ถ้าอยากรู้พื้นฐานก่อนว่าโปรโตคอลคืออะไร อ่าน โปรโตคอล VPN คืออะไร

ทำไมตัวเลขเดียวไม่ใช่การทดสอบความเร็ว

ตัวเลขดาวน์โหลดบอกอัตราสูงสุดที่ข้อมูลเคลื่อนที่ในไม่กี่วินาที ไม่ได้บอกว่าการโทรจะนิ่งไหม หน้าเว็บจะเปิดทันใจไหม หรืออุโมงค์จะรอดเมื่อเปลี่ยนเครือข่ายหรือไม่ เหมือนตัดสินรถด้วยความเร็วสูงสุดอย่างเดียว สิ่งที่คุณรู้สึกในการใช้งานจริงต่างออกไป

• หน้าเว็บเริ่มโหลดเร็วแค่ไหน
• เสียงและวิดีโอนิ่งไหม
• เกมตอบสนองดีไหม
• ดาวน์โหลดไฟล์ใหญ่รักษาจังหวะได้ไหม
• โทรศัพท์หรือแล็ปท็อปร้อนและแบตหมดเร็วหรือเปล่า

แต่ละข้อตรงกับการวัดต่างกัน การทดสอบที่ดีเลือกค่าที่ตรงกับสิ่งที่คุณสนใจ เก็บในแบบที่ทำซ้ำได้ และเทียบกับค่าฐาน

หกค่าที่ต้องวัด

1. ปริมาณข้อมูล ดาวน์โหลดและอัปโหลด

ข้อมูลเคลื่อนที่ต่อวินาทีเท่าไร เป็นเมกะบิตต่อวินาที วัดทั้งสองทิศ อัปโหลดมักต่ำกว่าและสำคัญกับการโทรและการแชร์ไฟล์ รายงานมัธยฐานของหลายรอบ ไม่ใช่ค่าที่ดีที่สุด

2. ความหน่วงขณะว่าง

เวลาไป-กลับของแพ็กเก็ตเล็กเมื่อไม่มีอะไรใช้การเชื่อมต่ออยู่ วัดด้วย ping ถูกกำหนดโดยระยะทางและเส้นทาง บทความอธิบาย latency ของ Cloudflare บอกว่าทำไมสิ่งนี้แยกจากปริมาณข้อมูล ถ้าอยากรู้ว่าอุโมงค์มีผลอย่างไร อ่าน VPN ลด ping ได้ไหม

3. ความหน่วงขณะมีโหลด

วัด ping เหมือนเดิมแต่ในขณะที่ดาวน์โหลดหรืออัปโหลดไฟล์ใหญ่อยู่ ถ้าตัวเลขกระโดดจาก 30 ms เป็น 400 ms แปลว่าการเชื่อมต่อมีความหน่วงจากการต่อคิว เรียกกันว่า bufferbloat ซึ่งมักเป็นสาเหตุที่การโทรกระตุกบนสายที่ได้คะแนนเทสต์ความเร็วดี หลายคนลืมวัดอันนี้

4. Jitter

ความแปรผันของความหน่วงจากแพ็กเก็ตหนึ่งไปอีกแพ็กเก็ต การเชื่อมต่อสองเส้นอาจเฉลี่ย 40 ms เท่ากัน แต่เส้นที่แกว่ง 20 ถึง 80 ms จะแย่กว่ามากสำหรับการโทรและเกม เครื่องมือ ping ส่วนใหญ่รายงานช่วงหรือส่วนเบี่ยงเบนมาตรฐานที่ใช้เป็นตัวชี้วัด jitter ได้

5. การสูญหายของแพ็กเก็ต

เปอร์เซ็นต์ของแพ็กเก็ตที่ไม่เคยไปถึง แม้เพียงหนึ่งสองเปอร์เซ็นต์ก็กระทบทราฟฟิกเรียลไทม์และลดปริมาณข้อมูลของการดาวน์โหลดทั่วไป รัน ping ให้นานขึ้น เช่นหนึ่งร้อยแพ็กเก็ต เพื่อดูค่านี้

6. การใช้โปรเซสเซอร์

อุโมงค์ใช้โปรเซสเซอร์ของอุปกรณ์เท่าไรขณะเคลื่อนย้ายข้อมูล ช่วยบอกว่าอุปกรณ์หรือเครือข่ายเป็นตัวจำกัด อุโมงค์ที่แตะเพดานโปรเซสเซอร์ที่ความเร็วปานกลางจะไม่เร็วขึ้นไม่ว่าเครือข่ายจะดีแค่ไหน การใช้สูงยังกินแบตเตอรี่

เสริม เวลาในการเชื่อมต่อและเสถียรภาพระยะยาว

เวลาสร้างเซสชันสำคัญถ้าคุณเปลี่ยนเครือข่ายบ่อย เสถียรภาพตลอดหนึ่งชั่วโมงขึ้นไปบอกว่าอุโมงค์รอดจากการพักเครื่อง การโรมมิ่ง และที่อยู่ที่เปลี่ยนไหม เซสชันของ WireGuard ออกแบบให้เบา และการจับมือสั้นเป็นส่วนหนึ่งของดีไซน์ในเอกสารทางเทคนิค แต่คุณตรวจสอบได้ว่าการตั้งค่าของคุณเองทำงานอย่างไร

สร้างการทดสอบที่ทำซ้ำได้

การทดสอบทำซ้ำได้เมื่อคนอื่นหรือตัวคุณสัปดาห์หน้าทำตามขั้นตอนเดิมแล้วได้ตัวเลขเทียบกันได้

1. เลือกอุปกรณ์เดียวและเครือข่ายเดียว รอบแรกควรใช้สาย
2. จดบริบท วันที่ เวลา อุปกรณ์ ระบบปฏิบัติการ เวอร์ชันแอป ชนิดเครือข่าย ตำแหน่งเซิร์ฟเวอร์
3. ทำค่าฐานโดยไม่มีอุโมงค์ เทสต์ความเร็วสามครั้ง ping หนึ่งร้อยแพ็กเก็ต และ ping ขณะดาวน์โหลด จดมัธยฐาน
4. เชื่อมต่ออุโมงค์ และรอสิบวินาทีให้นิ่ง
5. ทำชุดทดสอบเดิม ตอนเปิดอุโมงค์
6. ดูโปรเซสเซอร์ ระหว่างทดสอบปริมาณข้อมูล
7. ทำซ้ำในอีกช่วงเวลาของวัน ควรมีหนึ่งช่วงคนเยอะและหนึ่งช่วงเงียบ
8. เปลี่ยนตัวแปรเดียว ในรอบต่อไป เช่น ตำแหน่งเซิร์ฟเวอร์ เครือข่าย หรืออุปกรณ์

เก็บบันทึกเป็นตารางง่ายๆ การจดไม่กี่นาทีดีกว่าการเดาทีหลังเป็นชั่วโมง ส่วนเรื่องรั่วไหลและ kill switch ซึ่งไม่เกี่ยวกับความเร็ว ดู วิธีทดสอบ VPN

เครื่องมือที่ใช้ได้

• เทสต์ความเร็วบนเบราว์เซอร์ ให้ปริมาณข้อมูลและความหน่วง มักเปิดหลายการเชื่อมต่อ จึงเอื้อกับสายเร็วและซ่อนพฤติกรรมของ Stream เดียว
• ping ให้ความหน่วง jitter และการสูญหาย ใช้จำนวนอย่างน้อยหนึ่งร้อยเพื่อประเมินการสูญหาย
• การทดสอบความหน่วงขณะมีโหลด บางเว็บเทสต์ความเร็วมีให้ ถ้าที่ของคุณไม่มี ให้รัน ping ขณะดาวน์โหลดไฟล์ใหญ่
• iperf3 วัดปริมาณข้อมูลดิบระหว่างสองเครื่องที่คุณควบคุม เช่นแล็ปท็อปกับเซิร์ฟเวอร์ที่บ้านหรือเครื่องเช่า เลี่ยงอิทธิพลของอินเทอร์เน็ตสาธารณะต่อปลายทาง และทดสอบได้ทั้ง Stream เดียวหรือหลาย Stream
• ตัวตรวจสอบกิจกรรมของระบบ แสดงการใช้โปรเซสเซอร์ หน่วยความจำ และปริมาณข้อมูลเครือข่าย
• นาฬิกาจับเวลากับงานจริง จับเวลาดาวน์โหลด 500 MB การโหลดหน้าเว็บ หรืออัปโหลดไฟล์ใหญ่ งานจริงบอกสิ่งที่คุณรู้สึก

ตัวอย่างที่คำนวณ

ตัวอย่างสมมติเพื่อแสดงวิธีอ่านผลชุดหนึ่งเท่านั้น ผู้ใช้เปรียบเทียบอุโมงค์ที่อยู่ใกล้กับการเชื่อมต่อปกติบนแล็ปท็อปที่ต่อสาย

ค่าที่วัด	ไม่มีอุโมงค์	อุโมงค์ เซิร์ฟเวอร์ใกล้	อุโมงค์ เซิร์ฟเวอร์ไกล
ดาวน์โหลด (มัธยฐาน 3 ครั้ง)	220 Mbps	190 Mbps	105 Mbps
อัปโหลด (มัธยฐาน 3 ครั้ง)	45 Mbps	41 Mbps	28 Mbps
ความหน่วงขณะว่าง	12 ms	19 ms	180 ms
ความหน่วงขณะมีโหลด	38 ms	52 ms	330 ms
Jitter (ช่วง ping)	1 ถึง 3 ms	2 ถึง 5 ms	8 ถึง 40 ms
แพ็กเก็ตสูญหาย (100 ping)	0 เปอร์เซ็นต์	0 เปอร์เซ็นต์	2 เปอร์เซ็นต์
การใช้โปรเซสเซอร์ขณะทดสอบ	ไม่เกี่ยวข้อง	22 เปอร์เซ็นต์	18 เปอร์เซ็นต์

อ่านตาราง

• เซิร์ฟเวอร์ใกล้ ได้ราว 86 เปอร์เซ็นต์ของความเร็วดาวน์โหลดปกติ ความหน่วงเพิ่ม 7 ms ไม่มีการสูญหาย ใช้โปรเซสเซอร์เบา ผลดี ผู้ใช้ไม่รู้สึกเวลาท่องเว็บ และการโทรปกติ
• เซิร์ฟเวอร์ไกล ดาวน์โหลดเหลือราวครึ่ง ความหน่วงสูงขึ้นสิบห้าเท่า และเริ่มมี jitter กับการสูญหาย โปรเซสเซอร์ใช้น้อยลง แปลว่าอุปกรณ์ไม่ใช่ปัญหา เส้นทางต่างหาก นี่คืออุโมงค์ที่ดีในที่ผิด ไม่ใช่อุโมงค์ที่แย่
• การใช้โปรเซสเซอร์ ทั้งสองอุโมงค์ยังห่างจากขีดจำกัดของอุปกรณ์ ถ้าอันใดอันหนึ่งอยู่ที่ 95 เปอร์เซ็นต์ขณะที่ความเร็วแบน อุปกรณ์คือคอขวด

การตัดสินใจที่ตามมาเป็นเรื่องปฏิบัติ ใช้เซิร์ฟเวอร์ใกล้สำหรับการโทรและท่องเว็บ และไม่สรุปเรื่องโปรโตคอลจากผลของเซิร์ฟเวอร์ไกล

การเปรียบเทียบที่ยุติธรรมระหว่างการตั้งค่า

ถ้าเปรียบเทียบ WireGuard กับแนวทางอื่น ให้ทุกอย่างอื่นเท่ากัน

• อุปกรณ์เดียวกัน เครือข่ายเดียวกัน ชั่วโมงเดียวกัน สลับรอบ การตั้งค่า A, B, A, B
• พื้นที่เซิร์ฟเวอร์เดียวกัน และถ้าเป็นไปได้เครื่องเดียวกัน ถ้าการเปรียบเทียบเกี่ยวกับโปรโตคอลไม่ใช่เส้นทาง
• การตั้งค่าอื่นเหมือนกัน DNS ขนาดแพ็กเก็ต โหมดแบตเตอรี่
• จำนวนตัวอย่างเท่ากัน อย่างน้อยสามรอบต่อแบบ
• ดูมากกว่าปริมาณข้อมูล โปรโตคอลที่ช้ากว่าเล็กน้อยในปริมาณข้อมูลแต่นิ่งกว่าใน jitter อาจรู้สึกดีกว่า

สำหรับภาพรวมว่าโปรโตคอลที่รู้จักมากที่สุดสองตัวต่างกันที่ดีไซน์อย่างไร ดู WireGuard กับ OpenVPN ขอให้จำว่าประสิทธิภาพของโปรโตคอลใดก็ขึ้นกับการพัฒนาซอฟต์แวร์ ฮาร์ดแวร์ และเซิร์ฟเวอร์ ข้อสรุปทั่วไปจากการทดสอบหนึ่งจึงแทบไม่ใช้ข้ามไปยังอีกการตั้งค่าได้

กับดักที่ทำให้ผลหลอก

• ทดสอบค่าฐานกับอุโมงค์ในเวลาที่ต่างกัน
• ทดสอบบน Wi-Fi ในกรณีหนึ่งและผ่านสายในอีกกรณี
• เลือกผลที่ดีที่สุดของอุโมงค์กับผลที่แย่ที่สุดของค่าฐาน
• ลืมทราฟฟิกเบื้องหลัง การสำรองข้อมูล อัปเดตเกม ไคลเอนต์ซิงก์
• ใช้เซิร์ฟเวอร์เทสต์ในศูนย์ข้อมูลเดียวกัน กับจุดออกของอุโมงค์ ซึ่งทำให้ผลดูดีเกินจริง
• ทดสอบ Stream เดียวด้วยเครื่องมือที่คาดหวังหลาย Stream หรือกลับกัน
• ละเลย CPU แล้วสงสัยว่าทำไมเครือข่ายที่เร็วกว่าให้เลขเท่าเดิม
• ถือว่ารอบแรกเป็นตัวแทน รอบแรกมักมีผลของ slow-start
• เทียบกับภาพหน้าจอในอินเทอร์เน็ต ฮาร์ดแวร์ เครือข่าย และเซิร์ฟเวอร์ต่างกันทำให้ตัวเลขนั้นไม่มีความหมายสำหรับคุณ

แก้ปัญหาเมื่อผลน่าผิดหวัง

ถ้าอุโมงค์ดูแย่กว่าค่าฐานมาก ให้ไล่ตามรายการนี้

1. เปลี่ยนไปตำแหน่งใกล้แล้วทดสอบใหม่
2. เชื่อมต่อใหม่และทดสอบหลังสิบวินาที
3. เปลี่ยนจาก Wi-Fi เป็นสาย หรือนั่งข้างเราเตอร์
4. ดูการใช้โปรเซสเซอร์ ถ้าใกล้ขีดจำกัด ทดสอบบนอุปกรณ์ที่แรงกว่าหรือปิดแอปอื่น
5. ตรวจการสูญหายด้วย ping ที่นานขึ้น การสูญหายเกินหนึ่งเปอร์เซ็นต์ควรเปลี่ยนเครือข่ายหรือตำแหน่ง
6. ตรวจความหน่วงขณะมีโหลด การกระโดดมากชี้ไปที่การต่อคิวบนสาย ไม่ใช่อุโมงค์
7. อัปเดตแอปและซอฟต์แวร์ระบบ
8. อ่านเช็กลิสต์กว้างกว่าใน ทำไม VPN ช้า และคำอธิบายทั่วไปใน ทำไมความเร็วเปลี่ยนเมื่อใช้ VPN

ตีความผลโดยไม่อ่านเกินจริง

การทดสอบวัดเส้นทางเดียวในเวลาเดียว ข้อสรุปที่ยุติธรรมจึงต้องถ่อมตัว "บนแล็ปท็อปเครื่องนี้ เครือข่ายนี้ เซิร์ฟเวอร์นี้ ในช่วงเย็น อุโมงค์รักษาดาวน์โหลดไว้ราว 85 เปอร์เซ็นต์ของความเร็วปกติและเพิ่ม 7 ms" ประโยคนี้มีประโยชน์ ส่วน "WireGuard เร็ว 85 เปอร์เซ็นต์ของไม่ใช้ VPN" ไม่ใช่

และจำไว้ว่าตัวเลขที่ดีที่สุดไม่ใช่ประสบการณ์ที่ดีที่สุดเสมอไป ถ้าสองตัวเลือกได้ปริมาณข้อมูลเท่ากัน ให้เลือกตัวที่ jitter และการสูญหายต่ำกว่า ถ้าตัวเลือกหนึ่งช้ากว่าเล็กน้อยแต่คงการเชื่อมต่อหลังพักเครื่องและเปลี่ยนเครือข่าย ความเสถียรนั้นมีค่ากว่าเมกะบิตที่ขาดไป

สรุป

เพื่อทดสอบอุโมงค์ WireGuard ให้ดี ให้วัดปริมาณข้อมูลสองทิศ ความหน่วงขณะว่าง ความหน่วงขณะมีโหลด jitter การสูญหายของแพ็กเก็ต และการใช้โปรเซสเซอร์ บันทึกค่าฐานโดยไม่มีอุโมงค์ รันแต่ละการทดสอบหลายครั้งในมากกว่าหนึ่งช่วงเวลา เปลี่ยนตัวแปรทีละอย่าง และอ่านมัธยฐาน ใช้ผลตัดสินว่าจะปรับอะไร ซึ่งมักเป็นตำแหน่งเซิร์ฟเวอร์หรือเครือข่าย และระวังอย่าเปลี่ยนการรันครั้งเดียวเป็นคำตัดสินของโปรโตคอล

ถ้าอยากฝึกทดสอบเหล่านี้ด้วยแพ็กเกจระยะสั้น หน้าราคา แสดงตัวเลือก และแอป VPNclient ฟรีอยู่ที่ หน้าดาวน์โหลด