วิธี Benchmark Ping และ Latency ของ VPN ให้ยุติธรรม

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

บทความนี้เสนอวิธี Benchmark Ping VPN ที่ทำซ้ำได้ นักศึกษา คนทำงานระยะไกล หรือคนเล่นเกมก็ทำได้ภายในไม่ถึงชั่วโมงด้วยเครื่องมือที่มีอยู่ในคอมพิวเตอร์แล้ว บทความนี้พูดถึงเฉพาะความหน่วง หากอยากทบทวนว่า latency คืออะไร อ่านได้ที่ VPN latency อธิบายง่าย ๆ และถ้าสงสัยว่า VPN ลด ping ได้จริงหรือไม่ ดู VPN ช่วยลด ping ได้ไหม ส่วนในบทนี้เราจะเน้น "วิธีวัด" เป็นหลัก

กำหนดให้ชัดว่ากำลังวัดอะไร

Latency คือเวลาที่แพ็กเก็ตเล็ก ๆ ใช้เดินทางไปยังปลายทางและกลับมา เรียกว่า round-trip time หรือ RTT มันไม่ใช่ความเร็วดาวน์โหลด เส้นทางที่ดาวน์โหลดได้เร็วมากก็ยังรู้สึกอืดได้ถ้าทุกคำขอต้องรอ 200 มิลลิวินาที หน้าอธิบาย latency ของ Cloudflare อธิบายแนวคิดพื้นฐานนี้ไว้ชัดเจน

เมื่อเปิด VPN คุณวัดตัวเลขได้สามแบบ และการปนกันคือต้นเหตุแรกของผลทดสอบที่ผิด

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

ผลต่างของสองแถวแรกคือ ค่าโอเวอร์เฮดของ VPN ซึ่งเป็นตัวเลขที่ควรรายงาน แถวที่สามช่วยอธิบายที่มา ถ้าช่วงแรกก็ใช้เวลา 150 มิลลิวินาทีแล้ว การตั้งค่าใด ๆ ในอุโมงค์ก็แก้ไม่ได้

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

เตรียมสนามทดสอบให้ยุติธรรม

การ benchmark จะยุติธรรมก็ต่อเมื่อระหว่างสองรอบมีสิ่งเดียวเท่านั้นที่เปลี่ยน ซึ่งก็คือสิ่งที่กำลังทดสอบ ให้เตรียมดังนี้

1. ใช้อุปกรณ์เครื่องเดียว ใช้โน้ตบุ๊กหรือโทรศัพท์เครื่องเดิมทุกรอบ ปิดแอปซิงก์คลาวด์ การอัปเดตระบบ โปรแกรมดาวน์โหลด และแท็บ Streaming เพราะสิ่งเหล่านี้กินแบนด์วิดท์ขาขึ้นและทำให้ latency พุ่ง
2. ใช้เครือข่ายเดียว และควรเป็นสายแลน Wi-Fi มีความหน่วงแบบสุ่มจากสัญญาณรบกวนและการเปลี่ยนแปลงของคลื่น สายแลนตัดตัวแปรนี้ออกไป ภายหลังคุณค่อยทดสอบซ้ำบน Wi-Fi ได้ แต่ห้ามเอาผลจากต่างเครือข่ายมาเทียบกัน
3. หนึ่งการทดสอบต่อหนึ่งเซิร์ฟเวอร์ VPN เลือกเซิร์ฟเวอร์ที่คุณใช้ตามปกติและจดชื่อตำแหน่งไว้ ถ้าต้องการเทียบสองตำแหน่ง ให้แยกเป็นสองการทดสอบ
4. การตั้งค่าคงที่ ใช้ค่าเริ่มต้นของแอป VPN ไม่เปลี่ยนชนิดการเชื่อมต่อกลางคัน ยกเว้นว่านั่นคือสิ่งที่คุณต้องการทดสอบ และต้องจดไว้ด้วย
5. ตารางบันทึกผล ใช้สเปรดชีตหรือไฟล์ข้อความธรรมดาก็ได้ มีคอลัมน์วันที่ เวลา เครือข่าย สถานะ VPN ปลายทาง จำนวนตัวอย่าง ค่าต่ำสุด มัธยฐาน เฉลี่ย เปอร์เซ็นไทล์ที่ 95 สูงสุด และ packet loss

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

