最大传输单元MTU以及MTU优化

DomDomm

最大传输单元 (MTU)

不同的 数据链路层，有不同的 MTU。
如:
以太网路 (Ethernet) 的 1500 个位元组，
IEEE 802.3/802.2 的 1492 个位元组，
光纤分散式数据介面 (FDDI) 的 4352 个位元组…。

以 以太网路 (Etherner) 为例:


一个 以太网路 帧(Frame)，最大的长度为 1518 位元组 (octet)，
去掉表头与尾端数据后，载荷的最大资料长度则为 1500 octet，
且资料最小长度需为 46 octet，不足的话就用 填充位元 (padding) 填满至 46 为止。

相关文章&视频推荐：
简短概述Linux并发控制与原子操作
Linux容器封装——docker基础
详细讲解，Linux内核——文件系统（建议收藏）
Linux内核5.0版本五大模块及内核书籍推荐
全网最细的CMake教程！(强烈建议收藏)
<hr/>使用指令:
netstat -i

可显示系统网路介面信息(含 MTU)
IP 分段
(IP Fragmentation)

网络层的 IPv4 与 IPv6，
其封包大小上限，分别为 65535 与 65575 位元组 (octet)，
并提供较大的封包选项 — — 巨型封包 (jumbograms)。
远远超出了许多数据链路层的 帧大小（MTU）!

IP 分段 (IP Fragmentation) 即是其中一种解法:

IP 会将封包切割成多个较小的 (小于 MTU) 片段 (fragment)，使其能透过数据链路层传输 ，
目的端接收完所有片段后，再将片段 (fragment) 进行重组。

分段 (fragmentation)，可能由传输路径中的任何一台路由器来做 (含来源主机)，
且被分段的封包 — — 片段 (fragment) 可能经由不同路由方式，
只要最终达到相同的目的地即可。
(IPv6 只有来源端可以做分段)

将 IP 数据包 (IP Datagram) 分段的主机或路由器，
会复制必要栏位到各个片段中，
并更改 标志、片段偏移量、(封包)总长度，与重新计算各个分段的检验和。
(IP 检验和，不含虚拟表头)

最后，目的端接收完所有片段后，再将片段 (fragment) 进行重组：


IP Datagram 格式
将在未来讨论 IP 协定进一步说明。

【文章福利】小编推荐自己的Linux内核源码交流群:【869634926】整理了一些个人觉得比较好的Linux、C/++等学习书籍、视频资料分享给大家，有需要的可以自行添加哦！！！前100名可进群领取，并额外赠送一份价值600的内核资料包（含视频教程、电子书、实战项目及代码)！

学习直通车：Linux内核源码/内存调优/文件系统/进程管理/设备驱动/网络协议栈
<hr/>Path MTU Discovery

如果 IP Fragmentation 任一片段遗失、毁损呢?

答案是: 目的端将无法重组这个封包。

更重要的是:

网路层的 IP 并不会处理重送

这对有重送机制的传输层 (Ex: TCP)，降低了传输效率 (无法只重送一个 片段)；
对没有重送机制的传输层 (Ex: UDP)，增加了资料的遗失率。

Path MTU Discovery 技术，有效的避免 IP Fragmentation:

找出 来源 与 目的端路径中，
所有数据连接层的 最小 MTU。
(通常，为以太网路的 1500 octet)

许多可靠的传输层 (如: TCP)，会以此值做为参考，
调整 最大区段长度 (Maximum Segment Size, MSS)。

最简单的算法:
MSS = MTU - 20 octet (TCP 固定表头) - 20 octet (IP 固定表头)
或 其他动态调整演算法，
常见的 MSS 有 1460、1400、1380…。

而没有此机制的传输层 (如: UDP)，则是选择适当的 数据报 (Datagram) 大小，
确保传输的 IP 封包，会小于 IPv4 的最小可重组缓衝区大小 (576 octet)，避免 IP Fragmentation。
关于网络编程中MTU、TCP、UDP优化配置的一些总结

