2023年7月31日发(作者：)

TCPIP协议：最⼤报⽂段长度（MSS）是如何确定的（2）⼀旦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设置功能，思科路由器⼀般是在接⼝模式下使⽤命令“iptcp adjust-mss 1400 ”来做设置，其他的品牌产品的相关设置⼤家可在实际⼯作环境下⾃查相关品牌和产品的使⽤⼿册。 这个功能主要是通过由中间设备修改经过其转发的TCP SYN报⽂中的MSS值，让中间设备参与进TCP 三次握⼿时SYN报⽂的MSS协商来避免分⽚。 需要注意的是，该功能不像MTU值，只针对出接⼝，此功能⼀旦开启，其将针对该接⼝的收发双向有效。

我做⼀个简化环境下的⼯作过程图⽰以便于⼤家理解其⼯作过程：