เลือกปลายทางทดสอบที่มีความหมาย

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

• ที่อยู่โครงสร้างพื้นฐานสาธารณะที่อยู่ใกล้ เช่น DNS สาธารณะ ใช้ดูต้นทุนของ VPN โดยให้ระยะทางฝั่งปลายทางน้อยที่สุด
• เว็บที่คุณเปิดทุกวัน เช่น เว็บข่าว อีเมล หรือพอร์ทัลที่ทำงาน ใช้ชื่อโดเมน ไม่ใช่ตัวเลข IP ที่จดไว้ เพื่อให้ DNS เป็นส่วนหนึ่งของประสบการณ์จริงเมื่อทดสอบด้วยเบราว์เซอร์
• บริการที่คุณสนใจจริง ๆ เช่น เซิร์ฟเวอร์เกม บริการประชุม หรือ cloud region ที่ทีมใช้ เกมและเครื่องมือหลายตัวมีหน้าแสดง latency หรือที่อยู่สำหรับทดสอบ ใช้เป็นความเห็นที่สองได้
• ปลายทางไกลข้ามทวีป ใช้ดูว่าเส้นทางปกติกับเส้นทางผ่าน VPN แตกต่างกันหรือไม่เมื่อระยะทางไกล

ใช้ปลายทางชุดเดิมทุกรอบ หากปลายทางใดเลิกตอบ ping ให้เปลี่ยนทั้งในเงื่อนไขไม่มี VPN และมี VPN ไม่ใช่เปลี่ยนเฉพาะฝั่งเดียว

อีกข้อหนึ่งคือ ICMP echo หรือ ping ธรรมดา บางเครือข่ายปฏิบัติต่างจากทราฟฟิกเว็บ เมื่อต้องการความแม่นยำ ให้วัดระดับแอปพลิเคชันด้วย เช่น เวลารับไบต์แรกของหน้าเว็บเล็ก ๆ ผ่านเครื่องมือนักพัฒนาในเบราว์เซอร์หรือคำสั่ง fetch ที่แสดงเวลา บริการสมัยใหม่จำนวนมากใช้ QUIC บน UDP ตามที่ RFC 9000 อธิบายไว้ การวัดแบบ TCP จึงไม่ใช่สิ่งที่แอปเจอเสมอไป ให้มอง ping เป็นตัวชี้วัด และการวัดระดับแอปเป็นตัวยืนยัน

ขั้นตอนการวัดทีละขั้น

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

1. วอร์มอัป เปิดปลายทางในเบราว์เซอร์หนึ่งครั้ง เพื่อให้แคช DNS และเส้นทางพร้อม ผลรอบแรกที่ยัง "เย็น" ไม่เป็นตัวแทนที่ดี
2. วัดค่าตั้งต้นตอนปิด VPN รัน ping อย่างน้อย 100 ตัวอย่างต่อปลายทาง บน macOS หรือ Linux ใช้ ping -c 100 TARGET บน Windows ใช้ ping -n 100 TARGET บันทึกบรรทัดสรุปไว้
3. รัน traceroute หนึ่งครั้งต่อปลายทาง (traceroute บน macOS/Linux, tracert บน Windows) และเก็บผลลัพธ์ มันแสดงจุดผ่านต่าง ๆ และช่วยตรวจภายหลังว่าเส้นทางเปลี่ยนไปหรือไม่
4. เชื่อมต่อ VPN รอ 20 ถึง 30 วินาทีให้การเชื่อมต่อนิ่งและการแลกเปลี่ยนกุญแจเริ่มต้นเสร็จ
5. ทำซ้ำ ping และ traceroute ไปยังปลายทางเดิมด้วยจำนวนตัวอย่างเท่าเดิม
6. ตัดการเชื่อมต่อแล้ววัดค่าตั้งต้นอีกครั้ง ค่าตั้งต้นรอบสองบอกว่าเครือข่ายเองเปลี่ยนไประหว่างทดสอบหรือไม่ ถ้าสองค่าตั้งต้นต่างกันเกินประมาณ 10 ถึง 15 เปอร์เซ็นต์ แปลว่าการทดสอบไม่น่าเชื่อถือ ให้ทิ้งแล้วลองใหม่ภายหลัง
7. ทำทั้งชุดซ้ำสามรอบ เช่น เช้า บ่าย และเย็น หรือสามวันที่ต่างกัน

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