首先要看TCP/IP协议，涉及到四层：链路层，网络层，传输层，应用层。 　　
其中以太网（Ethernet）的数据帧在链路层 　　
IP包在网络层 　　
TCP或UDP包在传输层 　　
TCP或UDP中的数据（Data)在应用层 　　
它们的关系是 数据帧｛IP包｛TCP或UDP包｛Data｝｝｝ 　
在应用程序中我们用到的Data的长度最大是多少，直接取决于底层的限制。
我们从下到上分析一下： 　　
1.在链路层，由以太网的物理特性决定了数据帧的长度为（46＋18）－（1500＋18），其中的18是数据帧的头和尾，也就是说数据帧的内容最大为1500（不包括帧头和帧尾）
2.在网络层，因为IP包的首部要占用20字节，所以这的MTU为1500－20＝1480；　
3.在传输层，对于UDP包的首部要占用8字节，所以这的MTU为1480－8＝1472； 　　
所以，在应用层，你的Data最大长度为1472。 （当我们的UDP包中的数据多于MTU(1472)时，发送方的IP层需要分片fragmentation进行传输，而在接收方IP层则需要进行数据报重组，由于UDP是不可靠的传输协议，如果分片丢失导致重组失败，将导致UDP数据包被丢弃）。 　　
从上面的分析来看，在普通的局域网环境下，UDP的数据最大为1472字节最好（避免分片重组）。 　　
但在网络编程中，Internet中的路由器可能有设置成不同的值（小于默认值），Internet上的标准MTU值为576，所以Internet的UDP编程时数据长度最好在576－20－8＝548字节以内。
MTU对我们的UDP编程很重要，那如何查看路由的MTU值呢？ 　　
对于windows OS: ping -f -l 　　如：ping -f -l 1472 192.168.0.1 　　
如果提示：Packets needs to be fragmented but DF set. 　　则表明MTU小于1500，不断改小data_length值，可以最终测算出gateway的MTU值； 　　
对于linux OS: ping -c -M do -s 　　如： ping -c 1 -M do -s 1472 192.168.0.1 　　
如果提示 Frag needed and DF set…… 　　则表明MTU小于1500，可以再测以推算gateway的MTU。
原理：ping程序使用ICMP报文，ICMP报文首部占8字节，IP数据报首部占20字节，因此在数据大小基础上加上28字节为MTU值。
IP数据包的最大长度是64K字节(65535)，因为在IP包头中用2个字节描述报文长度，2个字节所能表达的最大数字就是65535。  

由于IP协议提供为上层协议分割和重组报文的功能，因此传输层协议的数据包长度原则上来说没有限制。实际上限制还是有的，因为IP包的标识字段终究不可能无限长，按照IPv4，好像上限应该是4G(64K*64K)。依靠这种机制，TCP包头中就没有“包长度”字段，而完全依靠IP层去处理分帧。这就是为什么TCP常常被称作一种“流协议”的原因，开发者在使用TCP服务的时候，不必去关心数据包的大小，只需讲SOCKET看作一条数据流的入口，往里面放数据就是了，TCP协议本身会进行拥塞/流量控制。  

UDP则与TCP不同，UDP包头内有总长度字段，同样为两个字节，因此UDP数据包的总长度被限制为65535，这样恰好可以放进一个IP包内，使得UDP/IP协议栈的实现非常简单和高效。65535再减去UDP头本身所占据的8个字节，UDP服务中的最大有效载荷长度仅为65527。这个值也就是你在调用getsockopt()时指定SO_MAX_MSG_SIZE所得到返回值，任何使用SOCK_DGRAM属性的socket，一次send的数据都不能超过这个值，否则必然得到一个错误。  

那么，IP包提交给下层协议时将会得到怎样的处理呢？这就取决于数据链路层协议了，一般的数据链路层协议都会负责将IP包分割成更小的帧，然后在目的端重组它。在EtherNet上，数据链路帧的大小如以上几位大侠所言。而如果是IP   over   ATM，则IP包将被切分成一个一个的ATM   Cell，大小为53字节。
一些典型的MTU值：
网络：                                    MTU字节
超通道                              　　  65535
16Mb/s信息令牌环（IBM）           　　　　17914
4Mb/s令牌环（IEEE802.5）         　　　　 4464
FDDI                              　　　  4352
以太网                              　　  1500
IEEE802.3/802.2                     　　  1492
X.25                               　　   576
点对点（低时延）                      　  296
    路径MTU：如果两台主机之间的通信要通过多个网络，那么每个网络的链路层就可能有不同的MTU。重要的不是两台主机所在网络的MTU的值，重要的是两台通信主机路径中的最小MTU。它被称作路径MTU。
