某省移动公司网络业务回溯全过程（二）

中国移动通信集团作为全国乃至世界最大的运营商，业务量不断增大，各类业务系统的持续加入，网络规模也随之升级与发展，网络及业务故障、异常日益突出。

问题描述

为了能对网络中业务数据进行可视化的监控、分析、诊断，帮助管理员排除网络事故，规避安全风险，提高网络可用性，某省移动公司业务支撑部部署了科来网络回溯分析系统对门户网站，针对其BOSS系统，数据库等关键节点进行监控，并在日常运维中利用该系统协助分析并解决了大量问题。

分析价值

通过数据流进行解码快速分析与定位网络故障位置、分析应用流量确定故障原因，为排障以及优化网络资源提供可靠数据依据;通过长期监测网络带宽用量、能够建立网络基准，一旦出现异常流量能够迅速发现，减少故障恢复时间，甚至能在故障发生前消除故障隐患。

分析过程

本次案例讲解为第二次推送，按照网络分析逻辑，深入浅出讲解回溯分析全过程。请在“延伸阅读”阅读上篇。

缴话费业务故障分析

背景

月初缴话费业务大量交易超时情况。20台缴费服务器通过*.*.*.32访问BOSS系统*.*.*.249。*.*.*.32通过边界防火墙是会被NAT为*.*.*.1。

分析过程

出现超时告警时，在科来回溯上查看发现*.*.*.32访问*.*.*.249有部分连接显示状态为同步包已发送，即TCP连接没有建立成功。

提取会话可以看到这些TCP会话均为10个数据包，并且连接都没有建立成功。

正常建立连接时，*.*.*.249收到SYN包后应该回复SYN ACK包才能正常建立连接，并且SYN ACK包的Ack应该等于SYN包的Seq+1，如下左图。连接建立失败时，*.*.*.249收到SYN包后回复的是ACK包，并且该包的Ack字段与SYN包的Seq完全没有关系，因此TCP连接不能建立，SYN包重传5次后连接失败，如下右图。

通过移动省公司网状网端科来回溯上提取的对应会话对比，如下图。*.*.*.249回复的异常ACK包的Ack字段与上一个会话的FIN包Ack字段相等。说明在上一个会话还没有结束连接之前，客户端就重复使用了源端口建立连接，导致连接建立失败。

总结

经过上文分析，服务器在上一个会话还没有结束连接之前，就重复使用了源端口向省公司BOSS系统建立连接，导致连接建立失败。TCP连接建立客户端随机使用源端口与服务器建立连接，对于一个客户端IP源端口数量是有限的。当业务量增大，建立连接速度大于连接结束速度，并且持续一段时间导致可用源端口数耗尽。客户端就会使用到连接中的源端口，导致新连接无法建立。增加客户端的IP数量能够有效缓解业务量增大时，源端口达到上限而产生的新连接建立失败的现象。

数据库延时问题

月初缴费高峰缴费业务数据库出现大量延时告警，延时为1.302秒。

部署点一为应用服务器集群出口，该点发现1.3秒的延时是有重传导致的。

部署点二为数据服务器出口，该部署点没有发现重传包的原始包，说明数据在传输中被丢弃了。

为了找到抓包位置我们增加了部署点三，核心交换机入口，防火墙入口和防火墙出口。由于该交换机只能做一个镜像，因此三点只能镜像到一个口出，也就是说任何正常的包会被抓三次。如下图右，只有重传包的原始包只被抓到2次，其余包均被抓到三次。可以判断丢包只能是防火墙。

总结

月初缴费高峰移动电商缴费业务数据库出现大量延时告警，通过多段抓包对比发现延时是由于丢包造成的，丢包点位应用服务器区的防火墙。

-END-