บันทึกมากกว่าค่าเฉลี่ย

ค่าเฉลี่ยซ่อนเรื่องราวจริงไว้ ให้บันทึกค่าต่อไปนี้ในแต่ละเงื่อนไข

• ต่ำสุด ใกล้เคียงขีดจำกัดทางกายภาพของเส้นทาง (ระยะทางและอุปกรณ์)
• มัธยฐาน ค่าที่ครึ่งหนึ่งของแพ็กเก็ตทำได้ดีกว่า เป็นค่า "ปกติ" ที่ซื่อสัตย์ที่สุด
• เฉลี่ย เทียบง่ายแต่ไวต่อค่าผิดปกติ
• เปอร์เซ็นไทล์ที่ 95 เส้นแบ่งของ 5 เปอร์เซ็นต์ที่ช้าที่สุด จับอาการกระตุกที่คุณรู้สึกตอนประชุมได้
• สูงสุด การพุ่งครั้งเดียว จดไว้ แต่อย่าสรุปจากมัน
• Jitter ความแปรปรวนของ latency ระหว่างแต่ละคำตอบ เครื่องมือ ping หลายตัวแสดงค่าเบี่ยงเบนมาตรฐาน (mdev) ใช้เป็นค่าประมาณ jitter ได้ ดูความหมายเชิงปฏิบัติใน VPN jitter
• Packet loss เปอร์เซ็นต์ของคำขอที่ไม่มีคำตอบ แม้แต่ 1 ถึง 2 เปอร์เซ็นต์ก็ทำให้การประชุมแย่กว่าการเพิ่ม 20 มิลลิวินาที อ่านต่อได้ที่ VPN packet loss

ตัวอย่างจะช่วยให้เห็นภาพ สมมติคนทำงานระยะไกลวัดบริการประชุมช่วงเย็นบนอินเทอร์เน็ตสายเคเบิล

เงื่อนไข	ต่ำสุด	มัธยฐาน	เฉลี่ย	P95	สูงสุด	Loss
ปิด VPN รอบ 1	18 ms	21 ms	23 ms	34 ms	71 ms	0%
เปิด VPN รอบ 1	41 ms	46 ms	49 ms	78 ms	140 ms	0%
ปิด VPN (ตั้งต้นรอบ 2)	18 ms	22 ms	23 ms	33 ms	65 ms	0%

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

อ่านผลโดยไม่หลอกตัวเอง

ตัวเลขดิบต้องมีการตีความ ใช้รายการตรวจสั้น ๆ นี้

เทียบมัธยฐานก่อน แล้วค่อยดู P95 ถ้ามัธยฐานต่างกันไม่กี่มิลลิวินาทีและช่วงหางทับซ้อนกัน ให้ถือว่าเสมอ ความต่างที่น้อยกว่าความแปรปรวนระหว่างรอบของคุณเองคือสัญญาณรบกวน

