什么是MTU
根據(jù)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，即是一個(gè)connection上最大允許的packet/frame大小。我們知道，交換機(jī)(switch)和路由(router)的CPU都是按幀(frame)來處理信息。那么每個(gè)frame越大，理論上我們部署的網(wǎng)絡(luò)中的router和switch總體效率便會(huì)得到提高。
Ethernet Frame
拿Ethernet Frame作例子：
每個(gè)frame的header大小是固定的(frame delimiter之后的：MAC destination + MAC source + 802.1Q tag + length) = 18 bytes。802.1Q協(xié)議，也被稱為Dot1q，本質(zhì)上是用來在IEEE 802.3 Ethernet network上支持VLAN的，這里不贅述。由于VLAN的廣泛使用，我們這里將其考慮進(jìn)來。
由于header+preamble的大小固定，很顯然每個(gè)frame/packet越小，收發(fā)的網(wǎng)絡(luò)設(shè)備(switch/router)CPU花費(fèi)在組合和拆分信息(收到frames時(shí)組合，發(fā)送信息時(shí)拆分)的時(shí)間和資源就越多，舉一個(gè)極端情況，如果每幀payload只有1 byte，那我們不需要計(jì)算也能直觀感覺到，這個(gè)網(wǎng)絡(luò)的信息處理效率（吞吐量 / throughput）低得莫名其妙。從信息有效的比率的角度來說，F(xiàn)ixed Header + Payload = Unit Size，如果允許的Unit Size越大，那么每個(gè)frame的payload也就越大，所以所有的frames的信息里，fixed header占的比例就越小，網(wǎng)絡(luò)設(shè)備就更多地在處理有效信息——payload。
Why Jumbo Frame
根據(jù)IEEE 802.3，現(xiàn)在IEEE規(guī)定的Ethernet MTU是1500個(gè)字節(jié)。滿打滿算，1500個(gè)字節(jié)在payload上用完，1500/1542 （1500+26+4+12=1544）= 97.28%是這個(gè)限制下最高的利用效率（假設(shè)使用802.1Q VLAN tagging ）。隨著網(wǎng)絡(luò)的日漸發(fā)達(dá)，對(duì)性能的要求愈加苛刻，人們不滿足于1500MTU，所以擁有9000字節(jié)payload的Jumbo Frame便應(yīng)運(yùn)而生。
Jumbo Frame并不是什么新鮮的東西，Jumbo Frame起源于 Alteon WebSystems 推出的ACEnic Gigabit Ethernet adapters?，F(xiàn)在的Jumbo Frame是9000MTU這一規(guī)范，也是源自于此。所以并不是說固定9000字節(jié)，不同的網(wǎng)絡(luò)（設(shè)備）供應(yīng)商可能提供不同的選擇。
Jumbo這個(gè)詞本意就是“巨大，特大”，所以一般frame size非標(biāo)準(zhǔn)（1500MTU）的frame規(guī)制，我們都可以稱其為Jumbo Frame。
說到這里，我們可能會(huì)有些迷惑的地方在于，1500MTU 或者9000MTU，到底是指的payload size還是整個(gè)frame的大小呢？這真的是一個(gè)case by case的問題，各個(gè)網(wǎng)絡(luò)設(shè)備供應(yīng)商可能從未統(tǒng)一過。比如Cisco IOS 1500可能跟Juniper 1518一樣，很明顯一個(gè)標(biāo)明的MTU沒包含header一個(gè)包含了header，又比如AWS的Jumbo Frame是指的整個(gè)packet size 9000，而AWS又稱這個(gè)standard為9001MTU。
Jumbo Frame的應(yīng)用
使用上，比較重要的一點(diǎn)是，Jumbo Frame在一套系統(tǒng)中的應(yīng)用，必須是end-to-end的。因?yàn)橐坏┲虚g有任何一個(gè)hop，任何一環(huán)沒能支持同一MTU的Jumbo Frame，那么那一個(gè)部分就可能成為整個(gè)系統(tǒng)的網(wǎng)絡(luò)瓶頸——木桶原理，最慢的一環(huán)決定了整體的速度。
現(xiàn)在的主流廠商基本上都支持Jumbo Frame。比如說Juniper Networks的SRX Series Services Gateway都支持最多9192字節(jié)的Jumbo Frame，當(dāng)然這是整個(gè)packet size，payload部分仍是9000字節(jié)。
IP Fragmentation和Path MTU Discovery
IP Fragmentation，即是一個(gè)支持IP協(xié)議的link（比如兩個(gè)router）MTU大小小于packet size時(shí)，該IP packet被切分傳送。然后link的接收方則會(huì)將MTU的packet重新組合。比如說router A開始發(fā)送Jumbo Frame，而下一個(gè)hop的router B仍舊認(rèn)為這個(gè)link的MTU是1500，那么這里就可能會(huì)發(fā)生IP Fragmentation，否則router B就只能丟掉不合標(biāo)準(zhǔn)的來自于A的packets。
Path MTU Discovery則是基于ICMP的，用于確定一個(gè)link的MTU的技術(shù)。如果要支持Jumbo Frame，一個(gè)網(wǎng)絡(luò)勢(shì)必要支持Path MTU Discovery，否則該網(wǎng)絡(luò)中的設(shè)備會(huì)缺乏調(diào)整MTU的能力。
Jumbo Frame的問題
Jumbo Frame之所以沒有成為現(xiàn)今IEEE的正式標(biāo)準(zhǔn)，恐怕是因?yàn)樗哂械囊恍﹩栴}。
一個(gè)問題便來自于上面所說的Path MTU Discovery。眾所周知，ICMP有著很多安全隱患（比如典型的DoS--ICMP flood），因而許多網(wǎng)絡(luò)設(shè)備供應(yīng)商/ISP/用戶自己會(huì)關(guān)掉/block掉整個(gè)ICMP，這便會(huì)限制Jumbo Frame的使用。
另一個(gè)問題，如上所述，Jumbo Frame要發(fā)揮價(jià)值，必須要一個(gè)網(wǎng)絡(luò)end-to-end的支持并開啟Jumbo Frame，這一點(diǎn)，在很復(fù)雜的網(wǎng)絡(luò)環(huán)境中，不論是開發(fā)角度還是實(shí)踐角度，都是很難的。當(dāng)然有一些特殊的網(wǎng)絡(luò)環(huán)境很適合使用，比如說AWS的Direct Connect——為用戶提供AWS到自己的onprem網(wǎng)絡(luò)（比如公司/自己的datacenter等等）提供一條不經(jīng)過Internet基于802.1q VLAN的專屬通路。
現(xiàn)代的NIC有著非常豐富和強(qiáng)大的處理功能。比如一個(gè)有著64k buffer的NIC，它并不會(huì)太在乎一個(gè)個(gè)1500字節(jié)的packet，而是先把現(xiàn)有的packets塞進(jìn)buffer，然后便可以根據(jù)自己的處理能力高效的處理buffer，而非frame by frame地處理數(shù)據(jù)。
總而言之，使用Jumbo Frame，聽起來很美好，能有效提高網(wǎng)絡(luò)吞吐，可是具體的使用，需要考慮具體網(wǎng)絡(luò)環(huán)境和所涵蓋的所有網(wǎng)絡(luò)設(shè)備，權(quán)衡之下才能知道使用它是一個(gè)能夠有效改進(jìn)網(wǎng)絡(luò)的手段，還是弊大于利的多余操作。
