TCP/IP协议：最大传输单元MTU 和最大分段大小MSS (TCP的分段和IP的分片)

傷城~ 2022-06-04 07:10 215阅读 0赞

**MTU = MSS + TCP Header + IP Header.**

**mtu是网络传输最大报文包。 mss是网络传输数据最大值。**

**MTU**：maximum transmission unit，最大传输单元，由硬件规定，如以太网的MTU为1500字节。

**MSS**：maximum segment size，最大分节大小，为TCP数据包每次传输的最大数据分段大小，一般由发送端向对端TCP通知对端在每个分节中能发送的最大TCP数据。MSS值为MTU值减去IPv4 Header（20 Byte）和TCP header（20 Byte）得到。

**分片**：若一IP数据报大小超过相应链路的MTU的时候，IPV4和IPV6都执行分片(fragmentation)，各片段到达目的地前通常不会被重组(re-assembling)。IPV4主机对其产生的数据报执行分片，IPV4路由器对其转发的数据也执行分片。然而IPV6只在数据产生的主机执行分片；IPV6路由器对其转发的数据不执行分片。

例如：一个以太网上的主机和一个令牌环网上的主机间建立连接，其中以太网上主机通告的MSS为1460，令牌环网上主机通告的MSS为4096。观察分组，在两个方向上都找不到大于1460字节的数据，为什么？

令牌环网上发送到以太网的数据大小不大于1460字节的原因是因为以太网上主要通告的MSS值就为1460个字节，所以令牌环网上发送出去的数据的长度不能够大于MSS值；令牌环网上主机通告的MSS值为4096，也即是说以太网能够发送到令牌环网上的TCP净荷值为4096，但是以太网的MTU值又是由硬件所决定的，最大只支持1500（包括IP头至少20B和TCP头至少20B），为避免分片，因此以太网发送到令牌环网的数据的净荷也为1500-20-20=1460B，所以两个方向的净数据长度不会大于1460字节。

下面这张图是**数据进入协议栈时的封装过程**

![211410439411608.png][]

最大传输单元MTU

以太网和8 0 2 . 3对数据帧的长度都有一个限制，其最大值分别是1 5 0 0和1 4 9 2字节。链路层的这个特性称作M T U，最大传输单元。不同类型的网络大多数都有一个上限。  
如果I P层有一个数据报要传，而且数据的长度比链路层的M T U还大，那么I P层就需要进行分片（ f r a g m e n t a t i o n），把数据报分成若干片，这样每一片都小于M T U。  
图2 - 5列出了一些典型的M T U值，它们摘自RFC 1191\[Mogul and Deering 1990\]。点到点的链路层（如S L I P和P P P）的M T U并非指的是网络媒体的物理特性。相反，它是一个逻辑限制，目的是为交互使用提供足够快的响应时间。

路径MTU

当在同一个网络上的两台主机互相进行通信时，该网络的M T U是非常重要的。但是如果  
两台主机之间的通信要通过多个网络，那么每个网络的链路层就可能有不同的M T U。重要的  
不是两台主机所在网络的M T U的值，重要的是两台通信主机路径中的最小M T U。它被称作路  
径M T U。  
两台主机之间的路径M T U不一定是个常数。它取决于当时所选择的路由。而选路不一定  
是对称的（从A到B的路由可能与从B到A的路由不同），因此路径M T U在两个方向上不一定是  
一致的。  
RFC 1191\[Mogul and Deering 1990\]描述了路径M T U的发现机制，即在任何时候确定路径  
M T U的方法。

MSS 是TCP选项中最经常出现，也是最早出现的选项。MSS选项占4byte。MSS是每一个TCP报文段中数据字段的最大长度，注意：只是数据部分的字段，不包括TCP的头部。TCP在三次握手中，每一方都会通告其期望收到的MSS（MSS只出现在SYN数据包中）如果一方不接受另一方的MSS值则定位默认值536byte。  
MSS值太小或太大都是不合适。太小，例如MSS值只有1byte，那么为了传输这1byte数据，至少要消耗20字节IP头部+20字节TCP头部=40byte，这还不包括其二层头部所需要的开销，显然这种数据传输效率是很低的。MSS过大，导致数据包可以封装很大，那么在IP传输中分片的可能性就会增大，接受方在处理分片包所消耗的资源和处理时间都会增大，如果分片在传输中还发生了重传，那么其网络开销也会增大。因此合理的MSS是至关重要的。MSS的合理值应为保证数据包不分片的最大值。对于以太网MSS可以达到1460byte.  
与MSS相似的在IP层也有一个类似的概念---MTU（Maximum Transfer Unit）下图可以清晰翻译MSS不MTU 的关系：

