VPN จะเร็วกว่าการเชื่อมต่อโดยตรงได้หรือไม่
การห่อหุ้มเพิ่มภาระ แต่ทางออกอาจเปลี่ยนเส้นทางผ่านเครือข่าย ปลายทาง และเงื่อนไขการขนส่ง ตัดสินด้วยการเปรียบเทียบสามอย่าง ไม่ใช่การทดสอบความเร็วครั้งเดียว
การถ่ายโอนที่คลานช้าบนการเชื่อมต่อสำนักงานบางครั้งจบเร็วผ่านอุโมงค์ และการห่อหุ้มเพิ่มเติมทำให้ดูเหมือนเป็นไปไม่ได้ ความขัดแย้งที่เห็นได้นี้มาจากการเปรียบเทียบสิ่งที่ผิด อุโมงค์เพิ่มงาน และยังเปลี่ยน เส้นทางเครือข่ายที่ทราฟฟิกใช้ ที่อยู่ที่ปลายทางเห็น และบางครั้งเซิร์ฟเวอร์ที่ตอบสนอง การตัดสินใจระหว่างสองเส้นทางต้องแยกผลกระทบสามข้อนี้ก่อนจะสรุปเรื่องความเร็ว
สามสิ่งที่อุโมงค์เปลี่ยนได้
อย่างแรกคือเส้นทางผ่านเครือข่าย การกำหนดเส้นทางอินเทอร์เน็ตเป็นไปตามนโยบายของผู้ให้บริการและความสัมพันธ์ทางธุรกิจ ไม่ใช่ความหน่วงที่วัดได้ ดังนั้นเส้นทางผ่านผู้ให้บริการ VPN จึงอาจผ่านเครือข่ายอื่นที่ต่างจากเส้นทางตรง อาจหลีกเลี่ยงจุดแลกเปลี่ยนที่แออัดหรือไปลงที่จุดที่มี peering ดีกว่า และก็อาจแย่กว่าได้ง่ายพอ ๆ กัน
อย่างที่สองคือปลายทาง การเปลี่ยนที่อยู่ขาออกมักเปลี่ยนคำตอบ DNS และเครือข่ายเนื้อหาอาจให้แคชหรือภูมิภาคอื่นแก่คุณ ส่วนหนึ่งของการปรับปรุงจึงเป็นของเซิร์ฟเวอร์ใหม่ ไม่ใช่อุโมงค์ ชื่อโฮสต์เดียวกันอาจไปลงที่เซิร์ฟเวอร์ที่ใกล้กว่าหรือมีภาระน้อยกว่าโดยไม่มีอะไรเปลี่ยนที่ไคลเอนต์
อย่างที่สามคือพฤติกรรมการขนส่ง การห่อหุ้มเปลี่ยนขนาดแพ็กเก็ตที่มีผล และอุโมงค์ที่หลีกเลี่ยงส่วนกลางที่มีการสูญเสียอาจปล่อยให้กระแส TCP ขยายหน้าต่างแทนที่จะถอยซ้ำ ๆ ไม่มีข้อใดเป็นกลไกเร่งความเร็วสากล แต่ละข้อเป็นเงื่อนไขที่ต้องสังเกต การแยกสิ่งเหล่านี้ออกจากกันคือสิ่งที่เปลี่ยนความอยากรู้ให้เป็นข้อเท็จจริง
สิ่งที่มันเปลี่ยนไม่ได้
ไม่มีอะไรในอุโมงค์เพิ่มความจุให้กับลิงก์ระหว่างอุปกรณ์กับเครือข่าย ช่อง Wi-Fi ที่อิ่มตัว ไมล์สุดท้ายที่แออัด หรือแพ็กเกจมือถือที่มีขีดจำกัด จำกัดทั้งสองเส้นทางเท่า ๆ กัน และการทดสอบความเร็วผ่านอุโมงค์ไม่อาจเกินเพดานนั้นได้ ลิงก์เดียวกันบรรทุกแพ็กเก็ตที่ห่อหุ้มไว้ ดังนั้นการห่อหุ้มใช้ความจุได้แต่ไม่เคยสร้างมันขึ้นมา สิ่งที่เปลี่ยนคือแพ็กเก็ตไปที่ใดหลังจากออกจากลิงก์นั้น นั่นคือเหตุผลที่ผลลัพธ์อุโมงค์ที่เร็วมีคำอธิบายเหนือฮอปแรกเสมอ
ขีดจำกัดฝั่งเซิร์ฟเวอร์ก็ไม่แยแสเช่นกัน หากโฮสต์ระยะไกลให้บริการช้า เส้นทางที่ดีกว่าจะส่งคำตอบที่ช้าได้อย่างมีประสิทธิภาพกว่าเท่านั้น และผู้ใช้ก็ยังรออยู่ แหล่งที่ใช้ร่วมกันภายใต้ภาระดูช้าทั้งสองเส้นทางในขณะเดียวกัน
เปรียบเทียบเส้นทางให้ถูกต้อง
รักษาแอปพลิเคชัน ทิศทาง ระยะเวลา และการทำงานพร้อมกันให้เหมือนกัน แล้วเปลี่ยนเฉพาะเส้นทาง รันการทดสอบแต่ละครั้งมากกว่าหนึ่งครั้งในเวลาเดียวกันของวัน และบันทึกที่อยู่ขาออกและคำตอบของตัวแก้ไขควบคู่กับอัตราการส่งข้อมูล การรันครั้งเดียวคือตัวอย่างไม่ใช่การวัด และการดาวน์โหลดเร็วครั้งเดียวอาจเป็นการชนแคชที่ไม่บอกอะไรเกี่ยวกับเส้นทาง เขียนเงื่อนไขก่อนผลลัพธ์ เพราะตัวเลขตีความยากในภายหลัง
mtr -rwc 50 -T -P 443 203.0.113.20
curl -o /dev/null -s -w '%{speed_download} %{time_connect}\n' https://example.com/file
dig +short cdn.example.com
traceroute -n -T -p 443 cdn.example.comคำตอบของตัวแก้ไขคือรายละเอียดที่การเปรียบเทียบส่วนใหญ่ละไว้ และอธิบาย “การปรับปรุง” ที่หายไปเมื่อบังคับให้ใช้เซิร์ฟเวอร์เดียวกัน หากที่อยู่ต่างกันระหว่างการรัน การทดสอบได้เปรียบเทียบสองปลายทางไม่ใช่สองเส้นทาง รายงานความหน่วงและการสูญเสียควบคู่กับอัตราการส่งข้อมูล เพราะเส้นทางที่เร็วกว่าโดยรวมแต่เพิ่มความหน่วงให้ทุกคำขอแบบโต้ตอบไม่ดีกว่าสำหรับภาระงานที่บ่นมา เวลาไปกลับสำคัญกว่าความเร็วจำนวนมากสำหรับทุกสิ่งที่ไม่ถามแล้วรอ
เมื่อใดที่ความแตกต่างคุ้มค่าที่จะเก็บไว้
หากอุโมงค์ที่ได้รับอนุมัติปรับปรุงภาระงานเฉพาะอย่างได้อย่างน่าเชื่อถือ นั่นคือทางเลือกในการปฏิบัติงานที่ชอบธรรม: บันทึกภาระงาน การวัด และทางออกที่ใช้ บันทึกที่ใช้ได้ระบุโฮสต์หนึ่งเครื่อง ที่อยู่ขาออกที่อุโมงค์สร้าง คำตอบของตัวแก้ไข และตัวเลขชุดเดียวกันจากเส้นทางตรงในวันเดียวกัน เท่านี้ก็เพียงพอให้วิศวกรคนถัดไปทำการเปรียบเทียบซ้ำแทนที่จะโต้แย้งใหม่ ยังไม่ใช่หลักฐานว่าผู้ให้บริการจำกัดสิ่งใด และไม่ส่งต่อไปยังแอปพลิเคชันอื่นหรือเวลาอื่น
เก็บบันทึกการวัดไว้กับการกำหนดค่า มันตอบคำถามถัดไปว่าการปรับปรุงยังมีอยู่หรือไม่ และนั่นเป็นวิธีเดียวที่จะรู้ว่าเส้นทางหรือภาระงานเปลี่ยนไปหรือไม่ บันทึกที่ไม่มีวันที่ตอบคำถามนั้นไม่ได้เลย