提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档
前言
在计算机网络中，数据的传输是通过分组的方式进行的。MTU（Maximum Transmission Unit）是指数据链路层中的最大传输单元。本文将详细介绍什么是MTU，它的作用以及相关的知识点。
一、MTU是什么？
MTU：Maximum Transmission Unit,最大传输单元MTU
通俗点来讲，MTU 是指数据链路层能够传输的最大数据帧的大小（以字节为单位）
原文：最大傳輸單元 (Maximum Transmission Unit, MTU) - NotFalse 技術客
比较好的简介结构：https://www.cloudflare.com/zh-cn/learning/network-layer/what-is-mtu/
(Maximum Transmission Unit, MTU)
最大传输单元MTU
帧太大的时候，传输需耗损大量的 缓衝区 (buffer) 大小
传输媒介可能被某一传送端独佔，造成堵塞
因此，数据链路 (Data-Link) 规范了 帧 (Frame) 的大小上限，
也就是 — — 最大传输单元 (Maximum Transmission Unit, MTU)，
如果没有这些缺点， MTU 当然越大越好啦!
许多可靠的传输层 (如: 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优化配置的一些总结
原文：https://www.cnblogs.com/maowang1991/archive/2013/04/15/3022955.html
首先要看TCP/IP协议，涉及到四层：链路层，网络层，传输层，应用层。
其中以太网（Ethernet）的数据帧在链路层
IP包在网络层
TCP或UDP包在传输层
TCP或UDP中的数据（Data)在应用层
它们的关系是 数据帧｛IP包｛TCP或UDP包｛Data｝｝｝
---------------------------------------------------------------------------------
在应用程序中我们用到的Data的长度最大是多少，直接取决于底层的限制。
我们从下到上分析一下：
1.在链路层，由以太网的物理特性决定了数据帧的长度为（46＋18）－（1500＋18），其中的18是数据帧的头和尾，也就是说数据帧的内容最大为1500（不包括帧头和帧尾）---（怀疑，现在还是1500？“历史网络媒体速度较慢，更容易出错，因此MTU Size设置得较小。对于大多数以太网，此设置为1500字节……”见：【MTU】关于MTU size| MTU size, PMTUD 和分段_bandaoyu的博客-CSDN博客_mtu大小），即MTU（Maximum Transmission Unit）为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选项来取消确认延迟。
关于TCP确认延迟的详细介绍可参考：http://blog.csdn.net/turkeyzhou/article/details/6764389
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确认数据包：
1、如果在200毫秒的计时器超时之前，接收到下一个数据包，则立即发送ACK确认数据包。
2、如果当前恰好有数据包需要发给ACK确认信息的接收端，则把ACK确认信息附带在数据包上立即发送。
3、当计时器超时，ACK确认信息立即发送。
为了避免小数据包拥塞网络，Microsoft TCP栈默认启用了Nagle算法，这个算法能够将应用程序多次
调用Send发送的数据拼接起来，当收到前一个数据包的ACK确认信息时，一起发送出去。下面是Nagle
算法的例外情况：
1、如果Microsoft TCP栈拼接起来的数据包超过了MTU值，这个数据会立即发送，而不等待前一个数据
包的ACK确认信息。在以太网中，TCP的MTU(Maximum Transmission Unit)值是1460字节。
2、如果设置了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调用的完成：
1、如果socket仍然在SO_SNDBUF限额内，Winsock复制应用程序要发送的数据到内核缓冲区，完成Send调用。
2、如果Socket超过了SO_SNDBUF限额并且先前只有一个被缓冲的发送数据在内核缓冲区，Winsock复制要发送
的数据到内核缓冲区，完成Send调用。
3、如果Socket超过了SO_SNDBUF限额并且内核缓冲区有不只一个被缓冲的发送数据，Winsock复制要发送的数据
到内核缓冲区，然后投递数据到网络，直到Socket降到SO_SNDBUF限额内或者只剩余一个要发送的数据，才
完成Send调用。
案例1
一个Winsock TCP客户端需要发送10000个记录到Winsock TCP服务端，保存到数据库。记录大小从20字节到100
字节不等。对于简单的应用程序逻辑，可能的设计方案如下：
1、客户端以阻塞方式发送，服务端以阻塞方式接收。
2、客户端设置SO_SNDBUF为0，禁用Nagle算法，让每个数据包单独的发送。
3、服务端在一个循环中调用Recv接收数据包。给Recv传递200字节的缓冲区以便让每个记录在一次Recv调用中
被获取到。
性能：
在测试中发现，客户端每秒只能发送5条数据到服务段，总共10000条记录，976K字节左右，用了半个多小时
才全部传到服务器。
分析：
因为客户端没有设置TCP_NODELAY选项，Nagle算法强制TCP栈在发送数据包之前等待前一个数据包的ACK确认
信息。然而，客户端设置SO_SNDBUF为0，禁用了内核缓冲区。因此，10000个Send调用只能一个数据包一个数据
包的发送和确认，由于下列原因，每个ACK确认信息被延迟200毫秒：
1、当服务器获取到一个数据包，启动一个200毫秒的计时器。
2、服务端不需要向客户端发送任何数据，所以，ACK确认信息不能被发回的数据包顺路携带。
3、客户端在没有收到前一个数据包的确认信息前，不能发送数据包。
4、服务端的计时器超时后，ACK确认信息被发送到客户端。
如何提高性能：
在这个设计中存在两个问题。第一，存在延时问题。客户端需要能够在200毫秒内发送两个数据包到服务端。
因为客户端默认情况下使用Nagle算法，应该使用默认的内核缓冲区，不应该设置SO_SNDBUF为0。一旦TCP
栈拼接起来的数据包超过MTU值，这个数据包会立即被发送，不用等待前一个ACK确认信息。第二，这个设计
方案对每一个如此小的的数据包都调用一次Send。发送这么小的数据包是不很有效率的。在这种情况下，应该
把每个记录补充到100字节并且每次调用Send发送80个记录。为了让服务端知道一次总共发送了多少个记录，
客户端可以在记录前面带一个头信息。
案例二：
一个Winsock TCP客户端程序打开两个连接和一个提供股票报价服务的Winsock TCP服务端通信。第一个连接
作为命令通道用来传输股票编号到服务端。第二个连接作为数据通道用来接收股票报价。两个连接被建立后，
客户端通过命令通道发送股票编号到服务端，然后在数据通道上等待返回的股票报价信息。客户端在接收到第一
个股票报价信息后发送下一个股票编号请求到服务端。客户端和服务端都没有设置SO_SNDBUF和TCP_NODELAY
选项。
性能：
测试中发现，客户端每秒只能获取到5条报价信息。
分析：
这个设计方案一次只允许获取一条股票信息。第一个股票编号信息通过命令通道发送到服务端，立即接收到
服务端通过数据通道返回的股票报价信息。然后，客户端立即发送第二条请求信息，send调用立即返回，
发送的数据被复制到内核缓冲区。然而，TCP栈不能立即投递这个数据包到网络，因为没有收到前一个数据包的
ACK确认信息。200毫秒后，服务端的计时器超时，第一个请求数据包的ACK确认信息被发送回客户端，客户端
的第二个请求包才被投递到网络。第二个请求的报价信息立即从数据通道返回到客户端，因为此时，客户端的
计时器已经超时，第一个报价信息的ACK确认信息已经被发送到服务端。这个过程循环发生。
如何提高性能：
在这里，两个连接的设计是没有必要的。如果使用一个连接来请求和接收报价信息，股票请求的ACK确认信息会
被返回的报价信息立即顺路携带回来。要进一步的提高性能，客户端应该一次调用Send发送多个股票请求，服务端
一次返回多个报价信息。如果由于某些特殊原因必须要使用两个单向的连接，客户端和服务端都应该设置TCP_NODELAY
选项，让小数据包立即发送而不用等待前一个数据包的ACK确认信息。
提高性能的建议：
上面两个案例说明了一些最坏的情况。当设计一个方案解决大量的小数据包发送和接收时，应该遵循以下的建议：
1、如果数据片段不需要紧急传输的话，应用程序应该将他们拼接成更大的数据块，再调用Send。因为发送缓冲区
很可能被复制到内核缓冲区，所以缓冲区不应该太大，通常比8K小一点点是很有效率的。只要Winsock内核缓冲区
得到一个大于MTU值的数据块，就会发送若干个数据包，剩下最后一个数据包。发送方除了最后一个数据包，都不会
被200毫秒的计时器触发。
2、如果可能的话，避免单向的Socket数据流接连。
3、不要设置SO_SNDBUF为0，除非想确保数据包在调用Send完成之后立即被投递到网络。事实上，8K的缓冲区适合大多数
情况，不需要重新改变，除非新设置的缓冲区经过测试的确比默认大小更高效。
4、如果数据传输不用保证可靠性，使用UDP。
TCP，UDP数据包的大小以及MTU
转自：TCP，UDP数据包的大小以及MTU_Answer-3的博客-CSDN博客_一个tcp包mtu的大小
TCP、UDP数据包大小的确定
UDP和TCP协议利用端口号实现多项应用同时发送和接收数据。数据通过源端口发送出去，通过目标端口接收。有的网络应用只能使用预留或注册的静态端口；而另外一些网络应用则可以使用未被注册的动态端口。因为UDP和TCP报头使用两个字节存放端口号，所以端口号的有效范围是从0到65535。动态端口的范围是从1024到65535。
MTU最大传输单元，这个最大传输单元实际上和链路层协议有着密切的关系，EthernetII帧的结构DMAC+SMAC+Type+Data+CRC由于以太网传输电气方面的限制，每个以太网帧都有最小的大小64bytes最大不能超过1518bytes，对于小于或者大于这个限制的以太网帧我们都可以视之为错误的数据帧，一般的以太网转发设备会丢弃这些数据帧。
由于以太网EthernetII最大的数据帧是1518Bytes这样，刨去以太网帧的帧头（DMAC目的MAC地址48bit=6Bytes+SMAC源MAC地址48bit=6Bytes+Type域2bytes）14Bytes和帧尾CRC校验部分4Bytes那么剩下承载上层协议的地方也就是Data域最大就只能有1500Bytes这个值我们就把它称之为MTU。
UDP 包的大小就应该是 1500 - IP头(20) - UDP头(8) = 1472(BYTES)
TCP 包的大小就应该是 1500 - IP头(20) - TCP头(20) = 1460 (BYTES)
注*PPPoE所谓PPPoE就是在以太网上面跑“PPP”。随着宽带接入（这种宽带接入一般为Cable Modem或者xDSL或者以太网的接入），因为以太网缺乏认证计费机制而传统运营商是通过PPP协议来对拨号等接入服务进行认证计费的，所以引入PPPoE。PPPoE导致MTU变小了以太网的MTU是1500，再减去PPP的包头包尾的开销（8Bytes），就变成1492。不过目前大多数的路由设备的MTU都为1500。
如果我们定义的TCP和UDP包没有超过范围，那么我们的包在IP层就不用分包了，这样传输过程中就避免了在IP层组包发生的错误；如果超过范围，既IP数据报大于1500字节，发送方IP层就需要将数据包分成若干片，而接收方IP层就需要进行数据报的重组。更严重的是，如果使用UDP协议，当IP层组包发生错误，那么包就会被丢弃。接收方无法重组数据报，将导致丢弃整个IP数据报。UDP不保证可靠传输；但是TCP发生组包错误时，该包会被重传，保证可靠传输。
UDP数据报的长度是指包括报头和数据部分在内的总字节数，其中报头长度固定，数据部分可变。数据报的最大长度根据操作环境的不同而各异。从理论上说，包含报头在内的数据报的最大长度为65535字节（64K）。
我们在用Socket编程时， UDP协议要求包小于64K，TCP没有限定。
不过鉴于Internet上的标准MTU值为576字节，所以建议在进行Internet的UDP编程时，最好将UDP的数据长度控制在548字节 (576-8-20)以内。
就具体函数而言：
用UDP协议发送时，用sendto函数最大能发送数据的长度为：65535- IP头(20) - UDP头(8)＝65507字节。用sendto函数发送数据时，如果发送数据长度大于该值，则函数会返回错误。
用TCP协议发送时，由于TCP是数据流协议，因此不存在包大小的限制（暂不考虑缓冲区的大小），这是指在用send函数时，数据长度参数不受限制。而实际上，所指定的这段数据并不一定会一次性发送出去，如果这段数据比较长，会被分段发送，如果比较短，可能会等待和下一次数据一起发送。
为什么需要 MTU ？
我们知道，数据在数据链路层中通常是以数据帧（Frame）的形式来传输
因为传输的 Frame 不可能无限大（传小的可以），那么一次传多大的 Frame 最合适、最高效就成了一个需要考虑的问题
所以说我们要设定一个值（也就是 MTU），这个值用来限制 Frame 的大小
维基百科有这么一段话
Larger MTU is associated with reduced overhead. Smaller MTU values can reduce network delay.
由上面的话可以得出：
- MTU越大，开销越小
这句话是很容易理解的，更大的 Frame 意味着包含的有效数据也就更多
我一次能传更多的数据了，那么传输次数就少了，在网络上的开销就变小了
- 较小的MTU值可以减少网络延迟
这句话容易让人引起困惑，为什么 MTU 值小能够减少网络延迟呢？
如果 MTU 设置的很大，意味着一次能传更大的数据了，那占据链路的时间就会更长，所以总体上网络延迟就会变大
而且如果一大段数据里面有一个 bit 出错了，这一大段就会整个重传，重传的代价是很大的
那么 MTU 设置成多少合适呢？
为什么 MTU 的值是 1500？
RFC 标准定义以太网的默认 MTU 值为 1500，为什么是 1500 ？
这是一个历史遗留问题
早期的以太网使用共享链路的工作方式，为了保证 CSMA/CD（载波多路复用/冲突检测）机制，规定了以太帧长度最小为 64 字节，最大为 1518 字节
- 最小 64 字节是为了保证最极端的冲突能被检测到，64 字节是能被检测到的最小值
- 最大不超过 1518 字节是为了防止过长的帧传输时间过长而占用共享链路太长时间导致其他业务阻塞
所以说数据帧的最大长度被限制为 1518 字节（包括帧头、帧尾和CRC校验）
18 字节用于帧头和帧尾，其中 CRC 校验占据 4 字节，剩下的 1500 字节就是最大数据载荷（Payload）
因此，1500 字节被定义为以太网数据帧中数据部分的最大长度（MTU）
虽然技术不断发展，但这个规定一直没有更改
以太网经过几十年的发展，速度已经从最初的10M被提升到了上百G，速度提高了上万倍
在这样高速度的传输数据中，如果还是延续经典以太网的最大帧长不超过1518 字节的限制，那么在每秒中传输的数据包的个数将很大
于是一些厂商提出了巨型帧（Jumbo Frame）的概念，把以太网的最大帧长扩展到了9K
目前还没有获得 IEEE 标准委员会的认可，但是大多数的设备厂商都已经开始支持
发送数据大小超过 MTU 怎么办？
以太网的 MTU 默认值是 1500，如果发送 Frame 小于 MTU（例如 1000 字节），直接传输就行
如果大于 MTU（payload 为 4000 字节），那就需要进行分片（Fragment）
即第一次发送 1500 字节（IP header 20 字节 + Payload 1480 字节）
第二次发送 1500 字节（IP header 20 字节 + Payload 1480 字节）
第三次 1060字节（IP header 20 字节 + Payload 1040 字节））
可能有小伙伴问，那我传的数据大小不够数据帧规定的最小 64 字节怎么办？
答案是：在实际数据内容后面添加填充数据，使得数据包总长度达到最小长度要求。填充数据可以是任意无意义的字节，例如全 0 或全 1 的数据
如何保证发送的数据不超过 MTU ？
前面我们知道，如果发送的数据大于 MTU，则就会进行分片操作
要让最终传给数据链路层的 Frame 数据大小不超过 1500 bytes，就要保证上层中的每一层的数据都没有超过这个大小
如果 MTU 是 1500，那么 IP 层就要保证 IP 层的 Packet 数据不超过 1480 bytes (1500 bytes – 20 bytes IP header),
对于 TCP 来说，它要保证每一个 Segment 数据大小不超过 1460 bytes (1460 bytes – 20 TCP header)
以 TCP 层（传输层）为例子， TCP 层是怎么知道发送的数据不会超过 MTU 呢？
- IP 层（网络层）问数据链路层数据最大传输单元（ MTU ）是多少
- TCP 层会问 IP 层数据最大传输大小（Maximum packet size）是多少
这样 TCP 层就会知道自己的最大传输数据大小，叫做 MSS（Maximum segment size）
在 TCP 的握手阶段，MSS（Maximum Segment Size）是用于指定TCP报文段中数据部分的最大长度
对于 TCP 来说，知道自己的 MSS 没有什么用
例如作为接收端来说，收到的包大小取决于发送端，得让发送端知道自己的 MSS 才行
所以在建立 TCP 连接时，双方需要协商一个合适的 MSS 值，以便在数据传输过程中进行分片和重组
什么是 TSO
前面我们介绍了什么是 MTU、MSS
如果你去抓一下包看看，你可能会遇到下面这种情况
明明协商了 MSS 为 1460 字节，为什么数据居然有一万多字节？
在建立 TCP 连接时，双方需要协商一个合适的 MSS 值，以便在数据传输过程中进行分片
但是这个分片过程往往是简单重复而且计算量比较大的，需要占用较多的 CPU 资源
所以网卡就会对内核说：哥这种小事我来干就好了，不需要麻烦您
然后内核就会把大包发给网卡，网卡来负责分片
这个叫做 TSO（TCP Segment Offload）
TSO（TCP Segmentation Offload）是一种网络传输卸载技术，用于减轻主机的网络数据包分段负担，提高网络传输性能
我们在抓包的时候看到是还在内核里的包，后面网卡拆包的过程是看不到的
网卡不但能对发送的包进行 offload，也可以对接收的包进行 onload，简单来说就是网卡会先把一些小的包积攒下来，然后合起来发送给内核
# 查看网卡上面是否开启 TSO 功能
# on 表示开启
[root@root~]# ethtool -k <网卡名称>
tcp-segmentation-offload: on
tx-tcp-segmentation: on
tx-tcp-ecn-segmentation: on
tx-tcp6-segmentation: on
tx-tcp-mangleid-segmentation: off
最后总结一下：
- MTU 是指数据链路层能够传输的最大数据帧的大小（以字节为单位）。由于历史原因，MTU 的值最小为 64 字节，最大为 1518 字节（Payload 则是 46~1500 字节）
- 如果发送的数据大于 MTU，则就会进行分片操作；如果小于 MTU，就会在实际数据内容后面添加填充数据，使得数据包总长度达到最小长度要求
- MSS（Maximum Segment Size）是用于指定 TCP 报文段中数据部分的最大长度。在建立 TCP 连接时，双方需要协商一个合适的 MSS 值以便在数据传输过程中进行分片和重组
- TSO（TCP Segmentation Offload）是一种网络传输卸载技术。TSO 技术将分片过程从 CPU 转移到网卡上的专用硬件，网卡负责将应用程序的大块数据分段为适当大小的数据包，并添加 TCP 首部，然后直接发送到网络上
3万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