**MTU =MSS \+ TCP Header + IP Header.**

![showimage-10046027-10000035-6fb84a4a7338f2861a3402bf9fdecf4d.jpg][]

# TCP/IP详解--TCP的分段和IP的分片 #

分组可以发生在运输层和网络层，运输层中的TCP会分段，网络层中的IP会分片。**IP层的分片更多的是为运输层的UDP服务的**，由于TCP自己会避免IP的分片，所以使用TCP传输在IP层都不会发生分片的现象。

我们在学习TCP/IP协议时都知道，TCP报文段如果很长的话，会在发送时发生分段，在接受时进行重组，同样IP数据报在长度超过一定值时也会发生分片，在接收端再将分片重组。

我们先来看两个与TCP报文段分段和IP数据报分片密切相关的概念。

MTU（最大传输单元）

MTU前面已经说过了，是链路层中的网络对数据帧的一个限制，依然以以太网为例，MTU为1500个字节。一个IP数据报在以太网中 传输，如果它的长度大于该MTU值，就要进行分片传输，使得每片数据报的长度小于MTU。分片传输的IP数据报不一定按序到达，但IP首部中的信息能让这些数据报片按序组装。IP数据报的分片与重组是在网络层进完成的。

MSS（最大分段大小）

MSS是TCP里的一个概念（首部的选项字段中）。MSS是TCP数据包每次能够传输的最大数据分段，TCP报文段的长度大于MSS时，要进行分段传输。TCP协议在建立连接的时候通常要协商双方的MSS值，每一方都有用于通告它期望接收的MSS选项（MSS选项只出现在SYN报文段中，即TCP三次握手的前两次）。MSS的值一般为MTU值减去两个首部大小（需要减去IP数据包包头的大小20Bytes和TCP数据段的包头20Bytes）所以如果用链路层以太网，MSS的值往往为1460。而Internet上标准的MTU（最小的MTU，链路层网络为x2.5时）为576，那么如果不设置，则MSS的默认值就为536个字节。很多时候，MSS的值最好取512的倍数。TCP报文段的分段与重组是在运输层完成的。

到了这里有一个问题自然就明了了，TCP分段的原因是MSS，IP分片的原因是MTU，由于一直有MSS<=MTU，很明显，分段后的每一段TCP报文段再加上IP首部后的长度不可能超过MTU，因此也就不需要在网络层进行IP分片了。因此TCP报文段很少会发生IP分片的情况。

再来看UDP数据报，由于UDP数据报不会自己进行分段，因此当长度超过了MTU时，会在网络层进行IP分片。同样，ICMP（在网络层中）同样会出现IP分片情况。

总结：**UDP不会分段，就由IP来分。TCP会分段，当然就不用IP来分了**！

另外，IP数据报分片后，只有第一片带有UDP首部或ICMP首部，其余的分片只有IP头部，到了端点后根据IP头部中的信息再网络层进行重组。而TCP报文段的每个分段中都有TCP首部，到了端点后根据TCP首部的信息在传输层进行重组。IP数据报分片后，只有到达目的地后才进行重组，而不是向其他网络协议，在下一站就要进行重组。

最后一点，对IP分片的数据报来说，即使只丢失一片数据也要重新传整个数据报（既然有重传，说明运输层使用的是具有重传功能的协议，如TCP协议）。这是因为IP层本身没有超时重传机制------由更高层（比如TCP）来负责超时和重传。当来自TCP报文段的某一段（在IP数据报的某一片中）丢失后，TCP在超时后会重发整个TCP报文段，该报文段对应于一份IP数据报（可能有多个IP分片），没有办法只重传数据报中的一个数据分片。

**在IP层分片时，只有第一个分片存在运输层协议头部，其余分片都不包含运输层协议的首部**，这一点很重要。然后**TCP的分段，每一个分段都包含TCP首部信息**。再有就是**IP分片时到达目的地之后再进行重组的，IP层的重组是发生在目的地的IP层**，**TCP的重组是发生在目的地的传输层中**。

转自：

http://blog.csdn.net/yygydjkthh/article/details/7359281

http://blog.csdn.net/xiaofei0859/article/details/51052752

[https://blog.csdn.net/yusiguyuan/article/details/39860303][https_blog.csdn.net_yusiguyuan_article_details_39860303]

[211410439411608.png]: /images/20220604/6139ac1440d841568c8a23a8ce302e40.png
[showimage-10046027-10000035-6fb84a4a7338f2861a3402bf9fdecf4d.jpg]: /images/20220604/be710519c3114f66bc5d488196d37375.png
[https_blog.csdn.net_yusiguyuan_article_details_39860303]: https://blog.csdn.net/yusiguyuan/article/details/39860303