Tcp传输中的nagle算法
　　TCP/IP协议中，无论发送多少数据，总是要在数据前面加上协议头，同时，对方接收到数据，也需要发送ACK表示确认。为了尽可能的利用网络带宽，TCP总是希望尽可能的发送足够大的数据。（一个连接会设置MSS参数，因此，TCP/IP希望每次都能够以MSS尺寸的数据块来发送数据）。Nagle算法就是为了尽可能发送大块数据，避免网络中充斥着许多小数据块。
      Nagle算法的基本定义是任意时刻，最多只能有一个未被确认的小段。 所谓“小段”，指的是小于MSS尺寸的数据块，所谓“未被确认”，是指一个数据块发送出去后，没有收到对方发送的ACK确认该数据已收到。
1. Nagle算法的规则：
      （1）如果包长度达到MSS，则允许发送；
      （2）如果该包含有FIN，则允许发送；
      （3）设置了TCP_NODELAY选项，则允许发送；
      （4）未设置TCP_CORK选项时，若所有发出去的小数据包（包长度小于MSS）均被确认，则允许发送；
      （5）上述条件都未满足，但发生了超时（一般为200ms），则立即发送。
     Nagle算法只允许一个未被ACK的包存在于网络，它并不管包的大小，因此它事实上就是一个扩展的停-等协议，只不过它是基于包停-等的，而不是基于字节停-等的。Nagle算法完全由TCP协议的ACK机制决定，这会带来一些问题，比如如果对端ACK回复很快的话，Nagle事实上不会拼接太多的数据包，虽然避免了网络拥塞，网络总体的利用率依然很低。
      Nagle算法是silly window syndrome(SWS)预防算法的一个半集。SWS算法预防发送少量的数据，Nagle算法是其在发送方的实现，而接收方要做的时不要通告缓冲空间的很小增长，不通知小窗口，除非缓冲区空间有显著的增长。这里显著的增长定义为完全大小的段（MSS）或增长到大于最大窗口的一半。
注意：BSD的实现是允许在空闲链接上发送大的写操作剩下的最后的小段，也就是说，当超过1个MSS数据发送时，内核先依次发送完n个MSS的数据包，然后再发送尾部的小数据包，其间不再延时等待。（假设网络不阻塞且接收窗口足够大）。
     举个例子，一开始client端调用socket的write操作将一个int型数据（称为A块）写入到网络中，由于此时连接是空闲的（也就是说还没有未被确认的小段），因此这个int型数据会被马上发送到server端，接着，client端又调用write操作写入‘\r\n’（简称B块），这个时候，A块的ACK没有返回，所以可以认为已经存在了一个未被确认的小段，所以B块没有立即被发送，一直等待A块的ACK收到（大概40ms之后），B块才被发送。整个过程如图所示：
      这里还隐藏了一个问题，就是A块数据的ACK为什么40ms之后才收到？这是因为TCP/IP中不仅仅有nagle算法，还有一个TCP确认延迟机制 。当Server端收到数据之后，它并不会马上向client端发送ACK，而是会将ACK的发送延迟一段时间（假设为t），它希望在t时间内server端会向client端发送应答数据，这样ACK就能够和应答数据一起发送，就像是应答数据捎带着ACK过去。在我之前的时间中，t大概就是40ms。这就解释了为什么'\r\n'（B块）总是在A块之后40ms才发出。
       当然，TCP确认延迟40ms并不是一直不变的，TCP连接的延迟确认时间一般初始化为最小值40ms，随后根据连接的重传超时时间（RTO）、上次收到数据包与本次接收数据包的时间间隔等参数进行不断调整。另外可以通过设置TCP_QUICKACK选项来取消确认延迟。
2. TCP_NODELAY 选项
      默认情况下，发送数据采用Negale 算法。这样虽然提高了网络吞吐量，但是实时性却降低了，在一些交互性很强的应用程序来说是不允许的，使用TCP_NODELAY选项可以禁止Negale 算法。
      此时，应用程序向内核递交的每个数据包都会立即发送出去。需要注意的是，虽然禁止了Negale 算法，但网络的传输仍然受到TCP确认延迟机制的影响。
