ทำไมการแชร์ไฟล์ผ่าน VPN ถึงรู้สึกช้า: จำนวนรอบไปกลับ ไม่ใช่ Mbps

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

สำเนาทำงานระยะไกลมีรูปทรงผิด

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

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

นับรอบไปกลับก่อนเมกะไบต์

วัดความหน่วงก่อนซื้อความจุ ping ครั้งเดียวบอกว่าการแลกเปลี่ยนแต่ละครั้งจ่ายอะไร

ping -c 10 fileserver.example.net

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

ย้ายงาน ไม่ใช่ย้ายไบต์

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

rsync -av --info=progress2 ./project/ [email protected]:/srv/share/project/

การให้บริการรีโพซิทอรีอย่างที่ hgweb หรือ Git ระยะไกลทำ ทำให้ไคลเอนต์ทำงานบนโคลนภายใน การเรียกใช้ระบบไฟล์จึงไม่ข้ามอุโมงค์ rsync ไล่ทั้งสองฝั่งและส่งเฉพาะบล็อกที่เปลี่ยน จึงตัดการแลกเปลี่ยนส่วนใหญ่ที่การคัดลอกแบบง่ายต้องจ่าย ฐานข้อมูลเดสก์ท็อปควรอยู่บนเอนจินฝั่งเซิร์ฟเวอร์ โดยไคลเอนต์เหลือเพียงส่วนหน้า หรือให้ไคลเอนต์ทั้งหมดทำงานบนโฮสต์ภายใน แต่ละทางเลือกเปลี่ยนว่าโปรโตคอลต้องเผชิญความหน่วงมากแค่ไหน นั่นคือประเด็น

การค้างที่ขนาดใกล้กันเป็นอาการของ MTU

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

ping -M do -s 1400 -c 3 fileserver.example.net

การทดสอบที่สำเร็จหมายถึงแพ็กเก็ต IP ขนาด 1428 ไบต์ผ่านเส้นทางได้โดยไม่ถูกแบ่งส่วน เพราะหัว ICMP และ IP เพิ่ม 28 ไบต์ ความล้มเหลวเมื่อตั้งธงห้ามแบ่งส่วนบ่งชี้ว่า MTU ที่ใช้ได้ของอุโมงค์เล็กกว่าที่เซิร์ฟเวอร์คิด เซิร์ฟเวอร์ที่ส่งบัฟเฟอร์ 9000 ไบต์ไปยังเส้นทาง 1500 ไบต์บังคับให้แบ่งส่วนหรือทิ้ง และการค้นหา MTU ของเส้นทางอาจล้มเหลวเงียบ ๆ เมื่อ ICMP ถูกกรอง ลด MTU ของอุโมงค์ เปิดใช้ mssfix บน OpenVPN หรือลดบัฟเฟอร์ของเซิร์ฟเวอร์ แล้วรันการถ่ายโอนเดิมอีกครั้งเพื่อยืนยัน

วัดช่องว่างที่มีความหมาย

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

เมื่อแค่เมกะไบต์แรก ๆ ลากช้า ให้ดูการพิสูจน์ตัวตนและเมทาดาทา เมื่อทุกอย่างช้า ให้ดูความจุและการสูญเสีย แก้สาเหตุที่ตรงกัน และเลิกคาดว่าลิงก์ WAN จะประพฤติเหมือนสาย LAN