11.11任性买的背后，科来告诉你一个不了解的世界
11.11使得网络流量疯狂攀升，当你挥汗血拼的时候，是否了解电商平台和银行服务器正承受着极大的压力，是对电商平台及银行的网络配置和运维的极大考验。
那么，他们是如何做到让你在付款的时候不会因此受到丝毫影响呢？其实，各大银行在双11来临之前都要进行应对电商支付的压力测试。下面我们通过一个真实的案例详细了解一下：
某银行和支付宝配合做压力测试的时候出现大量交易失败、交易数量提升不高等问题，银行内部网络部门和应用维护部门为这些问题忙得不可开交，但却始终找不到问题根源所在…
该银行在部署科来网络回溯分析系统之后，问题迎刃而解。
一、设备部署情况
该银行利用科来网络回溯分析系统多级监控能力在生产网络的关键区域都设置了数据捕获点，下图是本次支付宝业务测试的数据采集示意图
二、效果展示
测试初始阶段，支付宝的交易出现大量交易失败的情况，交易成功率仅有50%。工程师在科来设备上迅速找到造成大量交易失败的原因。对比分析防火墙内外两侧的数据：在防火墙外，工程师看到大量来自客户端的TCP SYN报文，但是服务器没有给出回应：
在防火墙内，工程师看到服务器对客户端的SYN应答了SYN-ACK报文，但是却很快发送了ACK-RST报文：
对比在防火墙外看到的情况，可以断定这些ACK-RST报文是由防火墙发出的。工程师将这些情况向银行网络人员做了说明，经过咨询该防火墙厂家，发现是有该防火墙的防攻击模块造成了对正常SYN报文的阻断。将该防火墙更换为另外一个厂家的后，交易成功率提高了不少。
在第二阶段测试中，发现交易量一旦达到一定量，交易数目就上不去了。但是这个交易量远远没有达到之前的设计目标，系统运维人员怀疑银行内部某个网络设备存在处理瓶颈。
工程师通过科来网络回溯分析系统的应用监控统计该业务的TCP交易情况：
通过分析，发现连接被重置多数是由服务器发出。客户端向服务器发送一些数据，服务器也很快对这些数据进行了确认，但是客户端还是不断向服务器发送相同数据。
如下图中客户端发送ACK-FIN报文后，服务器进行了确认，但是客户端还是不断发送ACK-FIN，随后服务器发送ACK-RST报文期望结束连接。这个过程重复进行了多次，说明通过客户端的链路存在丢包，客户端并没有收到服务器回的ACK包和后续的ACK-RST包：
工程师在统计服务器状态时发现在交易数量达到一定量后，服务器对客户的TCP新建连接不再响应：
工程师统计出各个服务器无响应的比例：
通过这两方面的分析知道：
1、通往支付宝客户的链路存在丢包的情况
2、服务器处理在高峰期的处理性能也有问题
工程师将这些情况告知银行工作人员后，服务器运维人员针对服务器进行了优化，同时通知运营商排查MSTP线路，结果发现运营商对这条链路的带宽只配置了2Mbps，少配置了8Mbps！银行工作人员和运营商处理完以上情况后，交易量出现了大幅度上升：
同时，通过定义上行RST发送情况监控应用服务质量
这样，通过应用告警，可以迅速得知支付宝业务质量情况以及出现故障时的方向。在“双十一”当天，该行人员利用前期科来工程师做好的监控配置，针对支付宝业务进行了监控分析：
可以看出在“双十一”当天，交易高峰期出现在凌晨零点到1点之间，其次在11月11日白天，也有大量的交易。通过查看应用监控告警，可以看到在高峰期出现了一些交易失败的情况：
经过统计，90%以上的交易失败都是由服务器响应慢造成的，可以通过科来专家分析系统对这些交易失败的情况进行详细分析：
注：交易对比-左侧为异常交易，右侧为正常交易
由此可以看出，如果要应对以后更高的支付宝交易的话，需要增强服务器的处理性能，同时也需要继续扩充支付宝链路带宽。
11.11使得网络流量疯狂攀升，当你挥汗血拼的时候，是否了解电商平台和银行服务器正承受着极大的压力，是对电商平台及银行的网络配置和运维的极大考验。
那么，他们是如何做到让你在付款的时候不会因此受到丝毫影响呢？其实，各大银行在双11来临之前都要进行应对电商支付的压力测试。下面我们通过一个真实的案例详细了解一下：
某银行和支付宝配合做压力测试的时候出现大量交易失败、交易数量提升不高等问题，银行内部网络部门和应用维护部门为这些问题忙得不可开交，但却始终找不到问题根源所在…
该银行在部署科来网络回溯分析系统之后，问题迎刃而解。
一、设备部署情况
该银行利用科来网络回溯分析系统多级监控能力在生产网络的关键区域都设置了数据捕获点，下图是本次支付宝业务测试的数据采集示意图
二、效果展示
测试初始阶段，支付宝的交易出现大量交易失败的情况，交易成功率仅有50%。工程师在科来设备上迅速找到造成大量交易失败的原因。对比分析防火墙内外两侧的数据：在防火墙外，工程师看到大量来自客户端的TCP SYN报文，但是服务器没有给出回应：
在防火墙内，工程师看到服务器对客户端的SYN应答了SYN-ACK报文，但是却很快发送了ACK-RST报文：
对比在防火墙外看到的情况，可以断定这些ACK-RST报文是由防火墙发出的。工程师将这些情况向银行网络人员做了说明，经过咨询该防火墙厂家，发现是有该防火墙的防攻击模块造成了对正常SYN报文的阻断。将该防火墙更换为另外一个厂家的后，交易成功率提高了不少。
在第二阶段测试中，发现交易量一旦达到一定量，交易数目就上不去了。但是这个交易量远远没有达到之前的设计目标，系统运维人员怀疑银行内部某个网络设备存在处理瓶颈。
工程师通过科来网络回溯分析系统的应用监控统计该业务的TCP交易情况：
通过分析，发现连接被重置多数是由服务器发出。客户端向服务器发送一些数据，服务器也很快对这些数据进行了确认，但是客户端还是不断向服务器发送相同数据。
如下图中客户端发送ACK-FIN报文后，服务器进行了确认，但是客户端还是不断发送ACK-FIN，随后服务器发送ACK-RST报文期望结束连接。这个过程重复进行了多次，说明通过客户端的链路存在丢包，客户端并没有收到服务器回的ACK包和后续的ACK-RST包：
工程师在统计服务器状态时发现在交易数量达到一定量后，服务器对客户的TCP新建连接不再响应：
工程师统计出各个服务器无响应的比例：
通过这两方面的分析知道：
1、通往支付宝客户的链路存在丢包的情况
2、服务器处理在高峰期的处理性能也有问题
工程师将这些情况告知银行工作人员后，服务器运维人员针对服务器进行了优化，同时通知运营商排查MSTP线路，结果发现运营商对这条链路的带宽只配置了2Mbps，少配置了8Mbps！银行工作人员和运营商处理完以上情况后，交易量出现了大幅度上升：
同时，通过定义上行RST发送情况监控应用服务质量
这样，通过应用告警，可以迅速得知支付宝业务质量情况以及出现故障时的方向。在“双十一”当天，该行人员利用前期科来工程师做好的监控配置，针对支付宝业务进行了监控分析：
可以看出在“双十一”当天，交易高峰期出现在凌晨零点到1点之间，其次在11月11日白天，也有大量的交易。通过查看应用监控告警，可以看到在高峰期出现了一些交易失败的情况：
经过统计，90%以上的交易失败都是由服务器响应慢造成的，可以通过科来专家分析系统对这些交易失败的情况进行详细分析：
注：交易对比-左侧为异常交易，右侧为正常交易
由此可以看出，如果要应对以后更高的支付宝交易的话，需要增强服务器的处理性能，同时也需要继续扩充支付宝链路带宽。
