ปัญหา MTU / MRU คืออะไรสิ่งที่เกิดจากและวิธีแก้ไข

ในกรณีของการแขวนแช่แข็งช้าการเชื่อมต่ออินเทอร์เน็ตไม่ตอบสนองสาเหตุมักจะถูกระบุโดยไม่มีเหตุผลสมควรเป็น "ปัญหา MTU / MRU" กับเสนอเร่งรีบ "รักษาวิเศษ" หลาย (โดยปกติจะไม่ถูกต้องหรือไม่เหมาะสมกับสถานการณ์) เช่นคำสั่งที่เกี่ยวข้องกับiptablesหรือifconfig, และอื่น ๆ " ใช้คาถา MTU กับ TSS "

สิ่งที่ฉันต้องการรู้คือสิ่งที่ปัญหาของ MTU / MRU คือสาเหตุที่มีผลต่อความเร็วในการเชื่อมต่อและเวลาในการเชื่อมต่อและวิธีการรักษาให้หาย (วิธีการที่รู้จักและทันสมัย) เนื่องจากฉันต้องการที่จะแก้ไขปัญหาด้วยความรู้ ไม่ได้อย่างน่าอัศจรรย์

นี่เป็นคำถามที่ซับซ้อนเล็กน้อยดังนั้นฉันจะเริ่มด้วยพื้นฐาน ยกโทษให้ฉันถ้าคุณรู้ทั้งหมดนี้แล้ว

MTU คือ Maximum Transmission Unit ซึ่งเป็นแพ็กเก็ตข้อมูลที่ใหญ่ที่สุดที่ส่วนต่อประสานคอมพิวเตอร์จะส่ง สำหรับ Ethernet ค่าเริ่มต้นคือ 1500 ไบต์ โดยทั่วไปเฟรมอีเธอร์เน็ตจะได้รับอนุญาตให้มีมากถึง 1522-1542 (ขึ้นอยู่กับสิ่งที่คุณนับ) และพื้นที่พิเศษคือ 'สงวน' สำหรับข้อมูลส่วนหัว

การเชื่อมต่อที่หลากหลายอาจมีความสามารถแตกต่างกัน เป็นเรื่องปกติที่จะใช้งานลิงค์บนอินเทอร์เน็ตที่มี MTU ที่เล็กกว่า 1500 เล็กน้อยซึ่งมักจะเกิดจากลิงค์ที่ใช้ข้อมูลส่วนหัวเพิ่มเติมหรือใช้สื่ออื่นที่ไม่ใช่อีเธอร์เน็ต 'มาตรฐาน' (อินเทอร์เน็ตส่วนใหญ่ทำงานบน การเชื่อมต่อ ATM / SoNet) โดยปกติทราฟฟิกที่พบลิงก์ดังกล่าวจะถูกแบ่งออกเป็นหลายชิ้นและส่งไปพร้อมกัน

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

รอบคัดเลือกในประโยคสุดท้ายนั้นคือนักเตะ มีเหตุผลทั่วไปสามประการที่กระบวนการอัตโนมัติแบ่งย่อย:

1. การติดตั้งใช้งานไม่ได้ - ซอฟต์แวร์ในบางครั้งที่ธรรมดาไม่ทำงานอย่างที่ควรจะเป็น ไม่มีกฎหมายที่บอกว่าผู้คนต้องปฏิบัติตามมาตรฐานที่เกี่ยวข้องของอินเทอร์เน็ตและมี บริษัท ที่ฝ่าฝืนมาตรฐานมักจะมีราคาถูก
2. การดำเนินการที่ถูกปิดการใช้งาน - มันเกิดขึ้นที่คนที่มีความตั้งใจดีทำลายซอฟต์แวร์เพราะพวกเขาไม่รู้ว่ากำลังทำอะไรอยู่ ฉันเคยเห็นคนบล็อก ICMP เพราะพวกเขาคิดว่ามันใช้สำหรับแพ็คเก็ต ICMP.0.0 เท่านั้น (echo คนส่วนใหญ่รู้เรื่องนี้โดยpingยูทิลิตี้)
3. เหตุผลอื่นที่นอกเหนือจากกระบวนการ 'ปกติ' นี้อย่างสมบูรณ์ โดยทั่วไปมักจะหมายถึงการเชื่อมต่อนั้นสูญเสียไปเพียงแพ็กเก็ตที่สั้นกว่าเท่านั้นที่ทำให้การเชื่อมต่อผ่านการเชื่อมต่อที่เชื่อถือได้ DSL และ CableModems รุ่นแรก ๆ มีปัญหาเช่นนี้ และก่อนหน้านั้นการต่อสายโทรศัพท์มักจะมีปัญหาเช่นนี้เมื่อใช้สายโทรศัพท์ที่มีคุณภาพต่ำมากและการวางสายแบบก้าวร้าว

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

MTU มีผลต่อการเชื่อมต่ออย่างไร การสับข้อมูลเป็นชิ้นเล็ก ๆ หมายความว่าแต่ละชิ้นจะมีโอกาสที่ดีกว่าในการไปยังปลายทางโดยเฉพาะอย่างยิ่งในการเชื่อมต่อที่ไม่น่าเชื่อถือสูง อย่างไรก็ตามการมีชิ้นส่วนเล็ก ๆ มีค่าใช้จ่ายมากกว่าต่อการส่งข้อมูล ซึ่งหมายความว่าความเร็วการเชื่อมต่อที่มีประสิทธิภาพจะลดลง อย่างมากหาก MTU มีขนาดเล็กมาก ความหน่วงแฝงอาจได้รับผลกระทบแม้ว่าฉันจะคาดหวังว่ามันจะมีขนาดเล็กเนื่องจากการประมวลผลพิเศษและค่าใช้จ่ายของส่วนหัวและกระบวนการกระจายตัว / การประกอบซ้ำ

