MTU ของ VPN ที่เล็กลงเร็วขึ้นหรือไม่? เปรียบเทียบหลักฐานจริง
MTU ที่ต่ำลงอาจหลีกเลี่ยงขีดจำกัดของเส้นทางได้แต่ยังคงต้องเสียอัตราการส่งข้อมูล เปรียบเทียบข้อจำกัดจริง ค่าใช้จ่ายของส่วนหัว และภาระงานก่อนที่จะเก็บการเปลี่ยนแปลงไว้
อุโมงค์ทิ้งการถ่ายโอนขนาดใหญ่แต่ปล่อยให้ ping ผ่านไป คำแนะนำจึงมาถึงอย่างรวดเร็ว: ลด MTU การแก้ไขบางครั้งได้ผล แล้วมันก็ถูกนำไปใช้กับทุกโปรไฟล์ในทุกเครือข่าย นั่นคือจุดที่การซ่อมแบบเจาะจงกลายเป็นภาษีประสิทธิภาพถาวร การเปรียบเทียบที่ต้องทำคือระหว่างขีดจำกัดจริงของเส้นทางกับต้นทุนของการย่อทุกแพ็กเก็ตให้ต่ำกว่านั้น
สิ่งที่หดลงจริงเมื่อคุณลด MTU
ทุกแพ็กเก็ตมีส่วนหัวก่อนที่จะบรรทุกข้อมูลของคุณ บนเส้นทางอีเทอร์เน็ต 1500 ไบต์ IPv4 และ TCP ใช้ 40 ไบต์และเหลือ 1460 สำหรับเพย์โหลด การห่อหุ้มเพิ่มส่วนหัว IP, UDP และอุโมงค์ด้านนอกเข้าไปอีก จึงทำให้งบเพย์โหลดภายในลดลงอีกครั้ง การลด MTU ของอินเทอร์เฟซจงใจลดงบนั้น
ต้นทุนเป็นสัดส่วนกับจำนวนแพ็กเก็ต ไม่ใช่จำนวนไบต์ ไฟล์เดียวกันที่แบ่งเป็นแพ็กเก็ตมากขึ้นต้องใช้การขัดจังหวะมากขึ้น การตัดสินใจเรื่องเส้นทางมากขึ้น และการประมวลผลต่อแพ็กเก็ตมากขึ้นบนทุกอุปกรณ์ตลอดเส้นทาง บนเราเตอร์ที่ใกล้ถึงขีดจำกัดแพ็กเก็ตต่อวินาทีอยู่แล้ว นั่นคือการช้าลงจริง ไม่ใช่ข้อผิดพลาดจากการปัดเศษ ต้นทุนปรากฏแม้เมื่อการถ่ายโอนเองสำเร็จ
นี่คือเหตุผลที่ MTU ที่เล็กลงเป็นการอ้อมข้อจำกัด ไม่ใช่การเพิ่มประสิทธิภาพทั่วไป มันซื้อความน่าเชื่อถือต่อเส้นทางที่ไม่สามารถบรรทุกเฟรมที่ใหญ่กว่า และเรียกเก็บค่าใช้จ่ายเพิ่มเติมสำหรับทุกแพ็กเก็ตที่ไม่จำเป็นต้องลดขนาด
เมื่อใดที่ MTU ที่เล็กลงเป็นการแก้ไขที่ถูกต้อง
อาการคลาสสิกนั้นเฉพาะเจาะจง: การจับมือ TCP เสร็จสมบูรณ์ คำตอบเล็ก ๆ มาถึง และการดาวน์โหลดขนาดใหญ่หยุดหรือรีเซ็ต ping ที่มีบิตไม่แบ่งส่วนที่ 1472 ไบต์ล้มเหลว ขณะที่ ping 1400 ไบต์สำเร็จ ซึ่งชี้ไปที่เส้นทางที่ไม่สามารถบรรทุกแพ็กเก็ตขนาดเต็มและไม่ส่งข้อความ ICMP ที่จะบอกผู้ส่งให้ย่อลง
การค้นพบ MTU ของเส้นทางขึ้นอยู่กับข้อความ ICMP ที่แจ้งว่าต้องแบ่งส่วนเหล่านั้น เมื่อไฟร์วอลล์ทิ้งข้อความเหล่านั้น ผู้ส่งยังคงลองแพ็กเก็ตใหญ่ซ้ำ และการเชื่อมต่อดูเหมือนค้าง การลด MTU ฝั่งอุโมงค์หลีกเลี่ยงการลองซ้ำ และนั่นคือการซ่อมที่ชอบธรรมสำหรับเครือข่ายนั้น
เทคโนโลยีการเข้าถึงก็กำหนดขีดจำกัดของตัวเองเช่นกัน: PPPoE มักจำกัดที่ 1492 บางเส้นทางมือถือและ DSL ต่ำกว่า และอุโมงค์ซ้อนกันหักค่าใช้จ่ายสองครั้ง วัดเส้นทางจริงแทนการคัดลอกตัวเลขจากคู่มือ และจำไว้ว่า IPv6 ต้องการ MTU อย่างน้อย 1280 ไบต์บนทุกลิงก์ที่บรรทุกมัน ตามที่ RFC 8200 ระบุ
เปรียบเทียบตัวควบคุมทั้งสามก่อนที่จะเปลี่ยนหนึ่ง
MTU, MSS และการแบ่งส่วนเป็นตัวควบคุมที่ต่างกันในชั้นที่ต่างกัน และการเปลี่ยนตัวที่ผิดทำให้อาการยังอยู่
| Control | Layer | What it changes | Where it misleads |
|---|---|---|---|
| Interface MTU | IP link | Largest frame the interface will send | Penalizes every protocol, not just the one that failed |
| TCP MSS clamp | TCP | Segment size advertised in the handshake | Leaves UDP and QUIC untouched |
| DF and fragmentation | IP | Whether a router may split a packet | Can break path MTU discovery and security assumptions |
| Tunnel overhead | Encapsulation | Inner MTU after outer headers | Mismatch shows up only for large inner packets |
การจำกัด MSS มักเป็นการซ่อมที่รุกล้ำน้อยที่สุด เพราะมันส่งผลต่อ TCP เท่านั้นและปล่อยอินเทอร์เฟซให้ว่างสำหรับทราฟฟิกอื่น MTU ของอินเทอร์เฟซที่ต่ำกว่านั้นกว้างกว่าและคิดตามได้ง่ายกว่า จึงเป็นเรื่องปกติบนเราเตอร์สำหรับผู้บริโภค แต่มันเรียกเก็บปัญหาของโปรโตคอลเดียวจากทุกโปรโตคอล
การปิดพฤติกรรมไม่แบ่งส่วนซ่อนอาการโดยอนุญาตให้แบ่งส่วน และมักทำให้ความหน่วงแย่ลงพร้อมกับทำลายผลป้อนกลับที่จะหาขนาดที่ถูกต้อง หลีกเลี่ยงการใช้เป็นวิธีแก้ถาวร
วัดการแลกเปลี่ยนแทนตัวเลขเดียว
หาขีดจำกัดของเส้นทางด้วยโพรบไม่แบ่งส่วน เริ่มจากค่าสูงและลดลงจนกว่าคำตอบจะมา:
ping -M do -s 1472 203.0.113.10
ping -M do -s 1400 203.0.113.10
tracepath 203.0.113.10จากนั้นเปรียบเทียบงานจริงบนการตั้งค่าทั้งสอง: การถ่ายโอนไฟล์เดียวกัน จุดปลายทางเดียวกัน และเครือข่ายเดียวกัน บันทึกเวลาที่เสร็จและการส่งซ้ำ เช่นด้วย nstat -az TcpRetransSegs และเฝ้าดู CPU ของอุปกรณ์หากอุโมงค์สิ้นสุดบนเราเตอร์เล็ก การทดสอบอัตราส่งข้อมูลแบบสังเคราะห์ระยะสั้นอาจพลาดการหยุดที่ปรากฏหลังหลายเมกะไบต์
ตัวนับแพ็กเก็ตจะเพิ่มขึ้นหลังการลด เพราะการถ่ายโอนเดียวกันใช้แพ็กเก็ตมากขึ้น นั่นเป็นสิ่งที่คาดไว้และไม่ใช่หลักฐานของอัตราส่งข้อมูลที่สูงขึ้น เปรียบเทียบข้อมูลแอปพลิเคชันที่เสร็จแล้ว จำนวนการส่งซ้ำ และการตอบสนอง ไม่ใช่แค่อัตราแพ็กเก็ต
นำการเปลี่ยนแปลงมาเป็นขั้นตอนและจำกัดขอบเขตไว้
บันทึกค่าเดิม เปลี่ยนตัวควบคุมหนึ่งตัว และทำการวัดซ้ำก่อนทำให้ถาวร หากหลักฐานไม่แสดงประโยชน์ ให้คืนค่าเดิมด้วยคำสั่งอินเทอร์เฟซเดียวกันกับที่คุณใช้ตั้งค่า:
ip link set dev wg0 mtu 1420
ip link set dev wg0 mtu 1500จำกัดผลลัพธ์ไว้กับเครือข่ายที่ต้องการมัน โปรไฟล์ที่ต้องทำงานบน Wi-Fi โรงแรม ฮอตสปอตมือถือ และ LAN ของสำนักงานไม่ควรสืบทอดค่าที่ต่ำที่สุดที่เครือข่ายใดเครือข่ายหนึ่งต้องการ เว้นแต่ไคลเอนต์จะตรวจหาเส้นทางไม่ได้
ค่าที่ถูกต้องคือ MTU ที่ใหญ่ที่สุดที่อยู่รอดบนเส้นทาง ไม่ใช่ค่าที่เล็กที่สุดที่ทำให้อาการหายไป จัดทำเอกสารเส้นทาง ผลของโพรบ และการย้อนกลับ และทบทวนการตั้งค่าเมื่อเครือข่ายการเข้าถึงเปลี่ยน