ในเครือข่ายคอมพิวเตอร์จัมโบ้เฟรมคือเฟรมอีเธอร์เน็ตที่มีเพย์โหลดมากกว่า 1500 ไบต์ ซึ่งเป็นขีดจำกัดที่กำหนดโดยมาตรฐานIEEE 802.3 ^{[ 1 ]}ขีดจำกัดเพย์โหลดสำหรับจัมโบ้เฟรมนั้นแปรผันได้ โดย 9000 ไบต์เป็นขีดจำกัดที่ใช้กันทั่วไปมากที่สุด แต่ก็มีขีดจำกัดที่เล็กกว่าและใหญ่กว่านั้นอยู่ สวิตช์ Gigabit Ethernetและตัวควบคุมอินเทอร์เฟซเครือข่าย Gigabit Ethernet จำนวนมาก รวมถึง สวิตช์ Fast Ethernetและการ์ดอินเทอร์เฟซเครือข่าย Fast Ethernet บางตัวสามารถรองรับจัมโบ้เฟรมได้^{[ 2 ]}

แต่ละเฟรมอีเธอร์เน็ตจะต้องได้รับการประมวลผลขณะที่ผ่านเครือข่าย การประมวลผลเนื้อหาของเฟรมขนาดใหญ่เฟรมเดียวดีกว่าการประมวลผลเนื้อหาเดียวกันที่แบ่งออกเป็นเฟรมขนาดเล็ก เนื่องจากวิธีนี้ใช้ประโยชน์จากเวลา CPU ที่มีอยู่ได้ดีขึ้นโดยลดการขัดจังหวะ นอกจากนี้ยังช่วยลดจำนวนไบต์ส่วนเกินและลดจำนวนเฟรมที่ต้องประมวลผล^{[ 3 ]}ซึ่งคล้ายกับการส่งเอกสารเป็นชุดทางไปรษณีย์แทนที่จะส่งเป็นซองหลายซองที่มีเอกสารเพียงแผ่นเดียวในแต่ละซอง ซึ่งช่วยประหยัดซองจดหมายและลดเวลาในการคัดแยก

เฟรมจัมโบ้เริ่มเป็นที่รู้จักอย่างแพร่หลายในปี 1998 เมื่อAlteon WebSystemsนำเสนอเฟรมจัมโบ้ในอะแดปเตอร์ ACEnic Gigabit Ethernet ของตน ^{[ 4 ]}ผู้จำหน่ายรายอื่น ๆ อีกหลายรายก็ใช้ขนาดนี้เช่นกัน อย่างไรก็ตาม เฟรมจัมโบ้ไม่ได้เป็นส่วนหนึ่งของ มาตรฐาน IEEE 802.3 Ethernet อย่างเป็นทางการ

เฟรมจัมโบ้มีศักยภาพในการลดโอเวอร์เฮดและรอบการทำงานของ CPU ^{[ 5 ]}และมีผลดีต่อประสิทธิภาพ TCP แบบ end-to-end ^{[ 6 ]}การมีเฟรมจัมโบ้อาจส่งผลเสียต่อความหน่วงของเครือข่าย โดยเฉพาะอย่างยิ่งบนลิงก์ที่มีแบนด์วิดท์ต่ำ ขนาดเฟรมที่ใช้โดยการเชื่อมต่อแบบ end-to-end มักจะถูกจำกัดด้วยขนาดเฟรมต่ำสุดในลิงก์ระดับกลาง802.5 Token Ring สามารถรองรับเฟรมที่มี MTU 4464 ไบต์FDDI สามารถส่ง เฟรมขนาด 4352 ไบต์ATM 9180 ไบต์ และ802.11สามารถส่งเฟรมขนาด 7935 ไบต์ มาตรฐาน IEEE 802.3 Ethernet เดิมกำหนดให้รองรับเฟรม MTU 1500 ไบต์ ขนาดเฟรมทั้งหมด 1518 ไบต์ (1522 ไบต์เมื่อใช้ แท็ก VLAN / QoS ของ IEEE 802.1Q ที่เป็นตัวเลือก ) การอัปเดตมาตรฐาน IEEE 802.3as ได้คงไว้ซึ่งส่วนหัว ส่วนท้าย และการห่อหุ้มข้อมูลทั่วไปหลายรายการ โดยการสร้างแนวคิดของซองจดหมายที่สามารถรวมส่วนหัวและส่วนท้ายได้มากถึง 482 ไบต์ และเฟรมอีเธอร์เน็ตที่ใหญ่ที่สุดที่รองรับโดย IEEE 802.3 ก็มีขนาด 2000 ไบต์

