VPN หลุดขณะอัปโหลดไฟล์ใหญ่: อ่านคิวก่อน

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

เปลี่ยนตัวแปรเพียงหนึ่งอย่างต่อการรันหนึ่งครั้ง และตรึงจุดปลายไว้

สร้างการเปรียบเทียบโหลดที่ทำซ้ำได้

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

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

บันทึกผลลัพธ์พร้อมตราเวลา เพื่อให้เทียบการรันแบบมีโหลดและแบบว่างได้ทีละบรรทัด

อ่านคิว ไม่ใช่อ่านความเร็ว

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

ping -c 20 -i 0.2 203.0.113.10
mtr -rwc 20 203.0.113.10
tc -s qdisc show dev eth0
ss -ti dst 203.0.113.10
nstat -az | grep -E 'Retrans|Timeout'

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

ตรวจสอบอุปกรณ์และเส้นทางควบคุม

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

uptime
mpstat -P ALL 1 3
dmesg | grep -i -E 'thermal|throttl'
journalctl -u openvpn-server@server --since '10 min ago' | tail -20

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

เปลี่ยนหนึ่งอย่างแล้วทำซ้ำ

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

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

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