TCP长连接负载均衡在大型银行渠道中的应用

劳 伟

(中国农业银行股份有限公司 软件开发中心，北京 100073)

0 引言

银行渠道系统既要作为服务端接收ATM、POS等本行外围设备以及银联、国际银行卡组织等行外系统的交易请求，也要作为客户端将交易请求转发至本行后台系统以及银联、VISA、Mastercard、美国运通、大莱、JCB等银行卡组织。银行渠道系统不仅需要7×24小时不间断运行，还需要具备在春节、国庆等交易高峰期平稳运行的能力。

银行渠道系统与关联系统之间通常基于TCP协议进行消息交互。TCP作为一个面向连接的协议，传输数据之前，需要在客户端与服务端之间建立连接，数据传输停止后，需要终止连接以释放资源。建立连接需要三次握手，断开TCP连接需要四次挥手[1]。

银行渠道系统为支撑核心业务，普遍采用集群部署方式实现高可用、高可靠和可扩展。建立连接属计算密集型操作，频繁交互场景下不适合采用短连接通信方式，故银联、VISA、Mastercard等银行卡组织均要求成员机构采用长连接入网方式[2-4]，因此银行渠道系统面临着如何实现长连接负载均衡的问题。

客户端和服务端完成一次消息交互后即断开TCP连接的方式为TCP短连接。建立TCP连接后进行多次消息交互，直至客户端或服务端退出时终止连接的方式为TCP长连接。采用传统负载均衡模式时，每条客户端长连接仅能接入服务集群中的1个节点，各节点的负载并不均衡，无法动态调整节点数量。

为应对上述问题，本文提出了基于F5公司的OneConnect、MBLB技术实现的TCP长连接负载均衡方案，方案已经过大型银行渠道系统的长期实践检验，取得了优化连接、节约资源的预期效果。

1 传统负载均衡模式现状分析

经过多年发展，传统负载均衡模式产生了若干类型，主要类型有：

(1)基于DNS轮询的负载均衡

DNS为同一域名配置多个IP地址，客户端查询域名时获取其中的一个IP地址以实现负载均衡[5]。DNS负载均衡常用于Web集群服务。

(2)基于代理服务器的负载均衡

通过代理服务器将请求分发至多台服务器以实现负载均衡。Linux下可用LVS实现代理服务器[6]。

(3)基于NAT的负载均衡

网络地址转换(Network Address Translation，NAT)是一种将外部IP映射为多个内部IP的技术。Linux内核已包含NAT负载均衡功能，通过客户端动态连接一个内部IP的方式实现负载均衡[7]。

本质上传统负载均衡模式是从服务端集群中选择1个服务节点进行连接，如图1所示。

图1 传统负载均衡模式示意图

因此传统负载均衡模式适用于TCP短连接的场景，在TCP长连接场景下达不到负载均衡的效果。

2 频繁交互场景下TCP短连接存在的问题

频繁交互的应用场景下采用TCP短连接的通信方式，存在TIME_WAIT状态套接字过多、CPU及内存资源消耗过高、吞吐率偏低等诸多问题。

2.1 TIME_WAIT状态套接字过多

频繁建立、拆除TCP短连接，系统内核中将不可避免地出现大量处于TIME_WAIT状态的套接字。

TIME_WAIT状态又称为2MSL等待状态。TCP协议规定主动关闭连接一方的套接字在发送最后一个ACK后进入TIME_WAIT，等待2倍报文段最长存活时间(Maximum Segment Lifetime， MSL)之后，转入CLOSED状态，内核释放CLOSED状态的套接字资源。

MSL是TCP报文段在网络上的最长存活时间，超过MSL的报文段将被网络设备自动丢弃。RFC 1122建议将MSL设为2 min，Berkeley TCP的MSL为30 s。

RFC 1185描述了TCP协议设置TIME_WAIT的两个理由：

(1)可靠终止TCP连接的两个方向(全双工关闭);

(2)等待网络设备丢弃已关闭连接的重复报文段。

简而言之，主动关闭连接一方保存关闭连接的传输控制块(Transmission Control Block,TCB)至2倍MSL，是为了防止主动关闭连接一方新建连接四元组信息(源地址、源端口、目的地址、目的端口)与仍在网络中传输的旧连接重复报文段出现重复。

主动关闭TCP连接的状态转换过程如图2所示。

图2 主动关闭TCP连接的过程

内核为新建连接创建TCB以保存TCP连接四元组等重要信息，并通过TCB列表管理连接。接收TCP报文时，内核检索TCB列表将分解的应用报文交给对应的套接字。

系统能够保存的TCB数量不仅取决于内核内存的大小，而且取决于系统中的TCP连接状态。当系统存在大量TIME_WAIT状态的TCP连接时，内核维护TCB列表的开销将会增长，甚至会因资源消耗过多出现系统服务中断的情况。

目前国内几家大型商业银行渠道系统的日交易量均为千万级别，支撑的核心业务交易峰值已过万级TPS。从投资效益角度看，渠道系统的配置不会很高，在资源有限的条件下，采用短连接意味着渠道系统的内核中要保存大量处于TIME_WAIT的TCB。