การใช้ขนาดเพย์โหลด 9000 ไบต์เป็นขนาดที่ต้องการสำหรับจัมโบ้เฟรมเกิดขึ้นจากการอภิปรายภายในทีมวิศวกรรมร่วมของInternet2และเครือข่ายรัฐบาลกลางของสหรัฐอเมริกา^{[ 7 ]}ข้อแนะนำของพวกเขาได้รับการนำไปใช้โดยเครือข่ายวิจัยและการศึกษาแห่งชาติอื่นๆ ทั้งหมด ผู้ผลิตจึงได้นำขนาด 9000 ไบต์มาใช้เป็นขนาด MTU มาตรฐาน โดยมีขนาดจัมโบ้เฟรมทั้งหมดระหว่าง 9014 ถึง 9022 ไบต์เมื่อรวมส่วนหัวอีเธอร์เน็ต^{[ 8 ]}อุปกรณ์อีเธอร์เน็ตส่วนใหญ่สามารถรองรับจัมโบ้เฟรมได้ถึง 9216 ไบต์^{[ 9 ]}

IEEE 802.1AB -2009 และIEEE 802.3bc -2009 ได้เพิ่ม การค้นหา LLDPลงใน Ethernet มาตรฐานสำหรับความยาวเฟรมสูงสุด ( TLV subtype 4) ^{[ 10 ]}ซึ่งช่วยให้สามารถตรวจจับความยาวเฟรมบนพอร์ตโดยใช้ฟิลด์สองอ็อกเท็ต ตาม IEEE 802.3-2015 ค่าที่อนุญาตคือ1518 (เฉพาะเฟรมพื้นฐาน), 1522 (เฟรมที่มีแท็ก 802.1Q) และ2000 (เฟรมที่มีแท็กหลายตัวและเฟรมซองจดหมาย) ^{[ 11 ]}

ข้อผิดพลาดในเฟรมจัมโบ้มีแนวโน้มที่จะไม่ถูกตรวจพบโดย การตรวจจับข้อผิดพลาด CRC32 แบบง่าย ของอีเธอร์เน็ต และการตรวจสอบผลรวมแบบบวกอย่างง่ายของUDPและTCPเนื่องจากเมื่อขนาดแพ็กเก็ตเพิ่มขึ้น โอกาสที่ข้อผิดพลาดหลายรายการจะหักล้างกันเองก็มีมากขึ้น^{[ a ]}

แนวทางหนึ่งของ IETF สำหรับการนำเฟรมจัมโบ้มาใช้คือการหลีกเลี่ยงการลดความสมบูรณ์ของข้อมูลในหน่วยข้อมูลบริการ (Service Data Unit หรือ CRC) โดยการทำ CRC เพิ่มเติมที่เลเยอร์โปรโตคอลเครือข่ายถัดไปเหนืออีเธอร์เน็ต โปรโตคอล การส่งข้อมูล แบบ Stream Control Transmission Protocol (SCTP) (RFC 4960) และ iSCSI (RFC 7143) ใช้พหุนาม CRC ของ Castagnoliพหุนาม Castagnoli 0x1EDC6F41 ให้ค่าHamming distance (HD) เท่ากับ 6 สำหรับขนาดข้อมูลเกิน MTU ของอีเธอร์เน็ต (ถึงความยาวคำข้อมูล 16,360 บิต) และ HD เท่ากับ 4 สำหรับขนาดข้อมูล 114,663 บิต ซึ่งมากกว่าความยาวของ MTU ของอีเธอร์เน็ตถึง 9 เท่า これにより、MTU のフロットント ...��実行されます。^{[ 13 ]}การสนับสนุนพหุนาม CRC ของ Castagnoli ภายในการขนส่งอเนกประสงค์ที่ออกแบบมาเพื่อจัดการชิ้นส่วนข้อมูล และภายในการขนส่ง TCP ที่ออกแบบมาเพื่อขนส่งข้อมูล SCSI ทั้งสองอย่างให้ผลลัพธ์อัตราการตรวจจับข้อผิดพลาดที่ดีขึ้น แม้ว่าจะใช้เฟรมจัมโบ้ซึ่งการเพิ่ม MTU ของอีเธอร์เน็ตจะส่งผลให้การตรวจจับข้อผิดพลาดลดลงอย่างมากก็ตาม

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

