通过时序图视角，看透TCP类业务故障

神券还不膨胀 · 发表于 2024-7-30 17:01:25

在IT运维监控与故障诊断工作中，传输控制协议TCP是无法避开的关键一环。熟练掌握TCP协议，可大幅提升IT工程师在实际工作中的技术水平，缩短故障处理时间。由于TCP协议的机制复杂，导致分析上手难且不便于观测其底层交互情况，因此若能以图形方式展示TCP的通信交互情况，则可大大降低理解TCP协议的难度。

什么是“交易时序图”，有哪些功能？

交易时序图是一种图形化的表示方法，用于描述系统中各个组件之间的交互过程和消息传递顺序。相较其它流量分析工具，交易时序图将TCP流量从枯燥的文字转化为图形，优化了用户对数据包发送方向、数据包载荷长度、数据包时间间隔等关键分析信息的展示方式，提升工具使用者的流量分析体验。

该功能如何使用？两个步骤即可进入该界面：

第一步：启动CSNAS流量分析以后，点击“TCP会话”视图，找到希望通过图形方式时序图分析的TCP会话，双击打开新窗口

图1：第一步

第二步：在新弹出的窗口中，依次选择“TCP交易列表”和“交易时序图”，CSNAS软件即开始根据此会话的原始数据包，展示此会话的TCP交易时序图

图2：第二步

交易时序图能体现哪些信息？

以图2为例，该交易时序图，体现了如下基本信息：

1、该会话共传输了10个数据包，其中序号为1、2、3的数据包为该会话的TCP三次握手过程，箭头被标记为绿色，该会话的三次握手成功完成。在某些无法访问、连接失败的故障分析场景，三次握手的建立情况可以判定故障是网络故障或非网络故障，对于网络运维人员来说，具有很高的分析价值。

2、序号4、5、6为该会话的HTTP交互过程，其中4号包和6号包传输了应用载荷数据，4号包为HTTP请求包，箭头右侧对应显示该数据包的应用载荷长度为990字节，6号包为HTTP应答包，应用载荷长度为1003字节，携带应用载荷数据的数据包对应箭头被标记为蓝色。5号包为TCP确认包，不含应用载荷数据，箭头被标记为黑色。该会话说明服务器进行了HTTP响应，在某些应用交易无响应的故障分析场景下，该信息可以用于分析应用的响应实际情况。

3、序号7、8、9、10的数据包为该会话的TCP四次挥手过程，四次断开成功完成。在一些会话无法断开，会话异常结束的场景下，分析会话的断开方式能够判断一些导致会话断开异常的故障原因，例如连接断开失败导致端口复用失败，连接异常结束错误等情况。

4、三次握手数据包箭头左侧的时间差显示，共花费了0.301秒，即301毫秒，这表示客户端与服务器之间的网络时延可能在301ms左右。其中，1号包与2号包的时间差为301毫秒，时序图中为这两个数据包箭头留了较多的留白，2号包与3号包的时间差<1毫秒，可以忽略不计，时序图中为这两个数据包箭头无留白。通过数据包箭头之间的留白信息，读者可以直观观察到网络时延情况，而无需紧盯数字进行时延分析。

上述的举例仅为交易时序图中的部分基本功能，实际分析过程中，通过该图能够得到更多分析结果。

正常的三次握手时序图应该是什么样的？

按照RFC 793，正常三次握手的工作过程如下：

1、SYN（同步）：客户端发送一个TCP的SYN（同步）标志的数据包给服务器，请求建立一个连接。这个数据包中的Seq序列号字段被填充为客户端ISN（初始序列号，Initial Sequence Number），Ack确认号字段为空，即全0。

2、SYN/ACK（同步确认）：服务器收到客户端的SYN请求后，如果同意建立连接，则会发送一个SYN+ACK标志的数据包作为应答。这个数据包中的Seq序列号字段被填充为服务器ISN，Ack确认号字段被填充为客户端ISN+1。

3、ACK（确认）：客户端收到服务器的SYN/ACK应答后，会发送一个ACK（确认）标志的数据包，确认收到服务器的初始序列号。这个数据包中的Seq序列号字段被填充为客户端ISN+1，Ack确认号字段被填充为服务器ISN+1

经过上述三次交互，客户端和服务器连接建立成功，双方进入TCP ESTABLISHED状态，可以开始传输数据。通过TCP交易时序图功能，只要看到双方三次握手交互完成，且三次握手包不存在重传、重复ACK、丢包等情况，则可以判断双方TCP连接建立正常，如图3所示：

图3：正常的三次握手

连接建立失败，包括哪些异常情况？

除正常的三次握手外，有时TCP还存在一些连接建立无响应的情况，如图4所示：

图4：连接建立失败——SYN包无响应

如果网络中出现了SYN包无响应情况，一般可能由如下原因导致：

SYN包未到达服务器。例如安全设备阻断、网络环路等原因。
SYN包顺利到达服务器，但服务器忽略了该SYN包。例如时间戳问题、TIME_WAIT状态、端口复用失败等原因。
SYN包顺利到达服务器，但服务器停止响应SYN包。例如TCP资源限制，遭受SYN Flood DDoS攻击等原因。
SYN包的目标服务器离线、宕机或网络中断。

SYN包无响应说明问题大概率出在网络层面，应先暂时停止应用层面的问题排查。具体原因应采用多点位对比分析法，分别在客户端、服务器、中间链路抓取数据包，进行进一步对比分析，判断具体结果。

如果遇到SYN/ACK包无响应或者ACK包无响应的情况，应当采用同样的多点位对比分析法进行对比分析，从而判断具体的连接建立失败原因。

当然，连接建立失败并不仅仅包含无响应问题，还有一种常见的情况，即RST（Reset）包的发送。RST包是TCP协议中用来进行“连接重置”的数据包，如图5和图6所示：

图5：连接在建立阶段被重置

图6：连接在其他阶段被重置

RST包的出现说明意味着连接被终止。由于RST包的发送机制和其背后的深层原因还有许多值得深入探讨的细节。因此在下篇文章《时序图看TCP：连接重置》中，我们将对RST包出现的多种情况进行深入探讨，各位读者敬请期待。

免费易用的流量分析工具下载

扫码关注公众号

更多网络分析技术、技巧、干货分享

- End -

延伸阅读

90%的攻击从邮件开始！如何解决邮件安全挑战

如何开展API安全管理？需要做到3点

防火墙策略无损验证，实时感知防护效果

解决两个数据问题，夯实工控数字化关键一步

漏洞梳理揭示关基威胁，科来阻止远程代码漏洞攻击

消除关基单位内部隐患，科来全流量揭示潜藏威胁软件

点击阅读原文，了解试用科来产品

通过时序图视角，看透TCP类业务故障

本帖子中包含更多资源

浏览过的版块