TCP/IP协议：最大报文段长度(MSS)是如何确定的

我不是女神ヾ 2022-06-05 04:50 1161阅读 0赞

TCP提供的是一种面向连接的，可靠的字节流服务，TCP提供可靠性的一种重要的方式就是MSS。通过MSS，应用数据被分割成TCP认为最适合发送的数据块，由TCP传递给IP的信息单位称为报文段或段(segment)。代表一个TCP socket的结构体struct tcp\_sock中有多个成员用于确定应用数据被分割成最大为多大的数据块较为合适(最大报文段长度MSS)。

用户在使用路由器访问Internet时，经常会反馈不能访问网页（或部分网页）以及使用Outlook收发邮件（这些应用是基于TCP或UDP的），但进行Ping包时没有问题，这时候检查[配置][Link 1]时也没有错误。出现这种情况的时候，多半是因为在设备上进行了[NAT][]应用，同时设备对报文进行了分片操作。

（没有支持路径MTU；设备没有参与MSS协商；结果TCP协商的MSS大于了设备的MTU-TCP头部-IP头部）

IP报文里是有五元组的，但报文要进行分片时，只有第一片报文带有IP的五元组信息（源目的ip位址，源目的端口号，协议号），后续的分片不会保留TCP/UDP报文所有的标识信息，如端口号信息等，这种情况下，如果设备又实现了NAT转换操作（NAT转换过程中，会随机地做埠转换），并且应用又是基于TCP/UDP的，这就导致报文不能正确组包，会出现上述的问题现象。

(不是所有TCP报文都指定IP报文不分片，特殊报文会指定，比如路径MTU发现机制)

TCP/IP连接时建立的过程中会协商很多参数的，其中TCP MSS参数就是用于协商TCP报文大小的，如果协商出来的TCP MSS的参数值小于设备的MTU的值时，TCP报文在设备上就不会被分片，否则就会出现报文分片并导致上述现象的发生。因此，为了避免上述情况的发生，一定要保证协商的TCP MSS参数小于设备的MTU的值。为此，Quidway路由器上有一个设置TCP MSS值的命令，如果配置了这条命令，路由器设备在建立TCP/IP连接的过程中就按照这个配置的值来修改协商报文中关于TCP MSS的值，在同对端协商的过程中也就能够协商出这个值来，如果不配置这条命令，路由器设备就不会修改报文中的这个值（有时对端设备发送过来的协商报文中的这个值会很大，如8000）。一般来说，默认或配置的MTU的值一般在1500左右，将TCP MSS的值设备为小于1500就可以，如1400或1024等。

如果TCP MSS值设置的过小，报文数量明显增多又导致效率下降，特别是没有配置NAT应用的情况下，限制TCP报文大小更没有必要，由于应用情况比较复杂，设置默认的TCP MSS的值也不是特别合适（设备会在建立连接时均要修改TCP MSS的值），因此，还是在应用中加以注意比较好，[思科][Link 2]设备也是有这个配置命令的。

MTU: Maxitum Transmission Unit 最大传输单元

MSS: Maxitum Segment Size 最大分段大小

MSS最大传输大小的缩写，是TCP协议里面的一个概念。  
MSS就是TCP数据包每次能够传输的最大数据分段。为了达到最佳的传输效能TCP协议在建立连接的时候通常要协商双方的MSS值，这个值TCP协议在实现的时候往往用MTU值代替（需要减去IP数据包包头的大小20Bytes和TCP数据段的包头20Bytes）, 通讯双方会根据双方提供的MSS值得最小值确定为这次连接的最大MSS值。而一般以太网MTU都为1500, 所以在以太网中, 往往TCP MSS为1460。

对于涉及PPPOE＋NAT、IPsec、L2TP、GRE等组网，通常由于报文太大需要分片，这样会降低传输速率; 所以选择一个合适的MSS对传输数据来说比较重要. linux中一般可以通过netfilter iptables设置TCP MSS来解决。

iptables -A FORWARD -p tcp- -tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

这条规则的目的就是改变TCP MSS以适应PMTU(Path MTU)

iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN- j TCPMSS --set-mss 128

