TCP MSS与PMTUD

作者：易隐者 发布于：2012-9-6 19:16 Thursday 分类：网络分析

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

点击查看原图


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

点击查看原图


       我们可以看到其差错类型为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协商的过程：

点击查看原图

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

点击查看原图

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

点击查看原图


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

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

点击查看原图

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

点击查看原图

       中间路径上的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值，只针对出接口，此功能一旦开启，其将针对该接口的收发双向有效。
我做一个简化环境下的工作过程图示以便于大家理解其工作过程：

点击查看原图

标签: TCP icmp差错 分片 SYN TCP选项 UDP MTU ICMP PMTUD MSS


您对本文的评分:
当前平均分: 9.7(54 次打分)

版权所有：《蚂蚁网-多维人生，三实而立！》 => 《TCP MSS与PMTUD》
本文地址：http://www.vants.org/?post=109
除非注明，文章均为 《蚂蚁网-多维人生，三实而立！》 原创，欢迎转载！转载请注明本文地址，谢谢。

« 工作机会 | 【转】负载均衡故障诊断：一个MSS值引发的疑案»

评论：

chf7777
2018-11-22 11:27
文章很好，但是在如何避免分片的问题上似乎作者的理解有所偏差
MSS是链路层一次传输的最大报文大小，要避免分片不是MSS大小的问题，而是一次发生的数据包小于MSS，一次发生多少数据包由发送窗口win的大小控制，所以要避免分片只要WIN < MSS 就可以。
回复
master/mg
2014-01-21 18:22
按照你的说法：
如果在中间设备（假设路由器）的内网口上设备MSS，跟在外网口上设置MSS，是一样的效果吗？
回复
lucifer
2013-07-12 17:23
文章很好，赞！
现在我有一个问题，我用专线上新浪（其余网站也一样）的时候，TCP三次握手中我看新浪给我回复的MSS是1460，当我用PPPOE宽带路由器上新浪，我发现TCP三次握手中新浪给我的回复中MSS是1440，我想新浪应该不可能识别到我上网方式的不同，按照您文章中所说的ip tcp adjust-mss技术，我感觉有可能是我的宽带路由器修改了进出数据中TCP的MSS协商值，但是因为是ADSL上网的，所以也没法抓包印证。
请问，你怎么看，是这样的么。
回复
易隐者
2013-07-12 21:06
@lucifer：应该是这样的。
回复

发表评论：

Powered by 易隐者 基于emlog 皖ICP备12002343号-1