TCP选项 - 蚂蚁网-多维人生，三实而立！

欢迎关注:1，欢迎关注本博客，你可点击右手边的【QQ邮件订阅】订阅本博客！2，本博客推出江湖救急计划，主要为工作中遇到疑难杂症的兄弟提供远程技术支持和分析，如有需要，请在江湖救急计划页面给我留言！

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

评论(4) 引用(0) 浏览(33380)

TCP SACK选项

作者：易隐者发布于：2012-8-1 22:37 Wednesday 分类：网络分析

一般TCP的ACK过程

在TCP的交互过程中，除了第一个SYN请求报文的ACK标志未置1外，其他的报文的ACK标志都是置1的。当客户端与服务器在交互的过程中，某些数据报被丢弃时，其ACK确认和后续数据交互的过程如下图所示：

图 1 一般丢包情况下的ACK确认和后续数据交互的过程示意图

在上图所示的交互过程中，我们可以清楚的发现，在交互中由于某些未知的不可控的原因导致包含data-2的数据报文丢失。虽然仅有包含data-2的报文丢失，客户端已经收到其他的data，但是，服务器却要将data-2以及data-2之后的其他Data重传一次，这就造成了交互效率的低下。正是为了解决这个问题，诞生了SACK。

SACK介绍

SACK(Selective Acknowledgment，选择性确认)技术，使TCP只重新发送交互过程中丢失的包，不用发送后续所有的包，而且提供相应机制使接收方能告诉发送方哪些数据丢失，哪些数据重发了，哪些数据已经提前收到了。如此大大提高了客户端与服务器端数据交互的效率，其确认和数据交互的过程如下图所示：

图 2 SACK确认和丢包后续数据交互示意图