3. TCP_CORK 选项
     所谓的CORK就是塞子的意思，形象地理解就是用CORK将连接塞住，使得数据先不发出去，等到拔去塞子后再发出去。设置该选项后，内核会尽力把小数据包拼接成一个大的数据包（一个MTU）再发送出去，当然若一定时间后（一般为200ms，该值尚待确认），内核仍然没有组合成一个MTU时也必须发送现有的数据（不可能让数据一直等待吧）。
      然而，TCP_CORK的实现可能并不像你想象的那么完美，CORK并不会将连接完全塞住。内核其实并不知道应用层到底什么时候会发送第二批数据用于和第一批数据拼接以达到MTU的大小，因此内核会给出一个时间限制，在该时间内没有拼接成一个大包（努力接近MTU）的话，内核就会无条件发送。也就是说若应用层程序发送小包数据的间隔不够短时，TCP_CORK就没有一点作用，反而失去了数据的实时性（每个小包数据都会延时一定时间再发送）。
4. Nagle算法与CORK算法区别
     Nagle算法和CORK算法非常类似，但是它们的着眼点不一样，Nagle算法主要避免网络因为太多的小包（协议头的比例非常之大）而拥塞，而CORK算法则是为了提高网络的利用率，使得总体上协议头占用的比例尽可能的小。如此看来这二者在避免发送小包上是一致的，在用户控制的层面上，Nagle算法完全不受用户socket的控制，你只能简单的设置TCP_NODELAY而禁用它，CORK算法同样也是通过设置或者清除TCP_CORK使能或者禁用之，然而Nagle算法关心的是网络拥塞问题，只要所有的ACK回来则发包，而CORK算法却可以关心内容，在前后数据包发送间隔很短的前提下（很重要，否则内核会帮你将分散的包发出），即使你是分散发送多个小数据包，你也可以通过使能CORK算法将这些内容拼接在一个包内，如果此时用Nagle算法的话，则可能做不到这一点。
    实际上Nagle算法并不是很复杂，他的主要职责是数据的累积，实际上有两个门槛：一个就是缓 冲区中的字节数达到了一定量，另一个就是等待了一定的时间（一般的Nagle算法都是等待200ms）；这两个门槛的任何一个达到都必须发送数据了。一般 情况下，如果数据流量很大，第二个条件是永远不会起作用的，但当发送小的数据包时，第二个门槛就发挥作用了，防止数据被无限的缓存在缓冲区不是好事情哦。 了解了TCP的Nagle算法的原理之后我们可以自己动手来实现一个类似的算法了，在动手之前我们还要记住一个重要的事情，也是我们动手实现Nagle算 法的主要动机就是我想要紧急发送数据的时候就要发送了，所以对于上面的两个门槛之外还的增加一个门槛就是紧急数据发送。
    对于我现在每秒钟10次数据发送，每次数据发送量固定在85~100字节的应用而言，如果采用默认的开启Nagle算法，我在发送端，固定每帧数据85个，间隔100ms发送一次，我在接受端（阻塞方式使用）接受的数据是43 138交替出现，可能就是这个算法的时间阈值问题，如果关闭Nagle算法，在接收端就可以保证数据每次接收到的都是85帧。
    Nagle算法适用于小包、高延迟的场合，而对于要求交互速度的b/s或c/s就不合适了。socket在创建的时候，默认都是使用Nagle算法的，这会导致交互速度严重下降，所以需要setsockopt函数来设置TCP_NODELAY为1.不过取消了Nagle算法，就会导致TCP碎片增多，效率可能会降低。
关闭nagle算法,以免影响性能，因为控制时控制端要发送很多数据量很小的数据包,需要马上发送。
const char  chOpt = 1;
int nErr  =  setsockopt(pContext->m_Socket,  IPPROTO_TCP, TCP_NODELAY,  &chOpt,  sizeof(char));

