TCP流量分析06——TCP选项（转载）

因为不是自己写的文章，可能逻辑上和作者有点儿对不上。科来应该是从实际解决网络故障为出发点，所以知识点有那么一点点跳跃，讲完四次挥手就开始讲TCP选项相关内容了，TCPFlag之类的没有讲，我先还是进行转载吧，空了再按照自己思路整理一下，把TCP数据包解码和一些科来略过的小知识点补充一下。以下为转载文章：

  什么是TCP选项？

选项是TCP包头的一个灵活扩展部分，用于实现一些额外的功能。TCP选项按需携带在数据包的尾部，是否携带取决于有没有使用额外的扩展功能。正常情况下，不携带TCP选项的包头长20字节，携带选项的TCP包头最长可达60字节（20字节包头+40字节选项）。

说得直白些，选项是为了TCP后期增加扩展功能使用的。

  TCP选项，长啥样？

TCP选项的格式，为“类型、长度、数值”，一个选项的长度从1-40字节不等。例如在“02 04 05 B4”这一串HEX字节流中，02为选项类型，说明该选项的功能作用，04是长度，说明该选项长度为4字节，05 B4为该选项的数值，将HEX转换为十进制，为1460，说明该选项的数值为1460。

图1：TCP选项的结构

常见TCP选项包括MSS、WSOPT、EOP、NOP、SACK、时间戳，本文讨论前三种，其它选项将在后续文章讨论

  EOP与NOP，这两种选项有何作用  

先介绍两个简单的：EOP和NOP

EOP是End of option list的缩写，译为“选项结束”

NOP是No-Operation的缩写，译为“无操作”

这两种选项为单字节选项，只需占用1字节的空间，仅描述类型即可，无需描述长度和值。EOP选项类型为00，NOP选项类型为01，两种选项可以连续使用，例如0000或者0100。

如果只从名称上来看的话似乎不好理解这两个选项的作用，实际上，这两种选项可以理解为“选项结尾填充符”和“选项间填充符”。简单来说，这两个选项没有实际意义，主要用于“填充”。

因为TCP的包头必须是4字节的倍数，包括选项在内，携带选项的包头也必须是4字节的倍数：

图2：TCP的NOP选项

如上图所示，图中只截取了TCP选项部分，图中依次出现了5个选项，5个选项的长度分别为4字节、2字节、10字节、1字节、3字节，相加后总选项长度为20字节。其中第四个长度为1字节的选项即为NOP选项，其作用为将19字节的总选项长度填充为20字节。

  什么是MSS选项？和MTU有什么关系？

MSS（Maximum Segment Size）用于指定在TCP连接中，双方可以发送的最大数据段的大小。MSS的取值一般受MTU（Maximum Transmission Unit）的限制。MTU包括IP头部、TCP头部以及数据载荷（Payload），在以太网线路中，MTU一般为1500字节；而MSS仅指数据载荷部分的大小，一般取值为MTU-20-20。因此在一般情况下，以太网中的MTU为1500，MSS为1460。

  如果通信双方的MSS值不同，应当以谁的MSS为准？

TCP在连接建立时的三次握手过程中，客户端和服务器会交换MSS值以进行协商，将双方中较小的MSS值用于后续通信中的实际使用。客户端和服务器的MSS值，携带在SYN包和SYN/ACK包的TCP MSS中传输，如下图所示：

图3：SYN包中的MSS选项，声明客户端的MSS为1460

图4：SYN ACK包中的MSS选项，声明服务器的MSS为1380

双方经过MSS交互后，取较低值1380为本次会话双方通信的MSS，后续，客户端发送给服务器的数据包MSS不超过1380，通过实际观察“载荷长度”的数值，客户端后续发送的数据包载荷长度为1368，比MSS少了12字节，这是由于客户端携带其它TCP选项，占用12字节MSS导致。

图5：12字节的其它TCP选项，占用12字节MSS

总结：MSS选项限制了单个TCP包携带载荷数据的大小。在分析一条TCP会话时，可以通过三次握手的SYN包和SYN/ACK包中的MSS选项，来观察双方协商MSS的结果，并根据时序图中的“载荷长度”对MSS进行综合判断。

看完这些，你是否已经了解了MSS的基础作用、协商过程以及通过流量分析观察MSS的方法？

  MSS可能导致的故障有哪些？有什么分析方法？

由于MSS协商过程只由客户端和服务器两端参与，并不考虑中间网络设备的MTU，因此可能出现协商MSS为1460，中间的小MTU设备实际能传输的MSS比1460小的情况，这种情况将导致MSS为1460的数据包必须经过中间小MTU设备的IP分片才能进行传输。

现如今的操作系统，为了避免IP分片带来的网络故障，已经默认为TCP协议数据包启用了IP层DF位，禁止数据包被中间设备进行IP分片，如下图所示：

图6：客户端和服务器双方均为TCP流量默认携带DF位

当DF位遇到小MTU设备，数据包只能被小MTU设备丢弃。数据包由于DF原因被丢弃后，丢弃数据包的设备会发送一个“ICMP 目的不可达”包（type=3,code=4）进行通知。若怀疑数据包由于DF原因被丢弃，可参考数据包丢弃后是否有相关ICMP目的不可达包。

除MSS、DF位、小MTU设备组合导致的故障外，关于MSS的故障可能还有隧道原因。在数据包经过GRE、VxLAN隧道或PPPoE传输的场景下，这些隧道协议会增加额外的数据包封装开销，如果仍将MSS设置为默认的1460字节，可能导致IP数据包在封装后的总长度超过默认MTU 1500。如果IP数据包恰好默认携带DF禁止分片位，这些经过隧道的数据包将由于无法分片导致被丢弃。为此，某些业务服务器通过设置降低MSS为1400或1300以规避此类问题。

当前，一些防火墙、负载设备，支持干预通信双方的MSS，这些设备通过篡改数据包的MSS数值，从而实现迫使双方协商为管理员预定的MSS数值，使得数据包“不用分片，相对安全”。

  典型的故障实例  

放一张图，大家可以分析下这个时序图，尝试分析故障：

图7：故障流量

如图所示，抓包位置在客户端，通过序号5数据包的载荷长度能够看出，双方协商的MSS在1448以上。而序号9和序号10数据包的Seq不连续，中间有数据包丢失。两包的Seq相减计算，判断丢失了长度为1448的数据，按照MSS协商结果，丢失的数据包数量应该是一个。运维人员通过对多个类似故障会话的分析，发现每个会话情况均是如此。你能判断导致故障的原因吗？

本文转载自：从时序图看TCP：有关MSS分析技巧，让故障排查事半功倍

非原创