มธ. และ มส

MTU (หน่วยการส่งข้อมูลสูงสุด) เป็นแพ็กเก็ต IP ที่ใหญ่ที่สุดที่ลิงก์สามารถรองรับได้ Standard Ethernet มี MTU 1500 ไบต์ PPPoE (ใช้โดยการเชื่อมต่อ DSL จำนวนมาก) คือ 1492 Wi-Fi คือ 1500 อุโมงค์ WireGuard คือ 1420 ตามค่าเริ่มต้น MSS (ขนาดเซกเมนต์สูงสุด) เทียบเท่ากับเลเยอร์ TCP ซึ่งเป็นขนาดเพย์โหลดสูงสุดในกลุ่ม TCP เดียว ซึ่งก็คือ MTU ลบ IP และโอเวอร์เฮดส่วนหัว TCP (40 ไบต์สำหรับ IPv4, 60 สำหรับ IPv6)

เหตุใดขนาดแพ็คเก็ตจึงมีความสำคัญ

หากคุณส่งแพ็กเก็ตที่ใหญ่กว่า MTU ของลิงก์ หนึ่งในสองสิ่งนี้ เกิดขึ้น:

• Fragmentation: เราเตอร์แบ่งแพ็กเก็ตออกเป็นแฟรกเมนต์ IP ที่เล็กลง จุดหมายปลายทางประกอบใหม่ วิธีนี้ใช้งานได้แต่จะเพิ่มค่าใช้จ่ายและความเสียหายหากแฟรกเมนต์ใด ๆ สูญหาย
• Drop ด้วย ICMP "Fragmentation Needed": หากแพ็กเก็ต IP มีบิตเซ็ต Don't Fragment (โดยปกติ TCP จะทำ) เราเตอร์จะดรอปและตอบกลับด้วยข้อความ ICMP ที่ระบุ MTU ของลิงก์ ผู้ส่งคาดว่าจะลดขนาดแพ็กเก็ตแล้วลองอีกครั้ง นี่คือ Path MTU Discovery.

ปัญหา: ไฟร์วอลล์จำนวนมากบล็อกข้อความ ICMP Fragmentation Needed ผู้ส่งไม่เคยเรียนรู้ว่าควรจะลดขนาดแพ็กเก็ต การเชื่อมต่อหยุดทำงานเนื่องจากแพ็กเก็ตขนาดใหญ่หลุดไปอย่างเงียบๆ และไม่เคยส่งซ้ำในขนาดอื่น นี่คือหลุมดำ PMTUD แบบคลาสสิก.

เหตุใด VPN จึงทำให้สิ่งนี้แย่ลง

A VPN ห่อหุ้มแพ็กเก็ตของคุณในส่วนหัวเพิ่มเติม WireGuard เพิ่ม 60 ไบต์ (IPv4) หรือ 80 (IPv6) IPsec เพิ่ม 50–60 ไบต์ขึ้นอยู่กับโหมด OpenVPN เพิ่ม 41+ ไบต์บวกกับค่าใช้จ่ายของผู้ให้บริการ TCP/UDP ดังนั้นแพ็กเก็ตขนาด 1,500 ไบต์บนอีเทอร์เน็ตเมื่อขนส่งผ่านอุโมงค์ WireGuard จะกลายเป็น 1,560 ไบต์ ซึ่งใหญ่เกินไปสำหรับส่วนล่างของอีเทอร์เน็ต

คำตอบที่ถูกต้อง: ตั้งค่า MTU ของอุโมงค์ให้ต่ำกว่า MTU ด้านล่างลบด้วยค่าใช้จ่ายในการห่อหุ้ม WireGuard มีค่าเริ่มต้นเป็น 1420 เหลือพื้นที่ว่างไว้ 80 ไบต์ โดยทั่วไปแล้ว OpenVPN จะใช้ 1,500 ลบโอเวอร์เฮด ซึ่งมักจะอยู่ที่ประมาณ 1,450

MSS การหนีบ: วิธีแก้ไขที่ใช้งานได้จริง

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

VPN โดยทั่วไปแล้วจะเป็น MSS-clamp ตามค่าเริ่มต้น อินเทอร์เฟซ WireGuard บน Linux สามารถกำหนดค่าได้ด้วย:

iptables -t mangle -A FORWARD -p tcp --tcp-flags SYN,RST SYN \
  -j TCPMSS --clamp-mss-to-pmtu

This จะยึด MSS ของการเชื่อมต่อ TCP ทุกอันแบบไดนามิกกับทุกเส้นทางที่สามารถดำเนินการได้

อาการของปัญหา MTU

สัญญาณคลาสสิกที่ MTU เป็นตัวการ:

• Lกำลังโหลดหน้าแรกของ ไซต์ใช้งานได้ การส่งแบบฟอร์มค้าง เซสชัน
• SSH เชื่อมต่อได้ดี ls /large/directory ค้างกลางเอาท์พุต
• บางไซต์ทำงานได้ ส่วนบางไซต์หมดเวลา
• VPN รู้สึกว่า HTTPS ใช้งานไม่ได้ แต่ DNS ใช้งานได้
• อาการปรากฏขึ้นเฉพาะเมื่อการรับส่งข้อมูลมีขนาดใหญ่ (ดาวน์โหลด, อัปโหลด)

การวินิจฉัย: ping -M do -s 1472 example.com ส่งแพ็กเก็ต IPv4 ขนาด 1500 ไบต์ (ส่วนหัว IP 1472 + 20 + ส่วนหัว ICMP 8 อัน) โดยไม่มีชุดการแยกส่วน ลดจนกว่าจะสำเร็จ ขนาดการทำงาน + 28 = เส้นทาง MTU.

Jumbo frames

ลิงก์บางลิงก์สามารถพกพาแพ็กเก็ตที่มีขนาดใหญ่กว่า 1,500 ไบต์ — jumbo frames โดยทั่วไปคือ 9000 ไบต์ สิ่งเหล่านี้พบได้ทั่วไปในแฟบริคของศูนย์ข้อมูลที่ทุกลิงก์มีอีเทอร์เน็ตที่เหมือนกัน และลดโอเวอร์เฮดของ CPU ต่อแพ็กเก็ตสำหรับเวิร์กโหลดที่มีปริมาณงานสูง เช่น พื้นที่จัดเก็บข้อมูลและ HPC สิ่งเหล่านี้หาได้ยากบนอินเทอร์เน็ตสาธารณะ เส้นทางส่วนใหญ่หล่นไปที่ MTU.

QUIC ของลิงก์ที่เล็กที่สุดและ Path MTU

QUIC (การขนส่งสำหรับ HTTP/3) ทำการตรวจสอบ path-MTU ของตัวเองภายในโปรโตคอล เริ่มต้นแบบอนุรักษ์นิยม (ประมาณ 1200 ไบต์) และขยายขนาดโดยการส่งแพ็กเก็ตโพรบเป็นครั้งคราวเพื่อค้นหาความจุที่แท้จริงของพาธ วิธีนี้จะหลีกเลี่ยงหลุมดำ PMTUD โดยสิ้นเชิง - QUIC ไม่ได้ขึ้นอยู่กับข้อเสนอแนะของ ICMP เนื่องจากการปรับใช้ HTTP/3 แพร่กระจาย การแฮงค์ที่เกี่ยวข้องกับ MTU จึงหายากขึ้นในเลเยอร์แอปพลิเคชัน