集成指挥平台定时任务故障流量分析

01故障现象

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

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

02分析目的

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

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

03部署架构及流量采集

通过与网络技术人员沟通了解，街道的电脑端在通过区县向市局传输数据时，出现连接被RST，网络上属于三个区域，分别为街道区域、区县区域和市局区域。经过分析，我们将NetInside以旁路方式部署到区县机房，将核心交换机镜像流量给NetInside，该位置可以抓取到定时任务数据全部流量，可以对异常进行全面分析。

04分析过程

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

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

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

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

从分析系统下载对应的数据包，发现大量的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。

异常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发起连接建立请求。

不再一一列举。

05分析结论

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

06解决建议

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

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

07问题验证

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

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

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

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

08异常前后效果对比

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

流量传输状况对比

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

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

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

09作用和价值

用户遇到网络异常问题，现场的专业技术人员多次进行分析，但是问题的定位依然无法确定，这给用户耗费了大量的人力和时间。为了解决这个问题，我们采用了NetInside全流量行为分析技术，能够快速发现异常和风险的原因。通过这项技术，用户的位置从被动变为主动，真正解放了他们不必要的人工故障诊断和数据包分析所消耗的时间和精力。