从微观世界的RST包文视角助力企业网络应用故障排查和优化

1. 前言

随着互联网的普及和发展，各行业的业务和应用越来越依赖于网络。然而，网络环境的不稳定性和复杂性使得出现各种异常现象的概率变得更高了。这些异常现象会导致业务无法正常运行，给用户带来困扰，甚至影响企业的形象和利益。因此，需要一种能够快速诊断和定位网络异常问题的解决方案。

网络抓包分析技术是一种常用的网络调试工具，它可以捕获网络数据包，并提供详细的数据分析和统计信息，帮助用户快速定位网络问题。其中，TCP RST报文是一种常见的网络异常现象，它通常表示连接被重置或中断，导致业务无法正常运行。

针对这种问题，NetInside全流量回溯分析解决方案（以下简称NetInside全流量），通过探针设备旁路收集和存储指定链路的全部流量数据，实现无人值守，对关键业务系统、应用和网络链路进行7×24小时、全方位的流量监控，智能学习关键性能指标的基线值，当出现网络异常、业务或网络相关状态达到阈值时，进行主动预警，并可以实时/事后对需要的原始包进行下载和分析解码，快速定位问题原因。

NetInside用以人为本的理念为信息部门量身打造了新一代全流量回溯分析系统，充分利用网络数据包建立覆盖重要链路、关键设备端口、核心服务的全面监控视图，并且按照网络部门的工作流程组织功能与操作，使其能够广泛适用于各种需要场景。

以服务为导向的全流量方法使NetInside系统能够直接体现网络基础架构对业务应用的支撑能力，提供实时故障诊断、告警触发、事后应用响应深度分析功能。整个系统从根本上简化了网络故障诊断、新应用和服务的部署以及降低了运营成本，并提供快捷的方式来实现故障定位。为分析网络攻击、定位异常，评估、判定用户体验、应用性能和网络服务质量提供可以信赖的数据依据。依托真实的网络流量，快速发现、定义应用，并提供数据正确性、变更结果验证能力，大大提升网络流量的可视化覆盖率和工作效率。运用先进的数据统计分析技术，发现、告警等功能极大简化了过去繁冗复杂的操作过程。

2. RST介绍

TCP RST（Reset）是一种TCP协议中的控制报文，位于TCP协议的传输层，用于终止TCP连接或拒绝非法连接。TCP RST通常由TCP连接的一方发送，它可以立即终止TCP连接，并通知另一方连接已经被重置。

TCP RST报文位于TCP报头中的控制位字段（Control Bits Field），该字段占据一个字节，它的第6位（RST）用来表示TCP RST报文。下面是一个TCP报头的示意图：

可以看到，TCP报头中的第13个字节（即控制位字段）的第6位表示TCP RST报文。当该位被设置为1时，表示发送TCP RST报文。

3. 常见产生RST的原因及确认方法

常见产生TCP重置数据包情况和原因有如下7种情况。需要注意的是，TCP重置数据包可能会对正常的TCP连接产生影响，因此应该谨慎使用。如果不确定是否应该发送TCP重置数据包，请先咨询网络管理员或安全专家。

3.1. 防火墙或网络设备对TCP连接的干预

防火墙或网络设备对TCP连接进行干预时，可能会发送TCP重置数据包来终止连接。

原因判断：可以通过查看防火墙或网络设备的日志，确认是否存在对TCP连接的干预行为。如果发现有TCP连接被终止且收到了TCP重置数据包，那么很可能是防火墙或网络设备发送的。

3.2. 端点认为该连接已经失效或存在异常

当TCP连接的一个端点认为该连接已经失效或存在异常情况时，它可以发送TCP重置数据包来终止连接。

原因判断：可以通过查看TCP连接的日志或网络抓包工具，确认是否存在TCP重置数据包。如果发现某一方发送了TCP重置数据包，那么很可能是该方认为连接已经失效或存在异常情况。

3.3. 攻击者可能会发送TCP重置数据包

在某些攻击中，攻击者可能会发送TCP重置数据包来终止连接或欺骗接收方。

原因判断：可以通过查看网络抓包工具，确认是否存在异常的TCP重置数据包。如果发现TCP重置数据包的源地址不明或与正常通信的IP地址不符，那么很可能是遭受攻击了。

3.4. 网络拥塞