设置MSS为128

1）Linux主机接口MTU可通过如下命令设置

ifconfig mtu

2）PPPoE MTU设置，可以通过在配置文件中添加

mtu

mru

3）NAT自动设置MSS值

iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS --clamp-mss-to-pmtu

![51058192][]

![20160404233814432][]

一旦DF设置为一，将不允许中间设备对该报文进行分片，那么在遇到IP报文长度超过中间设备转发接口的MTU值时，该IP报文将会被中间设备丢弃。在丢弃之后，中间设备会向发送方发送ICMP差错报文。  
为了简单直观的展示这个交互的过程，我做了下面这个图示：

[![点击查看原图][692caf0cc23ecc7bb1c85aad6806f74f201209052157091720125873.png]][692caf0cc23ecc7bb1c85aad6806f74f201209052157091720125873.png]

我找了一个实际环境下捕获的ICMP需要分片但DF位置一的差错报文，下图为其解码格式：

[![点击查看原图][0feae7d701a27be8d7a360ef6cb66658201209052157091918320565.png]][0feae7d701a27be8d7a360ef6cb66658201209052157091918320565.png]

我们可以看到其差错类型为3，代码为4，并且告知了下一跳的MTU值为1478。在ICMP差错报文里封装导致此差错的原始IP报文的报头（包含IP报头和四层报头）。

一旦出现这种因DF位置一而引起丢包，如果客户端无法正常处理的话，将会导致业务应用出现异常，外在表现为页面无法打开、页面打开不全、某些大文件无法传输等等，这将严重影响业务的正常运行。  
那么客户端如何处理这种状况呢？  
TCP主要通过两种方式来应对：  
1， 协商MSS，在交互之前避免分片的产生  
2， 路径MTU发现（PMTUD）

TCP MSS

TCP在三次握手建立连接过程中，会在SYN报文中使用MSS（Maximum Segment Size）选项功能，协商交互双方能够接收的最大段长MSS值。  
 MSS是传输层TCP协议范畴内的概念，顾名思义，其标识TCP能够承载的最大的应用数据段长度，因此，MSS=MTU-20字节TCP报头-20字节IP报头，那么在以太网环境下，MSS值一般就是1500-20-20=1460字节。  
客户端与服务器端分别根据自己发包接口的MTU值计算出相应MSS值，并通过SYN报文告知对方，我们还是通过一个实际环境中捕获的数据报文来看一下MSS协商的过程：

[![点击查看原图][13f465a71d39e31b28c1568269e577f3201209052157101372631015.png]][13f465a71d39e31b28c1568269e577f3201209052157101372631015.png]

这是整个报文交互过程的截图，我们再来看一下客户端的报文详细解码：

[![点击查看原图][6cd05c27bad36f1e70485d9063b65c0520120905215711916817182.png]][6cd05c27bad36f1e70485d9063b65c0520120905215711916817182.png]

上图为客户端的SYN报文，在其TCP选项字段，我们可以看到其通告的MSS值为1460；我们在看看服务器端的SYN/ACK报文解码：

[![点击查看原图][4150fa5a19d47041aa9727148deca512201209052157112105531868.png]][4150fa5a19d47041aa9727148deca512201209052157112105531868.png]

上图为服务器端给客户端回应的SYN/ACK报文，查看其TCP选项字段，我们可以发现其通告的MSS值为1440。

交互双方会以双方通告的MSS值中取最小值作为发送报文的最大段长。在此TCP连接后续的交互过程中，我们可以清楚的看到服务器端向客户端发送的报文中，TCP的最大段长度都是1440字节，如下图解码所示：

[![点击查看原图][6f75c843874a0009964b5e24b2f24f57201209052157111939739669.png]][6f75c843874a0009964b5e24b2f24f57201209052157111939739669.png]

通过在TCP连接之初，协商MSS值巧妙的解决了避免端系统分片的问题，但是在复杂的实际网络环境下，影响到IP报文分片的并不仅仅是发送方和接收方，还有路由器、防火墙等中间系统，假设在下图的网络环境下：

