หน่วยส่งสูงสุด (MTU)
ในระบบเครือข่ายคอมพิวเตอร์ คำว่า Maximum Transmission Unit (MTU) หมายถึงขนาด (เป็นไบต์) ของ PDU ที่ใหญ่ที่สุดที่เลเยอร์ที่กำหนดของโปรโตคอลการสื่อสารสามารถส่งต่อได้ พารามิเตอร์ MTU มักจะปรากฏร่วมกับอินเทอร์เฟซการสื่อสาร (NIC, พอร์ตอนุกรม ฯลฯ) MTU อาจได้รับการแก้ไขตามมาตรฐาน (เช่นเดียวกับอีเทอร์เน็ต) หรือตัดสินใจในเวลาเชื่อมต่อ (ตามปกติในกรณีของลิงก์อนุกรมแบบจุดต่อจุด) MTU ที่สูงขึ้นทำให้มีประสิทธิภาพมากขึ้น เนื่องจากแต่ละแพ็กเก็ตมีข้อมูลผู้ใช้มากกว่า ในขณะที่โอเวอร์เฮดของโปรโตคอล เช่น ส่วนหัวหรือความล่าช้าต่อแพ็กเก็ตพื้นฐานยังคงคงที่ และประสิทธิภาพที่สูงขึ้นหมายถึงการปรับปรุงเล็กน้อยในอัตราการส่งข้อมูลของโปรโตคอลจำนวนมาก อย่างไรก็ตาม แพ็กเก็ตขนาดใหญ่อาจใช้ลิงก์ที่ช้าในบางครั้ง ทำให้เกิดความล่าช้ามากขึ้นในการติดตามแพ็กเก็ต และเพิ่มความล่าช้าและเวลาแฝงขั้นต่ำ ตัวอย่างเช่น แพ็กเก็ตขนาด 1500 ไบต์ ซึ่งใหญ่ที่สุดที่อีเธอร์เน็ตอนุญาตในเลเยอร์เครือข่าย (และด้วยเหตุนี้ส่วนใหญ่ของอินเทอร์เน็ต) จะผูกโมเด็ม 14.4k ไว้ประมาณหนึ่งวินาที
การค้นพบเส้นทาง MTU
Internet Protocol กำหนด "เส้นทาง MTU" ของเส้นทางการรับส่งข้อมูลทางอินเทอร์เน็ตว่าเป็น MTU ที่เล็กที่สุดของ IP hops ของ "เส้นทาง" ระหว่างต้นทางและปลายทาง กล่าวอีกนัยหนึ่ง เส้นทาง MTU คือขนาดแพ็กเก็ตที่ใหญ่ที่สุดที่ข้ามผ่านเส้นทางนี้โดยไม่มีการแตกแฟรกเมนต์
RFC 1191 อธิบาย "การค้นพบเส้นทาง MTU" ซึ่งเป็นเทคนิคในการกำหนดเส้นทาง MTU ระหว่างโฮสต์ IP สองแห่ง ทำงานโดยการตั้งค่าตัวเลือก DF (Don't Fragment) ในส่วนหัว IP ของแพ็กเก็ตขาออก อุปกรณ์ใดๆ ตามเส้นทางที่ MTU มีขนาดเล็กกว่าแพ็กเก็ตจะปล่อยแพ็กเก็ตดังกล่าวและส่งข้อความ "Destination Unreachable (Datagram Too Big)" ของ ICMP ที่มี MTU ของมัน ซึ่งช่วยให้โฮสต์ต้นทางลดเส้นทาง MTU ที่สันนิษฐานได้อย่างเหมาะสม กระบวนการนี้จะทำซ้ำจนกว่า MTU จะเล็กพอที่จะสำรวจเส้นทางทั้งหมดโดยไม่มีการแตกแฟรกเมนต์
น่าเสียดายที่จำนวนเครือข่ายที่เพิ่มขึ้นทำให้ทราฟฟิก ICMP ลดลง (เช่น เพื่อป้องกันการโจมตีแบบปฏิเสธการให้บริการ) ซึ่งทำให้ไม่สามารถค้นพบเส้นทาง MTU ได้ มักตรวจพบการบล็อกดังกล่าวในกรณีที่การเชื่อมต่อทำงานสำหรับข้อมูลที่มีปริมาณน้อย แต่จะค้างทันทีที่โฮสต์ส่งข้อมูลจำนวนมากในแต่ละครั้ง ตัวอย่างเช่น เมื่อใช้ IRC ลูกค้าที่เชื่อมต่ออาจเห็นข้อความ ping แต่ไม่ได้รับการตอบกลับหลังจากนั้น เนื่องจากข้อความต้อนรับชุดใหญ่ถูกส่งออกไปในแพ็กเก็ตที่ใหญ่กว่า MTU จริง นอกจากนี้ ในเครือข่าย IP เส้นทางจากที่อยู่ต้นทางไปยังที่อยู่ปลายทางมักจะได้รับการแก้ไขแบบไดนามิก เพื่อตอบสนองต่อเหตุการณ์ต่างๆ (การปรับสมดุลโหลด ความแออัด เอาต์พุต ฯลฯ) ซึ่งอาจทำให้เส้นทาง MTU เปลี่ยนไป (บางครั้ง ซ้ำ) ระหว่างการส่ง ซึ่งอาจนำไปสู่การดรอปแพ็คเก็ตเพิ่มเติมก่อนที่โฮสต์จะพบ MTU ที่ปลอดภัยใหม่
อีเทอร์เน็ต LAN ส่วนใหญ่ใช้ MTU 1500 ไบต์ (LAN สมัยใหม่สามารถใช้ Jumbo frames ได้ อนุญาตให้ใช้ MTU ได้ถึง 9000 ไบต์) อย่างไรก็ตาม โปรโตคอลเส้นขอบ เช่น PPPoE จะลดสิ่งนี้ลง ซึ่งทำให้การค้นพบเส้นทาง MTU มีผลกับผลลัพธ์ที่เป็นไปได้ในการทำให้บางไซต์ที่อยู่หลังไฟร์วอลล์ที่กำหนดค่าไม่ดีไม่สามารถเข้าถึงได้ เราสามารถแก้ไขได้โดยขึ้นอยู่กับว่าส่วนใดของเครือข่ายที่ควบคุม ตัวอย่างเช่นสามารถเปลี่ยน MSS (ขนาดเซ็กเมนต์สูงสุด) ในแพ็กเก็ตเริ่มต้นที่ตั้งค่าการเชื่อมต่อ TCP ที่ไฟร์วอลล์ของตน
ปัญหานี้เกิดขึ้นบ่อยขึ้นตั้งแต่เปิดตัว Windows Vista ซึ่งแนะนำ 'Next Generation TCP/IP Stack' การดำเนินการนี้ใช้ "การปรับหน้าต่างรับอัตโนมัติซึ่งกำหนดขนาดหน้าต่างการรับที่เหมาะสมอย่างต่อเนื่องโดยการวัดผลิตภัณฑ์แบนด์วิดท์ล่าช้าและอัตราการดึงข้อมูลของแอปพลิเคชัน และปรับขนาดหน้าต่างรับสูงสุดตามเงื่อนไขเครือข่ายที่เปลี่ยนแปลง"[2] สิ่งนี้ถูกมองว่าล้มเหลวร่วมกับเราเตอร์และไฟร์วอลล์รุ่นเก่าที่ดูเหมือนว่าจะทำงานร่วมกับระบบปฏิบัติการอื่นได้ พบได้บ่อยในเราเตอร์ ADSL และสามารถแก้ไขได้โดยการอัปเดตเฟิร์มแวร์
แบ็คโบนของ ATM ตัวอย่างการปรับจูน MTU
ในบางครั้ง จะดีกว่าในแง่ของประสิทธิภาพในการประกาศ MTU ที่ลดขนาดลงเทียมในซอฟต์แวร์ที่ต่ำกว่าความยาวสูงสุดที่เป็นไปได้จริงที่รองรับ ตัวอย่างหนึ่งคือกรณีที่มีการรับส่งข้อมูล IP ผ่านเครือข่าย ATM (โหมดการถ่ายโอนแบบอะซิงโครนัส) ผู้ให้บริการบางราย โดยเฉพาะผู้ให้บริการที่มีพื้นฐานด้านโทรศัพท์ ใช้ ATM ในเครือข่ายแกนหลักภายใน
การใช้ ATM อย่างมีประสิทธิภาพสูงสุดจะเกิดขึ้นได้เมื่อความยาวของแพ็กเก็ตเป็นทวีคูณของ 48 ไบต์ ทั้งนี้เนื่องจาก ATM ถูกส่งเป็นสตรีมของแพ็กเก็ตที่มีความยาวคงที่ (เรียกว่า 'เซลล์') ซึ่งแต่ละอันสามารถบรรทุกข้อมูลผู้ใช้ได้ 48 ไบต์ โดยมีค่าโอเวอร์เฮด 5 ไบต์สำหรับราคารวม 53 ไบต์ต่อเซลล์ ดังนั้นความยาวรวมของความยาวข้อมูลที่ส่งคือ 53 * ncells ไบต์ โดยที่ ncells = จำนวนเซลล์ที่ต้องการ = INT((payload_length+47)/48) ดังนั้น ในกรณีที่เลวร้ายที่สุด โดยที่ความยาวรวม = (48*n+1) ไบต์ จำเป็นต้องใช้เซลล์เพิ่มเติมหนึ่งเซลล์เพื่อส่งหนึ่งไบต์สุดท้ายของเพย์โหลด เซลล์สุดท้ายมีค่าใช้จ่าย 53 ไบต์ที่ส่งเพิ่มเติม 47 เซลล์เป็นช่องว่างภายใน ด้วยเหตุผลนี้ การประกาศ MTU ที่ลดลงในซอฟต์แวร์โดยไม่ได้ตั้งใจจะเพิ่มประสิทธิภาพโปรโตคอลสูงสุดที่เลเยอร์ ATM โดยทำให้ความยาวเพย์โหลดทั้งหมดของ ATM AAL5 เพิ่มขึ้นเป็นทวีคูณของ 48 ไบต์ทุกครั้งที่ทำได้
ตัวอย่างเช่น 31 เซลล์ ATM ที่เติมอย่างสมบูรณ์จะบรรทุกของได้ 31*48=1488 ไบต์ เมื่อพิจารณาจากตัวเลข 1488 นี้แล้วลบค่าโสหุ้ยใดๆ ที่เกิดจากโปรโตคอลที่สูงกว่าที่เกี่ยวข้องทั้งหมด เราสามารถรับค่าที่แนะนำสำหรับ MTU ที่ลดค่าอย่างเหมาะสมที่สุดโดยไม่ตั้งใจ ในกรณีที่ผู้ใช้มักจะส่งแพ็คเก็ต 1500 ไบต์ การส่งระหว่าง 1489 ถึง 1536 ไบต์ต้องการค่าใช้จ่ายคงที่เพิ่มเติมของการส่ง 53 ไบต์ ในรูปแบบของเซลล์ ATM พิเศษหนึ่งเซลล์
สำหรับตัวอย่างของ IP ผ่านการเชื่อมต่อ DSL โดยใช้ PPPoA/VC-MUX อีกครั้งโดยเลือกเติม 31 เซลล์ ATM เช่นเดิม เราได้รับตัวเลข MTU ที่ลดลงอย่างเหมาะสมที่ต้องการเป็น 1478 = 31*48-10 โดยคำนึงถึงโอเวอร์เฮด 10 ไบต์ซึ่งประกอบด้วย ของโอเวอร์เฮดโปรโตคอลแบบจุดต่อจุด 2 ไบต์ และโอเวอร์เฮด AAL5 ขนาด 8 ไบต์ สิ่งนี้ทำให้ต้นทุนรวม 31*53=1643 ไบต์ที่ส่งผ่าน ATM จากแพ็กเก็ต 1478 ไบต์ที่ส่งไปยัง PPPoA ในกรณีของ IP ที่ส่งผ่าน ADSL โดยใช้ PPPoA ตัวเลข 1478 จะเป็นความยาวทั้งหมดของแพ็กเก็ต IP รวมถึงส่วนหัวของ IP ดังนั้นในตัวอย่างนี้ การรักษา MTU ที่ลดขนาดเองไว้ที่ 1478 เมื่อเทียบกับการส่งแพ็กเก็ต IP ที่มีความยาวทั้งหมด 1500 จะบันทึก 53 ไบต์ต่อแพ็กเก็ตที่เลเยอร์ ATM โดยลดความยาวของแพ็กเก็ต IP ลง 22 ไบต์
MTU สูงสุดสำหรับการเชื่อมต่อ PPPoE/DSL คือ 1492 ต่อ RFC 2516: 6 ไบต์เป็นส่วนหัวของ PPPoE ทำให้มีที่ว่างเพียงพอสำหรับเพย์โหลด 1488 ไบต์ หรือเซลล์ ATM เต็ม 31 เซลล์
สุดท้าย: ค่ามาตรฐานของ MTU จะเท่ากับ 1492.... และในกรณีที่เกิดปัญหาการท่องเว็บหรือปัญหาการเชื่อมต่อ MSN ควรลดค่าลงเป็น 1422 และ 1420
อ้างอิง: วิกิพีเดีย
ด้วยความเคารพ
สวัสดีครับ ขอบคุณสำหรับบทความที่เป็นประโยชน์