正在与服务器确认支付信息,如何解决支付交易间歇性失败问题

间歇性业务故障往往是运维人员的工作难点之一，随着网络设备日渐增多，网络环境也变得更加复杂，但保障业务性能仍需要各个设备正常运行，因此故障排查难度也越来越大。本案例将通过解决由WAF设备异常引发的支付交易故障，为运维人员提供面对间歇性业务故障时的应对思路。

2.1　问题描述

某大学老师、学生在通过手机支付宝在线充值校园卡时，频繁发生显示交易成功但校园卡的充值金额迟迟未到账的现象，这在校园中产生了极其恶劣的影响。故障发生后，网络管理员逐一排查一卡通服务器、防火墙、网络等，均未发现明显异常，无法有效定位问题原因。随后故障又恢复正常，如此往复多次，无法得到解决。

为了定位和解决问题，科来网络分析工程师在相关网络中旁路部署了科来网络回溯分析系统。

图　2-1

2.2　分析方案设计

2.2.1　分析思路

该充值业务路径为“手机支付宝充值操作→阿里支付宝处理账务交易→支付宝向校园一卡通系统提交充值金额”。由于“手机支付宝充值操作→阿里支付宝处理账务交易”交易流量无法被监控，因此只能根据故障时间重点分析“支付宝向校园一卡通系统提交充值金额”这一环节，通过提取“充值立即到账”与“充值迟迟未到账”的报文比对分析差异。

21.2.2　分析过程

首先在链路：“6509_TO_出口”提取一卡通充值服务器(X.X.194.23)交易流量，如下图在HTTP请求日志中我们可以看到支付宝服务器(X.X.0.0/16网段)向一卡通服务器POST的URL均同为“/webservices-alipay/getway.ashx”，但是一卡通服务器应答有两种状态：

1、HTTP状态码为0

POST请求内容长度(Content-Length)为10180字节(此类交易会话数量较多)，产生原因可能是POST请求数据包未发到一卡通服务器，或是一卡通服务器收到POST请求但不回应，或是回应被中间设备阻断。

2、HTTP状态码为200(此类交易会话数量较少)

表明一卡通服务器成功回应POST请求，此时POST请求的内容长度在800左右字节。

由于第一种HTTP状态为0的会话数量较多，怀疑充值金额未到账原因可能与此类会话有关。

图　2-2

对此，我们抽样分析内容长度为10180字节的会话。如下图所示，对数据流重组解码可以看到支付宝POST请求的内容以“sign=”开头，其余为加密信息呈现，无法完全判断此类交易信息与充值金额有关。但不妨先看此类会话传输状况。

图　2-3

抽取X.X.242.226：18622-X.X.194.23：80端到端的分析，详情如下：

图　2-4

流量采集链路：教育网出口(防火墙外侧)

由于支付宝POST请求达10180字节，被拆分8个数据包(第4-11号数据包)且按序传输。同时一卡通服务器多次重传(ACK=3974050115，第14-18号数据包)，表明第6号数据包传输中丢包、或是后期才到服务器。

最后，服务器主动发送“FIN”断开连接(ACK=3974058835，第20号数据包)，说明一卡通服务器已全部接收到POST请求的内容，但为何未应答原因仍需继续分析。

小结：支付宝发送的POST请求被拆分成8个数据包，按序进入防火墙。

图　2-5

流量采集链路：6509_TO_出口(防火墙内侧)

根据TCP协议传输规范要求，每一个TCP数据包均携带有序列号(Seq)，根据载荷偏移量可计算出下一序列值(Next Seq)，在对端确认好ACK的值为Next Seq后本端向对端发送的下一个数据包的Seq值为上一个数据包的Next Seq 。

可以看到第4号与第8号数据包失序，第18号更是失序到最后才发送，才导致一卡通服务器一直重复ACK(ACK=3974050115)。最终一卡通服务器也接收了全部请求数据(第20号数据包)，但仍未见到一卡通服务器应答。

小结：支付宝发送的POST请求被拆分成8个数据包，乱序从防火墙发出。

图　2-6

流量采集链路：6509_TO_NIPS(WAF外侧)

传输状况与在链路：6509_TO_出口一致，结论一致。

图　2-7

流量采集链路：服务器区(N7K)(WAF内侧)

WAF内侧，即WAF与一卡通服务器中间采集点。未能检索同一时间段内支付宝服务器X.X.242.226会话，表明WAF未把支付宝POST请求发送给一卡通服务器，所以服务器一直无法收到支付宝的POST请求，也就无法应答。其他POST无应答会话也均未能在N7K链路上的流量检索到，所以此现象是共性问题。

回查之前可成功充值的交易会话，内容长度均未达到10180字节，所有POST请求均得到一卡通服务器的应答，如下图所示。

图　2-8

下图会话是从链路“6509_TO_出口”下载的数据包，按序传输且未出现重传等情况；同时POST请求内容以“sign=”开头，得到一卡通服务器成功应答。通过对比发现：充值故障发生时一卡通服务器应答http/1.1 200 OK的会话都是只有个单个POST请求包(POST请求数据较少)，并且POST请求内容以“service_type=”开头。再结合故障时间及故障现象，基本上可以判定支付宝如果通过POST内容以“sign=”开头的会话提交充值金额，那么该笔充值可立刻到账。

图　2-9

2.3　分析总结及建议

当支付宝充值的POST请求数据量较小时(如内容长度在2300字节及以下)，经过防火墙的请求数据包会按序传输给WAF设备，WAF设备也会将这些请求正常发送给一卡通服务器，充值金额立刻到账。当支付宝充值的POST请求数据量较大时(如本例内容长度达10180字节)，经过防火墙的请求数据包会乱序传输(POST请求被拆分成8个数据包)给WAF设备，但WAF并未将请求发送给一卡通服务器，直接造成一卡通服务器无法记账，因此出现充值无法及时到账现象。

综上可知充值无法及时到账是因为支付宝的充值请求终结在WAF防火墙，请求无法到达一卡通服务器造成。

科来网络分析工程师建议该校运维负责人联系WAF厂家进行详细检查，通过排查发现WAF设备异常是由其安全防护机制引发的，部分充值请求数据包被WAF设备认为是“加密攻击”而被丢弃，当关闭WAF设备的相关策略后，充值无法及时到账现象不再出现。

2.4　价值

传统排查方式很定位间歇性业务故障的根源，在问题发生时，仅凭经验排查安全防护策略、服务器等节点，未必能有效查明原因。对比传统排查方式，科来网络回溯分析系统拥有对间歇性业务故障强悍的解决能力。正如本例所示故障所示，虽然WAF设备没有相关告警日志，但是通过流量分析和回溯分析等技术手段，可以准确定位故障原因，为解决故障提参考。