Update: - เกี่ยวกับตัว--clamp-mss-to-pmtu
ฉันไม่เคยพูดพล่อยๆกับ MTU ฉันยอมรับว่าฉันเป็นพวกชอบความสมบูรณ์แบบและเมื่อถูกนำเสนอด้วยแฮ็กที่น่าเกลียดเช่นนี้ฉันมักจะพบรากของปัญหาและสามารถแก้ไขได้ ด้วยเหตุนี้iptablesตัวเลือก--clamp-mss-to-pmtuจึงไม่คุ้นเคยสำหรับฉัน เห็นได้ชัดว่ามันเป็นเรื่องธรรมดามากและมีแนวโน้มว่าจะไม่ได้รับการยอมรับในสถานการณ์ส่วนใหญ่เพื่อใช้แฮ็คนี้ ยังคงเป็นการแฮ็กเพื่อชดเชยปัญหาข้อใดข้อหนึ่งข้างต้น ฉันพูดจาก manpage Linux สำหรับ iptables (8):

เป้าหมายนี้ใช้เพื่อเอาชนะผู้ดูแลระบบ ISP หรือเซิร์ฟเวอร์ที่บล็อก 'ICMP Fragmentation Needed' หรือ 'ICMPv6 Packet Too Big' แพ็คเก็ต

ภาษาที่ค่อนข้างโหดร้ายของ manpage ควรเป็นเครื่องบ่งชี้ว่าผู้ให้บริการอินเทอร์เน็ตและเครือข่ายที่ดูถูกเหยียดหยามมากน้อยเพียงใดที่ไม่ปฏิบัติตาม RFCs (และไม่พยายามใช้หรือชดเชย)

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

โปรโตคอลการทันเนล VPN สมัยใหม่จำนวนมากถูกสร้างขึ้นในระดับที่ต่ำกว่า (โดยมีค่าใช้จ่ายน้อยกว่า) เช่น GRE และ L2TP หรือ tunneled ในระดับที่สูงขึ้น (โดยปกติจะเข้ากันได้กับไฟร์วอลล์ที่มีข้อ จำกัด หรือเหตุผลอื่น ๆ ) เช่น SSTP หรือ SSH สิ่งเหล่านี้จะค่อยๆแทนที่ UDP เป็นกลไกการขนส่ง

อัปเดต 2: - การวินิจฉัยปัญหา MTU / ICMP
ดังนั้นคุณคิดว่าคุณมีปัญหา MTU / ICMP และต้องการตรวจสอบให้แน่ใจ มีสองขั้นตอนพื้นฐานในกระบวนการนี้ คำแนะนำสำหรับกล่อง Linux หรือ BSD แต่สามารถปรับให้เข้ากับระบบปฏิบัติการใดก็ได้

1. เลือกเป้าหมาย Ping ICMP (เช่น Google.com, Yahoo.com, Facebook.com เป็นต้น) ping -c 2 -s 1472 -D google.comลองกระตุกพวกเขาด้วยคำสั่งต่อไปนี้:
   • สิ่งนี้น่าจะสำเร็จ หากไม่สำเร็จควรส่งคืน "แพ็กเก็ตที่ต้องแยกส่วน" หากสิ่งเหล่านี้เป็นจริงหยุดการเชื่อมต่อของคุณทำงานได้ดี
   • หากสิ่งนี้ไม่ส่งคืนสิ่งใดหรือให้ข้อความ "หมดเวลา" แสดงว่าคุณมีปัญหา
2. สำหรับการเชื่อมต่อเสียเท่านั้น: traceroute -F google.com 1472วิ่ง สิ่งนี้จะบอกคุณว่า hop ไหนเสีย หมายเหตุ: เป็นเรื่องปกติที่ CPE จะไม่ตอบสนองต่อคำขอ traceroute ดังนั้นอย่าตื่นตระหนกหากการกระโดดครั้งแรกไม่ตอบสนอง
   • แล้วแต่จำนวนใดจะถึงการตอบรับสุดท้ายคืออันสุดท้ายที่ทำงานอย่างถูกต้องสำหรับคุณ
   • หากไม่มีคนใดตอบว่ามันคือสาย CPE หรือ DSL ของคุณ (การหาว่าอะไรจะยุ่งยากบ้าง แต่ก็แทบจะไม่เคย CPE เลยถ้ามันทันสมัย หมายเหตุ: หากการเชื่อมต่อของคุณใช้งานได้ดี traceroute จะเสร็จสมบูรณ์

จากหมายเหตุด้านข้าง: ISP รายใดใช้ PPTP ในวันนี้! นั่นคือการระเบิดจากอดีตที่ล้าสมัยและไร้ประโยชน์ อย่างน้อยควรใช้ PPPoE แต่การอนุญาตโมเด็มโดย MAC และ Segment จะง่ายขึ้นมาก (ง่ายขึ้นสำหรับ ISP และลูกค้า)