if  (nErr  ==  -1)
{

    TRACE(_T("setsockopt()?error\n"), WSAGetLastError());
    return;

}
setsockopt(sockfd, SOL_TCP, TCP_CORK, &on, sizeof(on)); //set TCP_CORK
TCP传输小数据包效率问题
摘要：当使用TCP传输小型数据包时，程序的设计是相当重要的。如果在设计方案中不对TCP数据包的
延迟应答，Nagle算法，Winsock缓冲作用引起重视，将会严重影响程序的性能。这篇文章讨论了这些
问题，列举了两个案例，给出了一些传输小数据包的优化设计方案。
背景：当Microsoft TCP栈接收到一个数据包时，会启动一个200毫秒的计时器。当ACK确认数据包
发出之后，计时器会复位，接收到下一个数据包时，会再次启动200毫秒的计时器。为了提升应用程序
在内部网和Internet上的传输性能，Microsoft TCP栈使用了下面的策略来决定在接收到数据包后
什么时候发送ACK确认数据包：

• 如果在200毫秒的计时器超时之前，接收到下一个数据包，则立即发送ACK确认数据包。
  
• 如果当前恰好有数据包需要发给ACK确认信息的接收端，则把ACK确认信息附带在数据包上立即发送。
  
• 计时器超时，ACK确认信息立即发送。
  

为了避免小数据包拥塞网络，Microsoft TCP栈默认启用了Nagle算法，这个算法能够将应用程序多次
调用Send发送的数据拼接起来，当收到前一个数据包的ACK确认信息时，一起发送出去。下面是Nagle
算法的例外情况：

• 如果Microsoft TCP栈拼接起来的数据包超过了MTU值，这个数据会立即发送，而不等待前一个数据包的ACK确认信息。在以太网中，TCP的MTU(Maximum Transmission Unit)值是1460字节。
  
• 如果设置了TCP_NODELAY选项，就会禁用Nagle算法，应用程序调用Send发送的数据包会立即被投递到网络，而没有延迟。
  

为了在应用层优化性能，Winsock把应用程序调用Send发送的数据从应用程序的缓冲区复制到Winsock
内核缓冲区。Microsoft TCP栈利用类似Nagle算法的方法，决定什么时候才实际地把数据投递到网络。
内核缓冲区的默认大小是8K，使用SO_SNDBUF选项，可以改变Winsock内核缓冲区的大小。如果有必要的话，
Winsock能缓冲大于SO_SNDBUF缓冲区大小的数据。在绝大多数情况下，应用程序完成Send调用仅仅表明数据
被复制到了Winsock内核缓冲区，并不能说明数据就实际地被投递到了网络上。唯一一种例外的情况是：
通过设置SO_SNDBUT为0禁用了Winsock内核缓冲区。
为了在应用层优化性能，Winsock把应用程序调用Send发送的数据从应用程序的缓冲区复制到Winsock
内核缓冲区。Microsoft TCP栈利用类似Nagle算法的方法，决定什么时候才实际地把数据投递到网络。
内核缓冲区的默认大小是8K，使用SO_SNDBUF选项，可以改变Winsock内核缓冲区的大小。如果有必要的话，
Winsock能缓冲大于SO_SNDBUF缓冲区大小的数据。在绝大多数情况下，应用程序完成Send调用仅仅表明数据
被复制到了Winsock内核缓冲区，并不能说明数据就实际地被投递到了网络上。唯一一种例外的情况是：
通过设置SO_SNDBUT为0禁用了Winsock内核缓冲区。
Winsock使用下面的规则来向应用程序表明一个Send调用的完成：

• 如果socket仍然在SO_SNDBUF限额内，Winsock复制应用程序要发送的数据到内核缓冲区，完成Send调用。
  
• 如果Socket超过了SO_SNDBUF限额并且先前只有一个被缓冲的发送数据在内核缓冲区，Winsock复制要发送的数据到内核缓冲区，完成Send调用。
  
• 如果Socket超过了SO_SNDBUF限额并且内核缓冲区有不只一个被缓冲的发送数据，Winsock复制要发送的数据到内核缓冲区，然后投递数据到网络，直到Socket降到SO_SNDBUF限额内或者只剩余一个要发送的数据，才完成Send调用。
  

<hr/>- - 内核技术中文网 - 构建全国最权威的内核技术交流分享论坛
原文链接：什么是MTU？怎么优化？（版权归原作者所有，侵删）