以中国农业银行卡受理中心系统为例，该系统处理能力为3 000 TPS，基于Linux集群部署，MSL为30 s。如果采用TCP短连接，理论上则需保存18万个TCB，按50个节点计算，各节点需保存3 600个TCB。有研究者在传输速率640 Mb/s的Myrinet局域网环境下进行了测试，结果显示1台安装了SunOS 4.1.3系统的SPARCStation 20/71工作站最多支持每秒60个TCP短连接[8]。

2.2 减少TIME_WAIT状态的风险

为避免TIME_WAIT过多消耗系统资源，网络上出现了各种修改内核参数减少TIME_WAIT的措施。如缩小Windows注册项HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters中的TcpTimedWaitDelay数值，启用Linux系统内核参数net.ipv4.tcp_tw_reuse、net.ipv4.tcp_tw_recycle。

在NAT环境下使用上述方法将会导致网络通信出现异常。

采用上述方法时需要NAT设备转发TCP包时重写TCP时间戳、转发新建TCP连接请求时重新生成TCP初始序列号(Initial Sequence Number,ISN)。当前NAT协议规范中并不包含上述功能，在NAT环境下减少TIME_WAIT的风险很高，原因如下：

RFC 1323规定TCP时间戳由报文发送方设置，主要用于往返时间测量(Round-trip Time Measurement，RTTM)和TCP序列号回绕保护(Protect Against Wrapped Sequences,PAWS)，Linux的TCP时间戳是系统启动至今经历的毫秒数量。新建连接时随机设置ISN的目的是为了防止攻击者猜测报文序列号、伪造TCP报文攻击系统。

RFC 1337 (TIME-WAIT Assassination hazards)公告所列网络故障案例的根源均和主动关闭连接一方提前回收或重用TIME_WAIT状态套接字有关。提前回收或重用TIME_WAIT套接字时，仅支持标准协议的NAT设备将自动重用旧连接四元组，并由此导致TCP时间戳或ISN出现乱序，最终引发连接超时、连接劫持、拒绝服务等网络异常[9]。

3 TCP长连接负载均衡面临的挑战

TCP长连接没有TIME_WAIT的问题，但是设计长连接负载均衡方案时将面临健康检查、并发连接数、无状态服务、消息边界等诸多挑战。

3.1 健康检查

健康检查是指检查网络设备、服务系统的运行状况，及时发现事件故障、潜在问题和性能瓶颈，为优化调整网络设备、服务系统提供决策支持[10]。通常采用发送检查报文的形式检测集群节点的健康状态，长连接方式下需要设计合适的检查机制，确保健康检查涵盖所有的节点。

3.2 并发连接数

采用TCP长连接时，服务端需要限制同一客户端的连接个数，以防止客户端频繁建立连接耗尽服务端的资源。

以银联为例，大型入网机构和银联之间的连接数限制通常为8进8出16条TCP单工长连接，小型入网机构的连接数限制通常为2进2出4条TCP单工长连接。

3.3 无状态服务

一笔银行交易的处理过程中可能包含多次消息交互，为了实现负载均衡，需要将其中的各个消息分发至服务端集群中的不同节点，因此服务端系统需要实现无状态服务。相比短连接，长连接方式下实现无状态服务的方法更为复杂。

3.4 确定消息边界

负载均衡设备(或负载均衡软件)从客户端长连接收到的数据中可能包含多个消息。为了将各个消息分发至服务端集群中的不同节点，各个消息需要有明确的边界信息，如消息长度(如HTTP报文头的Content-Length)或消息起始标记。

4 TCP长连接负载架构

针对长连接负载均衡面临的上述挑战，有研究者设计了基于软件实现的TCP长连接负载均衡器，通过非阻塞带优先级的事件调度模型处理连接建立、健康检查、负载任务分派、进程间通信、响应接收和报文转发，通过虚拟IP加双机主备部署负载均衡器的方式消除单点风险[11]。

相比专业的负载均衡设备，负载均衡软件在算法、带宽占用、加速比、可靠性、可维护性、可扩展性等方面还存在一定的差距，因此银行更倾向于选择相对成熟的专业设备实现核心业务的负载均衡。

本文提出的TCP长连接负载均衡方案正是基于当前金融行业广泛使用的F5公司的负载均衡设备，方案采用了OneConnect、MBLB等F5提供的技术。

4.1 OneConnect连接聚合技术

新建连接属计算密集型过程，不仅耗费CPU资源，而且还要为连接状态和通信缓存区分配内核内存，为减少资源消耗，HTTP/1.1已将keep-alives作为默认标准。TCP连接数越少，不仅意味着应用线程/进程数越少，应用线程/进程上下文切换的频率越低，而且意味着消耗的系统资源越少，系统有效容量越高。

OneConnect为同步处理方式，该方式通过重用服务端TCP连接、减少连接数，减轻服务器负载及带宽成本。

OneConnect方式默认支持HTTP连接聚合，F5收到服务端响应后，将服务端连接放入连接重用池；收到客户端连接请求时，从连接重用池中选出一条可重用的服务端连接；通过配置iRules规则(F5可编程网络语言，tclsh脚本)实现TCP连接聚合[12]。