เครือข่ายที่มีอุปกรณ์ที่กำหนดค่าสำหรับเฟรมจัมโบ้และอุปกรณ์ที่ไม่ได้กำหนดค่าสำหรับเฟรมจัมโบ้อาจมีปัญหาด้านประสิทธิภาพ^{[ 14 ]}

เฟรมจัมโบ้สามารถเพิ่มประสิทธิภาพของอีเธอร์เน็ตและการประมวลผลเครือข่ายในโฮสต์ได้โดยการลดโอเวอร์เฮดของโปรโตคอลดังแสดงในตัวอย่างต่อไปนี้ด้วย TCP บนIPv4โอเวอร์เฮดการประมวลผลของโฮสต์อาจลดลงตามอัตราส่วนของขนาดเพย์โหลด (ปรับปรุงได้ประมาณหกเท่าในตัวอย่างนี้) ว่าจะมีนัยสำคัญหรือไม่นั้นขึ้นอยู่กับวิธีการประมวลผลแพ็กเก็ตในโฮสต์ โฮสต์ที่ใช้ เอ็นจิ้นออฟ โหลด TCPของตัวควบคุมอินเทอร์เฟซเครือข่ายซึ่งมีโอเวอร์เฮดลดลงอยู่แล้วจะได้รับประโยชน์น้อยกว่าโฮสต์ที่ประมวลผลเฟรมด้วย CPU ประสิทธิภาพการรับส่งข้อมูลตามแบนด์วิดท์สามารถเพิ่มขึ้นได้ 4.4% ^{[ A ]}

ความสามารถในการปรับขนาดสัมพัทธ์ของปริมาณข้อมูลเครือข่ายตามฟังก์ชันของอัตราการถ่ายโอนแพ็กเก็ตมีความสัมพันธ์กันในลักษณะที่ซับซ้อนกับขนาดของเพย์โหลดต่อแพ็กเก็ต^{[ 17 ]}ในทางทฤษฎี เมื่ออัตราบิตของสายส่งเพิ่มขึ้น ขนาดของเพย์โหลดแพ็กเก็ตควรเพิ่มขึ้นตามสัดส่วนโดยตรงเพื่อรักษาพารามิเตอร์เวลาที่เทียบเท่ากัน อย่างไรก็ตาม สิ่งนี้หมายถึงการปรับขนาดของวงจรตรรกะระดับกลางจำนวนมากตามเส้นทางเครือข่ายเพื่อรองรับขนาดเฟรมสูงสุดที่ต้องการ

เฟรม Baby giantหรือBaby jumboคือเฟรม Ethernet ที่มีขนาดใหญ่กว่าที่มาตรฐาน IEEE Ethernet กำหนดไว้เพียงเล็กน้อย^{[ 2 ]}ตัวอย่างเช่น เฟรม Baby giant จำเป็นสำหรับ IP/ MPLSผ่าน Ethernet เพื่อส่งมอบบริการ Ethernet ด้วยเพย์โหลดมาตรฐาน 1500 ไบต์ การใช้งานส่วนใหญ่จะกำหนดให้เฟรมผู้ใช้ที่ไม่ใช่จัมโบ้ต้องถูกห่อหุ้มลงในรูปแบบเฟรม MPLS ซึ่งในทางกลับกันอาจถูกห่อหุ้มลงในรูปแบบเฟรม Ethernet ที่เหมาะสมด้วย ค่า EtherType 0x8847 และ 0x8848 ^{[ 18 ]}ค่าใช้จ่ายที่เพิ่มขึ้นของส่วนหัว MPLS และ Ethernet เพิ่มเติมหมายความว่าจำเป็นต้องรองรับเฟรมที่มีขนาดสูงสุด 1600 ไบต์ในเครือข่ายCarrier Ethernet ^{[ 19 ]}

