ทำไม VPN ของฉันจึงช้า? ทดสอบสี่ช่วงนี้

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

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

ตัดสินว่าคำว่าช้าหมายถึงอะไรก่อนวัด

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

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

ตรวจสอบเครือข่ายการเข้าถึงก่อน

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

ping -c 20 192.168.50.1
ping -c 20 198.51.100.7
curl -o /dev/null -w "%{time_starttransfer} %{speed_download}\n" https://speed.example.net/10mb.bin

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

เปลี่ยนทางออก แล้วเปลี่ยนการขนส่ง

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

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

บันทึกโปรไฟล์ที่ช่วยไว้ก่อนลองการเปลี่ยนแปลงครั้งถัดไป มิฉะนั้นการถดถอยในภายหลังจะทำให้คุณเดาว่าการแก้ไขใดทำให้ดีขึ้น

อ่านอุปกรณ์และอาการควบคู่กัน

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

ping -M do -s 1400 -c 3 198.51.100.7
ip link show dev tun0 | grep -o "mtu [0-9]*"

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