ดูแต่ละรอบ ไม่ใช่แค่ข้อมูลรวม ถ้ารอบแรกเพิ่ม 24 มิลลิวินาทีแต่รอบที่สามเพิ่ม 60 มิลลิวินาที สาเหตุน่าจะเป็นความคับคั่งในช่วงเวลานั้น ไม่ว่าจะฝั่งคุณหรือฝั่งเซิร์ฟเวอร์ ไม่ใช่การออกแบบของ VPN

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

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

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

ข้อผิดพลาดที่ทำให้ benchmark ใช้ไม่ได้

• ping สี่ครั้งแล้วสรุป ค่าเริ่มต้นของบางระบบคือสี่ครั้ง นั่นไม่ใช่ benchmark
• เทียบกันคนละช่วงเวลา ความคับคั่งช่วงเย็นมีจริง ควรวัดค่าตั้งต้นและค่าตอนเปิด VPN ห่างกันไม่กี่นาที
• ทดสอบบน Wi-Fi จากอีกห้อง ความแรงสัญญาณเปลี่ยนแปลงจะครอบงำทุกอย่าง
• ลืมว่า VPN เชื่อมต่อใหม่ ตรวจให้แน่ใจว่าแอปแสดงการเชื่อมต่อคงที่ตลอด การเชื่อมต่อใหม่เงียบ ๆ ทำให้เกิดค่าผิดปกติก้อนใหญ่
• เลือกปลายทางที่อยู่ใกล้เซิร์ฟเวอร์ VPN มาก จะเห็นโอเวอร์เฮดน้อยเกินจริง ให้ทดสอบที่ที่คุณใช้จริง
• สลับเซิร์ฟเวอร์ระหว่างรอบ สองเซิร์ฟเวอร์คือสองการทดลอง
• เอาตัวเลขโฆษณาของผู้ให้บริการมาเป็นผลของคุณ latency เป็นเรื่องเฉพาะเครือข่ายของแต่ละคน ตัวเลขของคนอื่นไม่ย้ายมาที่บ้านคุณ
• มองข้าม DNS ถ้าคำค้นหา DNS ผ่านรีโซลเวอร์ที่ช้า หน้าเว็บจะรู้สึกช้าแม้ ping ปกติ ให้วัดเวลา lookup ของ DNS แยกต่างหากเมื่อการท่องเว็บอืด

แก้ปัญหาเมื่อผลสูงกว่าที่คาด

ถ้าโอเวอร์เฮดมากกว่าที่คิด ให้ไล่ตามรายการนี้ตามลำดับ และทดสอบใหม่หลังแต่ละขั้น

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

หลังทำครบ ให้ถือว่าความต่างที่เหลือคือต้นทุนจริงของทางอ้อมในสถานการณ์ของคุณ

แม่แบบ benchmark ที่นำกลับมาใช้ซ้ำได้

คัดลอกแผนนี้ไปปรับใช้

• ประโยคเป้าหมาย หนึ่งบรรทัดระบุปลายทาง เครือข่าย และเวลา
• ปลายทาง สามถึงห้าแห่ง เหมือนกันทุกเงื่อนไข
• จำนวนตัวอย่าง 100 ต่อปลายทาง ต่อเงื่อนไข
• จำนวนรอบ สามรอบ ต่างเวลากัน
• ลำดับ ค่าตั้งต้น VPN ค่าตั้งต้น
• ตัวชี้วัด ต่ำสุด มัธยฐาน เฉลี่ย P95 สูงสุด ค่าเบี่ยงเบน และ loss
• กฎความถูกต้อง ค่าตั้งต้นสองรอบต้องต่างกันไม่เกิน 10 ถึง 15 เปอร์เซ็นต์
• ผลลัพธ์ โอเวอร์เฮดมัธยฐานและโอเวอร์เฮด P95 ต่อปลายทาง พร้อมคำอธิบายหนึ่งประโยค

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

สรุป

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