เฟรมจัมโบ้สำหรับPPPoEได้รับการกำหนดไว้ใน RFC 4638 โดยมีวัตถุประสงค์เพื่อลบข้อจำกัดเดิมที่ 1492 ไบต์ (เดิมกำหนดไว้เนื่องจาก PPP ต้องการโอเวอร์เฮดเพิ่มอีก 8 ไบต์) เพื่อให้ Ethernet ขนาด 1500 ไบต์ปกติสามารถทำงานได้โดยไม่ต้องมีการแบ่งส่วน แท็ก "PPP-Max-Payload" ยังคงสามารถรองรับเฟรมจัมโบ้ขนาดใหญ่ที่ไม่ใช่เบบี้ได้^{[ 20 ]}

เฟรมจัมโบ้ขนาดใหญ่ (SJF) คือเฟรมที่มี ขนาด เพย์โหลดมากกว่า 9,000 ไบต์^{[ 21 ]}เนื่องจากการเพิ่ม MTU ของเส้นทางเครือข่ายวิจัยและการศึกษาระดับชาติประสิทธิภาพสูงจาก 1,500 ไบต์เป็น 9,000 ไบต์หรือประมาณนั้นค่อนข้างยากและใช้เวลานาน จึงกำลังพิจารณาการเพิ่มขึ้นในภายหลัง ซึ่งอาจสูงถึง 64,000 ไบต์ ปัจจัยหลักที่เกี่ยวข้องคือการเพิ่มขนาดบัฟเฟอร์หน่วยความจำที่ใช้ได้ในกลไกการคงอยู่ของข้อมูลทุกกลไกที่อยู่ระหว่างเส้นทาง อีกปัจจัยสำคัญที่ต้องพิจารณาคือการลดประสิทธิภาพของ CRC32 ในการตรวจจับข้อผิดพลาดภายในเฟรมขนาดใหญ่ขึ้น

ฟิลด์Total LengthของIPv4และ ฟิลด์ Payload LengthของIPv6มีขนาด 16 บิตเท่ากัน ทำให้สามารถส่งข้อมูลได้สูงสุดถึง65,535ไบต์ตัว เลือก Jumbo Payloadของ IPv6 อนุญาตให้ส่งข้อมูลได้สูงสุดถึง 4  GiB ( ^2³² - 1 ไบต์) อย่างไรก็ตาม ขีดจำกัดทางทฤษฎีเหล่านี้สำหรับ MTU ของ โปรโตคอลอินเทอร์เน็ต (IP) จะเกิดขึ้นได้ก็ต่อเมื่อเครือข่ายมีโครงสร้างพื้นฐานระดับลิงก์เลเยอร์ที่เหมาะสมเท่านั้น

การถ่ายโอนข้อมูลขนาดใหญ่สำหรับการส่งและการรับข้อมูลขนาดใหญ่ช่วยลดภาระการประมวลผลต่อเฟรม ทำให้ภาระ CPU แทบจะไม่ขึ้นอยู่กับขนาดเฟรมเลย นอกจากนี้ยังเป็นอีกวิธีหนึ่งในการกำจัดโอเวอร์เฮดต่อแพ็กเก็ตที่เฟรมจัมโบ้ได้รับการออกแบบมาเพื่อลด^{[ 22 ]}เฟรมจัมโบ้ยังคงมีประโยชน์ในแง่ของแบนด์วิดท์ เนื่องจากช่วยลดปริมาณแบนด์วิดท์ที่ใช้สำหรับโอเวอร์เฮดที่ไม่ใช่ข้อมูล

• กรอบรูปขนาดใหญ่ – ควรใช้ที่ไหนบ้าง?
• เฟรมขนาดใหญ่? ใช่แล้ว!โดย เซลินา โล, อัลทีออน เน็ตเวิร์กส์, 23 กุมภาพันธ์ 1998 ใน NetworkWorld
• การเพิ่มค่า MTU ของอินเทอร์เน็ต
• คณะทำงานขยายเฟรม IEEE 802.3as
• รหัส Cyclic Redundancy 32 บิตสำหรับแอปพลิเคชันอินเทอร์เน็ต
• สิ่งที่ควรรู้: เฟรมจัมโบ้ในเครือข่ายขนาดเล็ก
• เฟรมขนาดใหญ่ในวิกิของ Arch Linux