Jumbo Frame 與 MTU
什麼是MTU
根據AWS EC2的文件：
The maximum transmission unit (MTU) of a network connection is the size, in bytes, of the largest permissible packet that can be passed over the connection. The larger the MTU of a connection, the more data that can be passed in a single packet. Ethernet packets consist of the frame, or the actual data you are sending, and the network overhead information that surrounds it.
MTU，即是一個connection上最大允許的packet/frame大小。我們知道，交換機(switch)和路由(router)的CPU都是按幀(frame)來處理資訊。那麼每個frame越大，理論上我們部署的網路中的router和switch總體效率便會得到提高。
Ethernet Frame
拿Ethernet Frame作例子：
802.3 Ethernet packet and frame structure - wikipedia
每個frame的header大小是固定的(frame delimiter之後的：MAC destination + MAC source + 802.1Q tag + length) = 18 bytes。802.1Q協議，也被稱為Dot1q，本質上是用來在IEEE 802.3 Ethernet network上支援VLAN的，這裡不贅述。由於VLAN的廣泛使用，我們這裡將其考慮進來。
由於header+preamble的大小固定，很顯然每個frame/packet越小，收發的網路裝置(switch/router)CPU花費在組合和拆分資訊(收到frames時組合，傳送資訊時拆分)的時間和資源就越多，舉一個極端情況，如果每幀payload只有1 byte，那我們不需要計算也能直觀感覺到，這個網路的資訊處理效率（吞吐量 / throughput）低得莫名其妙。從資訊有效的比率的角度來說，Fixed Header + Payload = Unit Size，如果允許的Unit Size越大，那麼每個frame的payload也就越大，所以所有的frames的資訊裡，fixed header佔的比例就越小，網路裝置就更多地在處理有效資訊——payload。
直觀比較
Why Jumbo Frame
根據 ofollow,noindex">IEEE 802.3 ，現在IEEE規定的Ethernet MTU是1500個位元組。滿打滿算，1500個位元組在payload上用完，1500/1542 （1500+26+4+12=1544）= 97.28%是這個限制下最高的利用效率（假設使用802.1Q VLAN tagging ）。隨著網路的日漸發達，對效能的要求愈加苛刻，人們不滿足於1500MTU，所以擁有9000位元組payload的Jumbo Frame便應運而生。
Jumbo Frame並不是什麼新鮮的東西，Jumbo Frame起源於 Alteon WebSystems 推出的ACEnic Gigabit Ethernet adapters。現在的Jumbo Frame是9000MTU這一規範，也是源自於此。所以並不是說固定9000位元組，不同的網路（裝置）供應商可能提供不同的選擇。
超9000MTU!
Jumbo這個詞本意就是“巨大，特大”，所以一般frame size非標準（1500MTU）的frame規制，我們都可以稱其為Jumbo Frame。
說到這裡，我們可能會有些迷惑的地方在於，1500MTU 或者9000MTU，到底是指的payload size還是整個frame的大小呢？這真的是一個case by case的問題，各個網路裝置供應商可能從未統一過。比如Cisco IOS 1500可能跟Juniper 1518一樣，很明顯一個標明的MTU沒包含header一個包含了header，又比如AWS的Jumbo Frame是指的整個packet size 9000，而AWS又稱這個standard為9001MTU。
Jumbo Frame的應用
使用上，比較重要的一點是，Jumbo Frame在一套系統中的應用，必須是end-to-end的。因為一旦中間有任何一個hop，任何一環沒能支援同一MTU的Jumbo Frame，那麼那一個部分就可能成為整個系統的網路瓶頸——木桶原理，最慢的一環決定了整體的速度。
現在的主流廠商基本上都支援Jumbo Frame。比如說Juniper Networks的 SRX Series Services Gateway 都支援最多9192位元組的Jumbo Frame，當然這是整個packet size，payload部分仍是9000位元組。
IP Fragmentation和Path MTU Discovery
IP Fragmentation，即是一個支援IP協議的link（比如兩個router）MTU大小小於packet size時，該IP packet被切分傳送。然後link的接收方則會將MTU的packet重新組合。比如說router A開始傳送Jumbo Frame，而下一個hop的router B仍舊認為這個link的MTU是1500，那麼這裡就可能會發生IP Fragmentation，否則router B就只能丟掉不合標準的來自於A的packets。
Path MTU Discovery則是基於ICMP的，用於確定一個link的MTU的技術。如果要支援Jumbo Frame，一個網路勢必要支援Path MTU Discovery，否則該網路中的裝置會缺乏調整MTU的能力。
Jumbo Frame的問題
Jumbo Frame之所以沒有成為現今IEEE的正式標準，恐怕是因為它所具有的一些問題。
一個問題便來自於上面所說的Path MTU Discovery。眾所周知，ICMP有著很多安全隱患（比如典型的DoS--ICMP flood），因而許多網路裝置供應商/ISP/使用者自己會關掉/block掉整個ICMP，這便會限制Jumbo Frame的使用。
另一個問題，如上所述，Jumbo Frame要發揮價值，必須要一個網路end-to-end的支援並開啟Jumbo Frame，這一點，在很複雜的網路環境中，不論是開發角度還是實踐角度，都是很難的。當然有一些特殊的網路環境很適合使用，比如說AWS的 Direct Connect ——為使用者提供AWS到自己的onprem網路（比如公司/自己的datacenter等等）提供一條不經過Internet基於802.1q VLAN的專屬通路。
現代的NIC有著非常豐富和強大的處理功能。比如一個有著64k buffer的NIC，它並不會太在乎一個個1500位元組的packet，而是先把現有的packets塞進buffer，然後便可以根據自己的處理能力高效的處理buffer，而非frame by frame地處理資料。
總而言之，使用Jumbo Frame，聽起來很美好，能有效提高網路吞吐，可是具體的使用，需要考慮具體網路環境和所涵蓋的所有網路裝置，權衡之下才能知道使用它是一個能夠有效改進網路的手段，還是弊大於利的多餘操作。