研究发现：网络原来如此之捷支付交易场景网络化践2022/12/26 14:43:44

哦不明白

捷支付业务在应用和络层面具有短连接、高频交易的特性，经过个关键阶段的络化，G行捷支付交易系统成功率明显提升，有力支撑了日常大量并发交易以及“双十一”、“双十二”等电商促销高峰时段业务访问。引言近年来，随着移动支付技术的发展和支付场景的普及，“扫一扫”付款已成为我们日常生活的重要组成部分，在日常消费、交通出行、社保医疗等重点领域和生活场景中，捷支付给我们带来很多便利。作为移动支付基础设施的关键环节，银行捷支付系统的稳定性将直接影响每一位消费者的支付体验。域名IP查询的具体问题可以到我们网站了解一下，也有业内领域专业的客服为您解答问题，为成功合作打下一个良好的开端！

鉴于捷支付业务的频繁交互需求，捷支付系统需应对日常庞大的交易请求，从络层面来讲具有高频短连接的特性，即连接速建立、速释放，此处说的连接是基于TCP(TCP)传输控制协议进行的。近年来G行持续开展捷支付络化，不断提升交易成功率，助力提升捷支付客户体验。

TCP协议简介TCP是一种面向连接的、可靠的传输通信协议，工作阶段分为建立连接、数据传输和连接终止，我们常说的五元组，即源IP地址、源端口、目的IP地址、目的端口和传输层协议（如TCP），共同组成一个连接。

为保证报文传输的可靠，TCP协议为每个报文设置一个序号，该序号也保证了传送到接收端体报文的按序接收，然后接收端体对已成功收到的字节回一个相应的确认(ACK)，如果发送端体在合理的往返时延(RTT)内未收到确认，那么对应的数据将会被重传。

首先，TCP协议通过“次握手”建立连接，过程如下图所示：



图1TCP协议次握手

1、客户端向服务器端发送标志位为SYN的TCP报文，随后客户端进入SYN-SENT状态；

2、服务器端收到来自客户端的TCP报文后发送一个标志位为SYN和ACK的TCP报文，随后进入SYN-RCVD状态；

3、客户端收到服务器端的标志位为SYN和ACK的TCP报文后发送标志位为ACK的TCP报文，随后进入ESTABLISHED状态，服务器端在收到客户端标志位为ACK的TCP报文后也进入ESTABLISHED状态，随后双方进入数据报文交互阶段。

在次握手完成后，客户端和服务器成功建立TCP连接，开始进行数据传输，数据传输完成后，TCP协议通过“四次挥手”终止连接，过程如下图所示（以客户端主动发起关闭连接为例）：



图2TCP协议四次挥手

1、由客户端主动发送标志位为FIN的TCP报文，随后进入FIN-WAIT-1的状态；

2、服务器端在收到客户端标志位为FIN的TCP报文后，发送一个标志位为ACK的TCP报文，随后进入CLOSE-WAIT状态；

3、客户端在收到服务器端发送的标志位为ACK的TCP报文后进入FIN-WAIT-2状态，服务器端在做好连接释放准备后主动发送标志位为FIN和ACK的TCP报文给客户端，随后进入LAST-ACK状态；

4、客户端在收到服务器端标志位为FIN和ACK的TCP报文后向服务器端发送标志位为ACK的TCP报文，随后进入TIME-WAIT状态，服务器端在收到客户端发送的标志位为ACK的TCP报文后关闭连接，客户端在等待TIME-WAIT状态（2个比较大报文存活时间）超时后也关闭连接。

捷支付架构介绍捷支付系统业务逻辑流程通常包括：商户端发起捷支付交易请求，通过运营商专线到达银行方中间业务DMZ区域，在银行内部经过防火墙、负载均衡或加解密等设备处理后与银行捷支付系统进行连接交互，每一笔交易会建立2个连接。具体过程如下：商户端首先通过“次握手”与银行加解密设备建立一个TCP连接（图3中所示连接1），商户发起交易请求至银行加解密设备对加密报文进行解密，随后加解密设备以代理模式（使用商户地址和端口），通过“次握手”与银行卡捷前置服务器建立一个新的连接（图3中所示连接2），经过银行后台处理后将交易处理结果返回商户。交易处理完成之后，由商户通过“四次挥手”终止与加解密设备的连接1，随后加解密设备终止与后端服务器的连接2。

为保障捷支付业务的安全平稳运行，G行部署了络流量分析工具，在多个络节点同时进行络流量时捕获分析，对捷支付交易进行监控，一旦发现失败交易就可以通过数据报文对每一笔失败交易进行回溯分析，作为持续化改进的依据。



图3捷支付架构示意图

表4所示是G行一笔捷支付交易中的两个连接流经各络路径的源目地址和端口情况。其中银行防火墙设备对交易进行访问控制，并对目的地址（即银行加解密设备地址）进行转换，一层负载均衡设备对加解密设备进行负载，二层负载均衡设备对卡捷前置服务器进行负载。



表4捷支付TCP连接源目地址和端口情况

负载均衡设备源端口速复用问题及化在前期日常运行维护过程中，运营人员反馈捷支付业务每天会有少量连接交易失败的情况，经过络管理员抓包分析发现为加解密设备有时会向商户方向主动发送R报文断链，与前文描述的商户主动关闭连接不符。络人员通过络流量分析平台逐笔逐包对异常交易连接进行深度分析，首先在产生断链告警的加解密设备侧进行络流量分析，确认加解密设备主动向商户方向发送了R报文，如图5所示：