当网络拥塞时，路由器或防火墙可能会丢弃部分数据包，从而导致TCP连接超时或失效。此时，连接的一方可能会发送TCP重置数据包来终止连接。

原因判断：可以通过查看网络抓包工具，确认是否存在丢失的数据包或TCP连接超时。如果发现TCP重置数据包是在网络拥塞期间发送的，那么很可能是因为连接的一方认为连接已经失效。

3.5. 程序异常

当应用程序或操作系统出现异常时，可能会导致TCP连接受损或失效。此时，连接的一方可能会发送TCP重置数据包来终止连接。

原因判断：可以通过查看应用程序或操作系统的日志，确认是否存在异常行为或错误信息。如果发现某一方发送了TCP重置数据包，那么很可能是由于程序异常导致的。

3.6. 超时

当TCP连接长时间没有活动时，可能会被认为已经失效。此时，连接的一方可能会发送TCP重置数据包来终止连接。

原因判断：可以通过查看TCP连接的日志或网络抓包工具，确认连接是否长时间没有活动。如果发现某一方发送了TCP重置数据包，且连接长时间没有活动，那么很可能是由于超时导致的。

3.7. 非法连接

当某些恶意程序或攻击者尝试建立非法的TCP连接时，连接的一方可能会发送TCP重置数据包来阻止该连接。

原因判断：可以通过查看网络抓包工具，确认是否存在非法的TCP连接请求或连接行为。如果发现某一方发送了TCP重置数据包，那么很可能是由于遭受非法连接请求导致的。

4. RST案例分析

下面将通过两个现场真实案例进行RST异常行为分析，快速帮助用户解决疑难问题。

4.1. 某省公安案例

4.1.1. 背景

集成指挥平台中有定时任务定时传输数据到总队，总队定时下发数据到市交警支队。市交警支队发现定时任务一直出现执行失败的错误。市交警支队和总队联系，说需要市交警支队排查一下自身网络，前两天在应用服务器上面抓了定时任务的数据包，发现在连接过程中一直被RST。现在不能确认在哪个环节被RST。

本次分析采用NetInside流量分析系统，已部署到业务环境，使用流量分析系统提供实时和历史原始流量。本次分析重点针对集成定时任务故障排查，以供设置取证、性能分析、网络质量监测以及深层网络分析。

4.1.2. 环境部署

市交警支队和交警总队采用专网专线方式互联，在市交警支队安全域集成指挥平台的核心交换机位置，将流量旁路方式镜像给NetInside流量分析系统，通过NetInside对定时任务流量进行采集和分析。

4.1.3. 分析时间

报告分析时间范围为：2023-05-19日白天工作时段。

4.1.4. 分析目的

针对集成指挥平台中定时任务出现执行失败原因进行分析，找出问题的根本原因，并采取相应的措施来解决这些问题。

通过分析，可以确定哪些因素导致了定时任务执行失败，如网络连接问题、系统故障、配置错误等。这样做可以帮助管理员及时发现和解决问题，确保集成指挥平台的正常运行。查找并验证确认是否存在业务系统健康问题。

4.1.5. 详细分析

以下对本次故障详细分析。

4.1.5.1. 流量传输存在明显时间间隔

通过分析系统秒级数据分布趋势发现，10.61.132.78（以下简称78）和服务器10.56.81.80（以下简称80）之间的数据传输存在明显的、有规律性的传输间隔现象。这极有可能受到某些未知因素的影响造成。

4.1.5.2. 数据传输间隔现象深入分析

从分析系统下载对应的数据包，发现大量的RST报文，如下图。

随机查看上图中一个会话信息（基于5元组的对话），发现存在异常现象。

下图中，Frame 19695之前的所有报文是一个正常POST请求操作，但Frame 20756和20757明显与前面的连接没有关系。

继续分析。

正常数据传输中，80到78流向的数据包TTL为119，如下图。

再看Frame 20756，同样是80到78流向的数据包，但TTL却为124。

同时，这个RST包还含有更多的应用层信息，可供参考。

而Frame 20757则是对上面这个RST报文的RST。

经过分析，在时长约43分钟的时间范围内，共出现了1846次类似的RST。

4.1.5.3. 异常RST对数据传输的影响

分析发现，当出现上述RST后，78会停滞一段时间，才会再次向80发起TCP握手请求，继而进行POST数据操作。