F5提供Source Mask配置项以限定服务端连接重用的客户端范围。比如设为255.255.255.255限定连接重用池中的连接仅供原连接客户端使用。

如图3所示，基于OneConnect聚合ATM连接时，F5通过重用服务端长连接将ATM交易报文转发至渠道集群中的服务节点；服务节点通过原连接将应答返回给F5之后，不关闭连接以支持F5重用连接。

图5 基于MBLB技术均衡网控器接入POS业务的方案

4.2 基于消息进行负载均衡的MBLB技术

MBLB(Message Based Load Balancing)是F5公司基于消息进行负载均衡的技术，采用MBLB分发的消息需要包含长度或起始标记等边界信息。F5通过配置的iRules规则识别TCP数据流中的消息边界[13]，从中拆分出相互独立的消息，将每个消息作为负载均衡的基本单元，依据配置的策略分发至各服务节点，分发过程如图4所示。

图4 不间断接收消息场景下MBLB分发负载过程示意图

MBLB为非阻塞异步处理方式，采用该方式的客户端或服务端可持续向对端发送消息，不必等待对端响应。

MBLB方式下，F5默认为每条客户端连接建立一组连通服务集群所有节点的长连接，用户可通过配置限制F5与各服务节点之间建立的连接数量。

MBLB适用于均衡网控器接入的POS业务。网控器接入的POS报文包含报文长度及标记POS通信线路的TPDU(Transport Protocol Data Unit)信息。网控器的每块上联卡可与渠道系统建立一条TCP双工长连接，通过这些连接向渠道系统转发POS请求、异步接收渠道系统的应答，依据应答中的TPDU将应答报文返回给对应的POS。采用MBLB均衡POS业务的方案如图5所示。

VISA、Mastercard等国际银行卡组织与入网机构之间采用TCP双工长连接方式发送联机交易请求、异步接收联机交易应答，交易报文中包含报文长度信息，适于采用MBLB方式进行负载均衡。

银联与入网机构之间的联机交易报文包含报文长度信息，但是采用收发分离的TCP单工长连接方式进行通信，因此采用MBLB均衡时需分别设计发送端、接收端的iRules规则。为保证处理过程的连续性，渠道服务节点可在发给银联的检索参考号字段中设置当前节点标识，由F5根据配置的iRules规则解析银联应答报文,从银联应答的检索参考号字段中取出节点标识，依据节点标识将应答送回对应的节点。

4.3 银行渠道系统TCP长连接负载均衡整体架构

银行渠道系统负载均衡整体架构如图6所示，其中同步、异步指接收应答的方式。

图6 银行渠道系统TCP长连接负载均衡整体架构

4.4 技术可行性测试

使用LoadRunner模拟客户端，80%的请求报文长度为200～300 B，20%的长度为1 200～1 400 B。

在一台F5 BIG-IP LTM设备上开启两个测试端口，分别配置OneConnect及MBLB iRules规则。

测试服务端为一台64位SuSE11.3虚拟机，CPU配置为AMD 6234 2.4 GB×2、内存配置为4 GB。测试服务程序开3个TCP端口模拟3个节点，线程池最大容量为10 000。测试服务程序收到请求报文后随机等待0～2 s模拟后端系统延迟，然后将请求报文直接返回给客户端模拟后端系统应答。

(1)OneConnect聚合连接技术测试

LoadRunner模拟50个客户端，持续发压时间5 min。各客户端持续多轮测试，每轮测试建1条连接到F5，发送1笔请求、收到1笔应答后关闭连接。接收应答的超时时间为3 s。测试结果如表1所示。

表1 OneConnect聚合连接技术测试

(2)MBLB消息均衡技术测试

LoadRunner模拟50个客户端，持续发压时间为5 min。各客户端建立1条长连接到F5，之后持续多轮测试，每轮测试连续发送4笔请求，接收4笔应答。接收应答的超时时间为3 s。测试结果如表2所示。

测试结果证明OneConnect聚合短连接、MBLB均衡长连接的技术可行。

表2 MBLB消息均衡技术测试

5 结论

本文所述TCP长连接负载均衡方案已于2014年应用于中国农业银行的银行卡受理中心系统，该系统承载了中国农业银行的ATM渠道、POS渠道，以及银联、VISA、Mastercard等银行卡组织的联机交易，日均交易量5 000万笔。自方案实施以来，迄今为止该系统已平稳运行了4年，通过了国庆、春节等多个交易高峰时段的压力考验，不仅实现了“无缝”停机运维、按需调整集群节点数量，而且系统运行监控及统计分析结果显示集群中各节点的负载相对均匀，各节点的CPU占用、内存消耗、套接字数量、吞吐率、响应时间等运行指标相对平稳。因实施效果显著，本文所述方案已被F5公司作为金融行业优化TCP连接、节约系统及网络资源的典范。

TCP长连接负载均衡在中国农业银行渠道系统中的成功应用，为大型银行建设资源节约型负载均衡体系提供了借鉴。