Wireshark TS | 呼叫中心应用崩溃网络排查

问题描述

前段时间公司参加国家 HW，总体来说保障还是挺顺利的，但或多或少也是有一些小问题出现，现回顾记录一次呼叫中心业务应用系统崩溃的故障排查。

HW 开始之后，呼叫中心频频反馈坐席端应用闪退，出现掉线情况，给客户带来了不良体验，紧急上报至信息技术部进行相关排查。应用系统负责人检查内网客户端至服务器的 tcp 连接后，反馈说 tcping 端口偶尔无响应，因此怀疑内部网络不稳定导致。

问题处理

话说在分析疑似网络故障时，哪些是我们必须要做的，首先一定要具备争吵能力，不背锅。

🤣 嗯，有底气的可以这么干。

一般正常来说可能有以下几点：清楚故障现象、明确网络拓扑、梳理数据流向、合理部署抓包点等。

因应用系统负责人反馈交互较简单，且故障现象随机较频繁，在远端呼叫中心客户端侧暂无技术能力抓包的情况下，遂在服务器侧进行抓包，抓包点在服务器网关交换机上。

问题分析

首先根据上报的客户端1 IP 192.168.0.1 进行了数据包过滤抓取，观察是否有异常。

TCP 层面有会规律的建立即关闭连接，应该并不是什么问题，只是客户端和服务器之间的心跳包。再捞取唯一有数据字段传输的流，在相应时间内看起来也并没有什么问题，带 [PSH,ACK] 和 [ACK] 的数据包来回交互。

第一次分析尝试貌似并没有取到有用的信息，因此和呼叫中心同事强调客户端源IP以及应用闪退的时间点需进一步明确，要不服务器端的抓包分析很容易被大量数据包所掩盖。

第二次根据上报的问题客户端2 IP 192.168.0.2 ，服务器 IP 10.10.10.2 以及 故障时间点（1分钟内） 进行了数据包过滤抓取，如下

发现客户端主动 RST 了连接，网络上并没有出现因延时或丢包所造成的重传现象。在故障时点内观察该客户端与其他服务器的通讯，发现有同样问题，

客户端在同一时间点前后，同样主动 RST 了连接。根据相应数据包现象来看，问题更像是出在应用本身上面。

为进一步佐证结论，再一次回溯分析了客户端3 IP 192.168.0.3 在故障时间点的数据包，同样的现象，且无其他异常。

后续分析

根据业务所上报的问题现象，在不同的客户端、服务器以及不同的故障时间点，综合分析出问题并不是在内部网络上（包括呼叫中心和总部互连的专线），所看到的都是客户端行为，反馈应用系统负责人需进一步排查该应用上的故障日志。

后续应用系统负责人在客户端上调取应用日志，发现在故障时点上应用有调用服务失败现象，紧接着造成应用程序崩溃。后配合分析发现是该应用在办理某项业务时，会调用公网服务，即在呼叫中心本地客户端会产生从公网外出访问至总部数据中心 DMZ 区域的服务器，而由于安全 HW 要求，呼叫中心一刀切关闭了公网访问，因此造成了调用失败，导致应用崩溃，而在内网所抓取的数据包 RST 都是该应用崩溃关闭后所产生的后续行为，至此问题处理结束。

问题总结

回顾整个问题，最后所强调的仍然是开头提到的几点建议，

a. 清楚故障现象，明确问题所发生的行为，结合应用或系统日志综合分析；

b. 明确网络拓扑，定位客户端和服务器所处的位置，交互方式，判断可能发生的问题点；

c. 梳理数据流向，理清数据交互的走向、类型、规律，不要有所遗漏。

d. 合理部署抓包点，根据问题的不同，可能需要在客户端、服务器、网络设备前后进行一一抓包对比分析。

---

感谢阅读，更多技术文章可关注个人公众号：Echo Reply ，谢谢。