以下是随机查看的几个数据为证。

异常RST后，78等待8.19秒，才向80发起连接建立请求。

异常RST后，78等待13.14秒，才向80发起连接建立请求。

异常RST后，78等待34.34秒，才向80发起连接建立请求。

异常RST后，78等待58.43秒，才向80发起连接建立请求。

不再一一列举。

4.1.6. 分析结论

78与80之间数据传输时，会出现大量的未知系统或节点的RST数据包，该数据包同时会对78发起请求造成明显的时延作用。

4.1.7. 解决建议

由于异常数据包中含有地址及提示信息，可以根据这个信息定位发送RST的设备。也可以根据TTL信息，计算并定位该设备所处位置。

对发出异常RST的设备进行策略配置和优化。

4.1.8. 问题验证

针对异常RST进行分析，确定是由终端管控软件发出，管理人员对该软件做了相应设置，让其不再发出RST报文。

从NetInside流量分析系统中下载策略修改后，78与80之间的数据传输报文，打开查看，不再出现异常的RST报文。

同样，在一段时间内，一个异常RST都不再出现，如下图。

这说明终端管控软件策略设置有效。

4.1.9. 异常前后效率对比

最后，对异常前后，流量传输特征进行分析和比较。

4.1.9.1. 流量传输状况对比

以下是策略调整前78和80之间的数据传输情况。

以下是策略调整后78和80之间的数据传输情况。

通过对比可以看到，策略调整后，数据传输明显加快，且中间没有出现明显的间隔和空白等待时段。

4.2. 某电气化局案例

4.2.1. 背景

电气化局的用户反馈，近期视频系统在使用过程中出现频繁中断的情况，这种情况影响到用户的视频体验和工作效率。

针对此问题，我们将NetInside流量分析系统部署到电气化局机房，使用流量分析系统提供实时和历史原始流量。重点针对电气化局的视频系统进行故障分析，找出视频系统中断的具体原因。

4.2.2. 故障现象

通过用户反馈2023年2月8日7点20分出现视频中断情况，通过视频系统管理端看到视频流量有断开的情况，如下图：

4.2.3. 环境部署

在内网中心机房的视频区的汇聚交换机位置，将相关流量旁路方式镜像给NetInside流量分析系统，通过NetInside对所有视频流量进行采集和分析。

4.2.4. 故障分析

针对此问题，我们来进行详细分析。

4.2.4.1. 分析设备流量采集图

与现场网络人员沟通，了解真实网络结构，以下是视频会议的流量采集图：

流量采集图主要为：1台视频系统客户端，1台视频系统服务器，1台核心交换机；

视频系统客户端和视频系统服务器下方标注显示对应的MAC地址；

核心交换机分别标注显示对应的两个口的MAC地址；

核心交换机通过镜像方式将流量给到流量分析系统。

4.2.4.2. 分析思路

1、流量分析系统里找到异常数据包，下载数据包。

2、打开数据包，找到异常时间点的数据包内容。

3、分析视频数据包的协议和详细内容。

4.2.4.3. 详细分析

数据包下载

根据流量分析系统迅速找到异常节点，对数据包进行下载。

流量分析

流量分析系统对镜像后的流量进行去重功能，所以分析系统仅获取10.21.106.11发送到核心交换机的流量，及10.21.30.106发送到核心交换机上的流量。

正常传输

通过数据包分析看到，客户端10.21.106.11发给服务器10.21.30.106的mac地址为：Src：HuaweiTe_XX:XX:26 ————> dst：HuaweiTe_XX:XX:01。

通过数据包分析看到，服务器10.21.30.106发给客户端10.21.106.11的mac地址为：Dst：HuaweiTe_XX:XX:0f <———— src：EdgeCore_XX:XX:a8。

数据包内的TTL为64。

同时数据包带有VLAN协议，VLAN ID为59。

异常传输

通过数据包分析看到，视频中断时间点发现RST，数据包MAC地址异常，服务器10.21.30.106发给客户端10.21.106.11的mac地址为：src：HuaweiTe_XX:XX:01，dst：HuaweiTe_XX:XX:26，正常应为src：EdgeCore_XX:XX:a8，dst：HuaweiTe_XX:XX:0f。

数据包内的TTL为127。

未发现VLAN协议。