[![点击查看原图][6fd282222635b1845ec97902a99baa83201209052157122094684129.png]][6fd282222635b1845ec97902a99baa83201209052157122094684129.png]

中间路径上的MTU问题，端系统并不知道，因此需要一个告知的机制，这个机制就是路径MTU发现（PMTUD： Path MTU Discovery ）！

PMTUD

说起PMTUD，我们必须在此回到上面讲到的ICMP需要分片但DF位置一差错报文，还记得那个ICMP差错报文中有一个字段是告知下一跳的MTU值的吗？PMTUD正是利用ICMP需要分片但DF位置一差错报文的这一特性来实现的。  
 发送方在接收到该差错报文后，会根据该报文给出的下一跳的MTU值计算适合传输的最大段长度，从而在后续的发送报文过程中，避免在中间路径被分片的情况产生。  
 这在端系统主要是通过在路由表里临时添加目的主机路由并将ICMP差错报文告知的下一跳MTU值跟该主机路由关联起来来实现。  
 PMTUD的确是个非常不错的机制，但是在复杂的实际网络环境中，有时候会失效，因为为了安全起见，有些网络管理员会在路由器、防火墙等中间设备上设置过滤ICMP报文的安全策略，这将导致ICMP差错报文被这些中间设备丢弃，无法达到发送方，从而引起PMTUD的失效，网上有个宫一鸣前辈共享的案例——《错误的网络访问控制策略导致PMTUD 实现故障一例》，该案例正是说明这种情况绝好的例子，大家可以自行百度此文档学习参考。

值得一提的是PMTUD仅TCP支持，UDP并不支持PMTUD。

由于PMTUD可能存在ICMP差错报文被过滤的情况，很多中间设备的接口支持adjust tcp mss设置功能，思科路由器一般是在接口模式下使用命令“ip tcp adjust-mss 1400 ”来做设置，其他的品牌产品的相关设置大家可在实际工作环境下自查相关品牌和产品的使用手册。

这个功能主要是通过由中间设备修改经过其转发的TCP SYN报文中的MSS值，让中间设备参与进TCP 三次握手时SYN报文的MSS协商来避免分片。

需要注意的是，该功能不像MTU值，只针对出接口，此功能一旦开启，其将针对该接口的收发双向有效。  
我做一个简化环境下的工作过程图示以便于大家理解其工作过程：

[![点击查看原图][2b201320d835ec05a74f64202c0f2d7a2012090521570819765176.png]][2b201320d835ec05a74f64202c0f2d7a2012090521570819765176.png]

[Link 1]: http://www.07net01.com/r_s/
[NAT]: http://www.07net01.com/route/
[Link 2]: http://www.07net01.com/
[51058192]: /images/20220605/d1b50775093c450a8e85ca37f9d61c92.png
[20160404233814432]: /images/20220605/ef3c51ff6b434023812799a77e730142.png
[692caf0cc23ecc7bb1c85aad6806f74f201209052157091720125873.png]: /images/20220605/a4c271e715bb468ca1de6237088ff109.png
[0feae7d701a27be8d7a360ef6cb66658201209052157091918320565.png]: /images/20220605/a8bd2c25e9f44a21be365d1d696d644b.png
[13f465a71d39e31b28c1568269e577f3201209052157101372631015.png]: /images/20220605/fed40ce530534352b69805aaf7a768ff.png
[6cd05c27bad36f1e70485d9063b65c0520120905215711916817182.png]: /images/20220605/7e64f4ce9eed44e8a48a7e26f7f748ba.png
[4150fa5a19d47041aa9727148deca512201209052157112105531868.png]: /images/20220605/b511ee9436164a7d825ae6f405cc442c.png
[6f75c843874a0009964b5e24b2f24f57201209052157111939739669.png]: /images/20220605/0c780334cdbc42eaa2580a64c4f1487b.png
[6fd282222635b1845ec97902a99baa83201209052157122094684129.png]: /images/20220605/3fed04c792ee4ba3a55bcdb431a9c5c1.png
[2b201320d835ec05a74f64202c0f2d7a2012090521570819765176.png]: /images/20220605/f66c46890f6d45d2956a3f7afc6de172.png