图5加解密设备主动向商户方向发送R报文

为进一步确认问题根本原因，技术人员顺藤摸瓜，在一层负载均衡节点继续进行络流量分析，此时发现负载均衡源端口转换机制，由于端口转换导致速使用了前一个连接用的源端口，如图6所示：



图6一层负载均衡源端口速复用

速复用的原因为商户在通过“四次挥手”终止与加解密设备的连接1后，发送R报文速回收了这个连接，所以一层负载均衡和加解密设备均会速回收连接1，回收后下一个新的连接有概率的会出现复用前一个连接源端口的情况，此时因加解密设备已速回收前一个连接1，复用源端口的新连接1可以正常建立，如图7所示：



图7速复用源端口的连接1正常建链

正如前文所述，当新的连接成功建立后，加解密设备会使用连接1的源地址和源端口，发起和后端卡捷前置服务器（目的地址为二层负载均衡VS地址）的连接2，此时因连接2为标准的“四次挥手”断链，加解密设备向服务器端发送标志位为ACK的TCP报文后进入TIME-WAIT状态，在处理连接回收TIME-WAIT等待时间内不能接受相同五元组的新连接。在此时间内如果出现相同五元组的新连接，会导致新连接法正常建立，出现加解密设备向商户方向发送R断链的情况。而且交易量越大五元组冲突的可能性越高，交易失败的笔数及概率越高，在业务层面表现为客户已经发起的一笔捷支付交易失败，需要重新发起交易，影响客户使用体验。

在明确问题原因及原理后，络化的思路是避免因TIME-WAIT导致的连接2法正常建立问题，同时需保证各项化操作不会对际生产交易造成新的影响。在综合考量各个因素后，络技术人员分阶段开展化工作，首先将一层负载均衡设备源端口转换功能设置为不转换模式，即不再对商户发起的连接1的源端口进行转换，减少速复用前一个连接源端口的连接1出现的几率。化后每日连接重置的数量有一定下降，如图8所示。



图8一层负载均衡设备源端口保持化后连接重置交易变化情况

表9所示是化后一笔捷支付交易中的两个连接流经各络路径的源目地址和端口情况。



表9捷支付TCP连接源目地址和端口情况

商户源端口速复用问题及化在关闭一层负载均衡源端口转换设置后，络技术人员发现每日依然存在连接重置的情况，为此继续向靠近商户方向的节点进行络流量分析，发现商户在发出交易请求时就存在源端口速复用的情况，如图10所示：



图10商户侧源端口速复用

此时有两个方向的化思路，一是仿照解决一层负载均衡源端口速复用问题思路，减少相同五元组的连接1出现的几率。考虑到商户侧的源端口速复用不在G行络技术人员维护范围之内，化起来有一定难度，而商户侧会和银行加解密设备建立连接1，此时可以尝试从目的端进行化，以达到同样的效果。

在连接1的目的端为加解密设备提供负载的一层负载均衡设备默认使用“比较小连接数”的负载均衡算法，即根据后端服务器当前的连接情况，动态地选取当前积压连接数比较少的一台服务器，将商户发起的交易转发至多台加解密设备中的其中一台。相比“比较小连接数”负载均衡算法，“轮询”负载均衡算法按顺序轮流地将交易请求分配到后端服务器，后一个连接与前一个连接分配的目的地址不一致，从原理上来讲可减少相同五元组的连接1出现的几率，而在卡捷交易场景下，每台加解密设备上的连接处理机制一致，调整为“轮询”负载均衡算法后，每台加解密设备连接数也能相对保持均衡。

在经过充分测试后，络技术人员开展第二阶段络化，将一层负载均衡算法调整为“轮询”，调整后每日发生连接重置的交易笔数进一步下降，证明此步化也是有效的，如图11所示：



图11一层负载均衡算法化后连接重置交易变化情况

但此时仍有极少量连接重置情况发生，原因为捷支付交易量大，调整一层负载均衡算法为“轮询”后，仍有极少量速复用源端口的连接“轮询”到同一台加解密设备的情况，此时络技术人员考虑使用第二个化思路，即减少连接2回收等待的时间。如连接2可在较短时间内回收，此时即使连接1有相同五元组情况，连接2也可正常建立。如前文所述，连接2由加解密设备通过“四次挥手”关闭，加解密设备存在TIME-WAIT等待时间，TIME-WAIT时间的长短将决定连接2回收的时间。为此，经过充分测试并分批试点，络技术人员将加解密设备的TIME-WAIT时间由1秒调整为100毫秒。经过第阶段化后，每日连接重置交易数降为0，如图12所示：



图12加解密设备TIME-WAIT时间化后连接重置交易变化情况

表13所示是整体化后一笔捷支付交易中的两个连接流经各络路径的源目地址和端口情况。



表13捷支付TCP连接源目地址和端口情况

总结捷支付业务在应用和络层面具有短连接、高频交易的特性，经过个关键阶段的络化，G行捷支付交易系统成功率明显提升，有力支撑了日常大量并发交易以及“双十一”、“双十二”等电商促销高峰时段业务访问。

随着金融业务发展转型，为现高质量发展，G行信息科技部持续深化“123+N”数字银行发展体系，持续发挥科技动能，通过金融科技手段解决发展新挑战。络也将继续站在业务视角，关注各类重点业务交易场景，化分布式架构下络传输路径，提高交易响应速度，不断夯底层基础设施，持续化改进，提升客户服务和使用体验，助力银行业务再上新台阶。