勞 偉

(中國(guó)農(nóng)業(yè)銀行股份有限公司 軟件開發(fā)中心，北京 100073)

0 引言

銀行渠道系統(tǒng)既要作為服務(wù)端接收ATM、POS等本行外圍設(shè)備以及銀聯(lián)、國(guó)際銀行卡組織等行外系統(tǒng)的交易請(qǐng)求，也要作為客戶端將交易請(qǐng)求轉(zhuǎn)發(fā)至本行后臺(tái)系統(tǒng)以及銀聯(lián)、VISA、Mastercard、美國(guó)運(yùn)通、大萊、JCB等銀行卡組織。銀行渠道系統(tǒng)不僅需要7×24小時(shí)不間斷運(yùn)行，還需要具備在春節(jié)、國(guó)慶等交易高峰期平穩(wěn)運(yùn)行的能力。

銀行渠道系統(tǒng)與關(guān)聯(lián)系統(tǒng)之間通常基于TCP協(xié)議進(jìn)行消息交互。TCP作為一個(gè)面向連接的協(xié)議，傳輸數(shù)據(jù)之前，需要在客戶端與服務(wù)端之間建立連接，數(shù)據(jù)傳輸停止后，需要終止連接以釋放資源。建立連接需要三次握手，斷開TCP連接需要四次揮手[1]。

銀行渠道系統(tǒng)為支撐核心業(yè)務(wù)，普遍采用集群部署方式實(shí)現(xiàn)高可用、高可靠和可擴(kuò)展。建立連接屬計(jì)算密集型操作，頻繁交互場(chǎng)景下不適合采用短連接通信方式，故銀聯(lián)、VISA、Mastercard等銀行卡組織均要求成員機(jī)構(gòu)采用長(zhǎng)連接入網(wǎng)方式[2-4]，因此銀行渠道系統(tǒng)面臨著如何實(shí)現(xiàn)長(zhǎng)連接負(fù)載均衡的問題。

客戶端和服務(wù)端完成一次消息交互后即斷開TCP連接的方式為TCP短連接。建立TCP連接后進(jìn)行多次消息交互，直至客戶端或服務(wù)端退出時(shí)終止連接的方式為TCP長(zhǎng)連接。采用傳統(tǒng)負(fù)載均衡模式時(shí)，每條客戶端長(zhǎng)連接僅能接入服務(wù)集群中的1個(gè)節(jié)點(diǎn)，各節(jié)點(diǎn)的負(fù)載并不均衡，無法動(dòng)態(tài)調(diào)整節(jié)點(diǎn)數(shù)量。

為應(yīng)對(duì)上述問題，本文提出了基于F5公司的OneConnect、MBLB技術(shù)實(shí)現(xiàn)的TCP長(zhǎng)連接負(fù)載均衡方案，方案已經(jīng)過大型銀行渠道系統(tǒng)的長(zhǎng)期實(shí)踐檢驗(yàn)，取得了優(yōu)化連接、節(jié)約資源的預(yù)期效果。

1 傳統(tǒng)負(fù)載均衡模式現(xiàn)狀分析

經(jīng)過多年發(fā)展，傳統(tǒng)負(fù)載均衡模式產(chǎn)生了若干類型，主要類型有：

(1)基于DNS輪詢的負(fù)載均衡

DNS為同一域名配置多個(gè)IP地址，客戶端查詢域名時(shí)獲取其中的一個(gè)IP地址以實(shí)現(xiàn)負(fù)載均衡[5]。DNS負(fù)載均衡常用于Web集群服務(wù)。

(2)基于代理服務(wù)器的負(fù)載均衡

通過代理服務(wù)器將請(qǐng)求分發(fā)至多臺(tái)服務(wù)器以實(shí)現(xiàn)負(fù)載均衡。Linux下可用LVS實(shí)現(xiàn)代理服務(wù)器[6]。

(3)基于NAT的負(fù)載均衡

網(wǎng)絡(luò)地址轉(zhuǎn)換(Network Address Translation，NAT)是一種將外部IP映射為多個(gè)內(nèi)部IP的技術(shù)。Linux內(nèi)核已包含NAT負(fù)載均衡功能，通過客戶端動(dòng)態(tài)連接一個(gè)內(nèi)部IP的方式實(shí)現(xiàn)負(fù)載均衡[7]。

本質(zhì)上傳統(tǒng)負(fù)載均衡模式是從服務(wù)端集群中選擇1個(gè)服務(wù)節(jié)點(diǎn)進(jìn)行連接，如圖1所示。

圖1 傳統(tǒng)負(fù)載均衡模式示意圖

因此傳統(tǒng)負(fù)載均衡模式適用于TCP短連接的場(chǎng)景，在TCP長(zhǎng)連接場(chǎng)景下達(dá)不到負(fù)載均衡的效果。

2 頻繁交互場(chǎng)景下TCP短連接存在的問題

頻繁交互的應(yīng)用場(chǎng)景下采用TCP短連接的通信方式，存在TIME_WAIT狀態(tài)套接字過多、CPU及內(nèi)存資源消耗過高、吞吐率偏低等諸多問題。

2.1 TIME_WAIT狀態(tài)套接字過多

頻繁建立、拆除TCP短連接，系統(tǒng)內(nèi)核中將不可避免地出現(xiàn)大量處于TIME_WAIT狀態(tài)的套接字。

TIME_WAIT狀態(tài)又稱為2MSL等待狀態(tài)。TCP協(xié)議規(guī)定主動(dòng)關(guān)閉連接一方的套接字在發(fā)送最后一個(gè)ACK后進(jìn)入TIME_WAIT，等待2倍報(bào)文段最長(zhǎng)存活時(shí)間(Maximum Segment Lifetime， MSL)之后，轉(zhuǎn)入CLOSED狀態(tài)，內(nèi)核釋放CLOSED狀態(tài)的套接字資源。

MSL是TCP報(bào)文段在網(wǎng)絡(luò)上的最長(zhǎng)存活時(shí)間，超過MSL的報(bào)文段將被網(wǎng)絡(luò)設(shè)備自動(dòng)丟棄。RFC 1122建議將MSL設(shè)為2 min，Berkeley TCP的MSL為30 s。

RFC 1185描述了TCP協(xié)議設(shè)置TIME_WAIT的兩個(gè)理由：

(1)可靠終止TCP連接的兩個(gè)方向(全雙工關(guān)閉);

(2)等待網(wǎng)絡(luò)設(shè)備丟棄已關(guān)閉連接的重復(fù)報(bào)文段。

簡(jiǎn)而言之，主動(dòng)關(guān)閉連接一方保存關(guān)閉連接的傳輸控制塊(Transmission Control Block,TCB)至2倍MSL，是為了防止主動(dòng)關(guān)閉連接一方新建連接四元組信息(源地址、源端口、目的地址、目的端口)與仍在網(wǎng)絡(luò)中傳輸?shù)呐f連接重復(fù)報(bào)文段出現(xiàn)重復(fù)。

主動(dòng)關(guān)閉TCP連接的狀態(tài)轉(zhuǎn)換過程如圖2所示。

圖2 主動(dòng)關(guān)閉TCP連接的過程

內(nèi)核為新建連接創(chuàng)建TCB以保存TCP連接四元組等重要信息，并通過TCB列表管理連接。接收TCP報(bào)文時(shí)，內(nèi)核檢索TCB列表將分解的應(yīng)用報(bào)文交給對(duì)應(yīng)的套接字。

系統(tǒng)能夠保存的TCB數(shù)量不僅取決于內(nèi)核內(nèi)存的大小，而且取決于系統(tǒng)中的TCP連接狀態(tài)。當(dāng)系統(tǒng)存在大量TIME_WAIT狀態(tài)的TCP連接時(shí)，內(nèi)核維護(hù)TCB列表的開銷將會(huì)增長(zhǎng)，甚至?xí)蛸Y源消耗過多出現(xiàn)系統(tǒng)服務(wù)中斷的情況。

目前國(guó)內(nèi)幾家大型商業(yè)銀行渠道系統(tǒng)的日交易量均為千萬級(jí)別，支撐的核心業(yè)務(wù)交易峰值已過萬級(jí)TPS。從投資效益角度看，渠道系統(tǒng)的配置不會(huì)很高，在資源有限的條件下，采用短連接意味著渠道系統(tǒng)的內(nèi)核中要保存大量處于TIME_WAIT的TCB。

以中國(guó)農(nóng)業(yè)銀行卡受理中心系統(tǒng)為例，該系統(tǒng)處理能力為3 000 TPS，基于Linux集群部署，MSL為30 s。如果采用TCP短連接，理論上則需保存18萬個(gè)TCB，按50個(gè)節(jié)點(diǎn)計(jì)算，各節(jié)點(diǎn)需保存3 600個(gè)TCB。有研究者在傳輸速率640 Mb/s的Myrinet局域網(wǎng)環(huán)境下進(jìn)行了測(cè)試，結(jié)果顯示1臺(tái)安裝了SunOS 4.1.3系統(tǒng)的SPARCStation 20/71工作站最多支持每秒60個(gè)TCP短連接[8]。

2.2 減少TIME_WAIT狀態(tài)的風(fēng)險(xiǎn)

為避免TIME_WAIT過多消耗系統(tǒng)資源，網(wǎng)絡(luò)上出現(xiàn)了各種修改內(nèi)核參數(shù)減少TIME_WAIT的措施。如縮小Windows注冊(cè)項(xiàng)HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters中的TcpTimedWaitDelay數(shù)值，啟用Linux系統(tǒng)內(nèi)核參數(shù)net.ipv4.tcp_tw_reuse、net.ipv4.tcp_tw_recycle。

在NAT環(huán)境下使用上述方法將會(huì)導(dǎo)致網(wǎng)絡(luò)通信出現(xiàn)異常。

采用上述方法時(shí)需要NAT設(shè)備轉(zhuǎn)發(fā)TCP包時(shí)重寫TCP時(shí)間戳、轉(zhuǎn)發(fā)新建TCP連接請(qǐng)求時(shí)重新生成TCP初始序列號(hào)(Initial Sequence Number,ISN)。當(dāng)前NAT協(xié)議規(guī)范中并不包含上述功能，在NAT環(huán)境下減少TIME_WAIT的風(fēng)險(xiǎn)很高，原因如下：

RFC 1323規(guī)定TCP時(shí)間戳由報(bào)文發(fā)送方設(shè)置，主要用于往返時(shí)間測(cè)量(Round-trip Time Measurement，RTTM)和TCP序列號(hào)回繞保護(hù)(Protect Against Wrapped Sequences,PAWS)，Linux的TCP時(shí)間戳是系統(tǒng)啟動(dòng)至今經(jīng)歷的毫秒數(shù)量。新建連接時(shí)隨機(jī)設(shè)置ISN的目的是為了防止攻擊者猜測(cè)報(bào)文序列號(hào)、偽造TCP報(bào)文攻擊系統(tǒng)。

RFC 1337 (TIME-WAIT Assassination hazards)公告所列網(wǎng)絡(luò)故障案例的根源均和主動(dòng)關(guān)閉連接一方提前回收或重用TIME_WAIT狀態(tài)套接字有關(guān)。提前回收或重用TIME_WAIT套接字時(shí)，僅支持標(biāo)準(zhǔn)協(xié)議的NAT設(shè)備將自動(dòng)重用舊連接四元組，并由此導(dǎo)致TCP時(shí)間戳或ISN出現(xiàn)亂序，最終引發(fā)連接超時(shí)、連接劫持、拒絕服務(wù)等網(wǎng)絡(luò)異常[9]。

3 TCP長(zhǎng)連接負(fù)載均衡面臨的挑戰(zhàn)

TCP長(zhǎng)連接沒有TIME_WAIT的問題，但是設(shè)計(jì)長(zhǎng)連接負(fù)載均衡方案時(shí)將面臨健康檢查、并發(fā)連接數(shù)、無狀態(tài)服務(wù)、消息邊界等諸多挑戰(zhàn)。

3.1 健康檢查

健康檢查是指檢查網(wǎng)絡(luò)設(shè)備、服務(wù)系統(tǒng)的運(yùn)行狀況，及時(shí)發(fā)現(xiàn)事件故障、潛在問題和性能瓶頸，為優(yōu)化調(diào)整網(wǎng)絡(luò)設(shè)備、服務(wù)系統(tǒng)提供決策支持[10]。通常采用發(fā)送檢查報(bào)文的形式檢測(cè)集群節(jié)點(diǎn)的健康狀態(tài)，長(zhǎng)連接方式下需要設(shè)計(jì)合適的檢查機(jī)制，確保健康檢查涵蓋所有的節(jié)點(diǎn)。

3.2 并發(fā)連接數(shù)

采用TCP長(zhǎng)連接時(shí)，服務(wù)端需要限制同一客戶端的連接個(gè)數(shù)，以防止客戶端頻繁建立連接耗盡服務(wù)端的資源。

以銀聯(lián)為例，大型入網(wǎng)機(jī)構(gòu)和銀聯(lián)之間的連接數(shù)限制通常為8進(jìn)8出16條TCP單工長(zhǎng)連接，小型入網(wǎng)機(jī)構(gòu)的連接數(shù)限制通常為2進(jìn)2出4條TCP單工長(zhǎng)連接。

3.3 無狀態(tài)服務(wù)

一筆銀行交易的處理過程中可能包含多次消息交互，為了實(shí)現(xiàn)負(fù)載均衡，需要將其中的各個(gè)消息分發(fā)至服務(wù)端集群中的不同節(jié)點(diǎn)，因此服務(wù)端系統(tǒng)需要實(shí)現(xiàn)無狀態(tài)服務(wù)。相比短連接，長(zhǎng)連接方式下實(shí)現(xiàn)無狀態(tài)服務(wù)的方法更為復(fù)雜。

3.4 確定消息邊界

負(fù)載均衡設(shè)備(或負(fù)載均衡軟件)從客戶端長(zhǎng)連接收到的數(shù)據(jù)中可能包含多個(gè)消息。為了將各個(gè)消息分發(fā)至服務(wù)端集群中的不同節(jié)點(diǎn)，各個(gè)消息需要有明確的邊界信息，如消息長(zhǎng)度(如HTTP報(bào)文頭的Content-Length)或消息起始標(biāo)記。

4 TCP長(zhǎng)連接負(fù)載架構(gòu)

針對(duì)長(zhǎng)連接負(fù)載均衡面臨的上述挑戰(zhàn)，有研究者設(shè)計(jì)了基于軟件實(shí)現(xiàn)的TCP長(zhǎng)連接負(fù)載均衡器，通過非阻塞帶優(yōu)先級(jí)的事件調(diào)度模型處理連接建立、健康檢查、負(fù)載任務(wù)分派、進(jìn)程間通信、響應(yīng)接收和報(bào)文轉(zhuǎn)發(fā)，通過虛擬IP加雙機(jī)主備部署負(fù)載均衡器的方式消除單點(diǎn)風(fēng)險(xiǎn)[11]。

相比專業(yè)的負(fù)載均衡設(shè)備，負(fù)載均衡軟件在算法、帶寬占用、加速比、可靠性、可維護(hù)性、可擴(kuò)展性等方面還存在一定的差距，因此銀行更傾向于選擇相對(duì)成熟的專業(yè)設(shè)備實(shí)現(xiàn)核心業(yè)務(wù)的負(fù)載均衡。

本文提出的TCP長(zhǎng)連接負(fù)載均衡方案正是基于當(dāng)前金融行業(yè)廣泛使用的F5公司的負(fù)載均衡設(shè)備，方案采用了OneConnect、MBLB等F5提供的技術(shù)。

4.1 OneConnect連接聚合技術(shù)

新建連接屬計(jì)算密集型過程，不僅耗費(fèi)CPU資源，而且還要為連接狀態(tài)和通信緩存區(qū)分配內(nèi)核內(nèi)存，為減少資源消耗，HTTP/1.1已將keep-alives作為默認(rèn)標(biāo)準(zhǔn)。TCP連接數(shù)越少，不僅意味著應(yīng)用線程/進(jìn)程數(shù)越少，應(yīng)用線程/進(jìn)程上下文切換的頻率越低，而且意味著消耗的系統(tǒng)資源越少，系統(tǒng)有效容量越高。

OneConnect為同步處理方式，該方式通過重用服務(wù)端TCP連接、減少連接數(shù)，減輕服務(wù)器負(fù)載及帶寬成本。

OneConnect方式默認(rèn)支持HTTP連接聚合，F(xiàn)5收到服務(wù)端響應(yīng)后，將服務(wù)端連接放入連接重用池；收到客戶端連接請(qǐng)求時(shí)，從連接重用池中選出一條可重用的服務(wù)端連接；通過配置iRules規(guī)則(F5可編程網(wǎng)絡(luò)語言，tclsh腳本)實(shí)現(xiàn)TCP連接聚合[12]。

F5提供Source Mask配置項(xiàng)以限定服務(wù)端連接重用的客戶端范圍。比如設(shè)為255.255.255.255限定連接重用池中的連接僅供原連接客戶端使用。

如圖3所示，基于OneConnect聚合ATM連接時(shí)，F(xiàn)5通過重用服務(wù)端長(zhǎng)連接將ATM交易報(bào)文轉(zhuǎn)發(fā)至渠道集群中的服務(wù)節(jié)點(diǎn)；服務(wù)節(jié)點(diǎn)通過原連接將應(yīng)答返回給F5之后，不關(guān)閉連接以支持F5重用連接。

圖5 基于MBLB技術(shù)均衡網(wǎng)控器接入POS業(yè)務(wù)的方案

4.2 基于消息進(jìn)行負(fù)載均衡的MBLB技術(shù)

MBLB(Message Based Load Balancing)是F5公司基于消息進(jìn)行負(fù)載均衡的技術(shù)，采用MBLB分發(fā)的消息需要包含長(zhǎng)度或起始標(biāo)記等邊界信息。F5通過配置的iRules規(guī)則識(shí)別TCP數(shù)據(jù)流中的消息邊界[13]，從中拆分出相互獨(dú)立的消息，將每個(gè)消息作為負(fù)載均衡的基本單元，依據(jù)配置的策略分發(fā)至各服務(wù)節(jié)點(diǎn)，分發(fā)過程如圖4所示。

圖4 不間斷接收消息場(chǎng)景下MBLB分發(fā)負(fù)載過程示意圖

MBLB為非阻塞異步處理方式，采用該方式的客戶端或服務(wù)端可持續(xù)向?qū)Χ税l(fā)送消息，不必等待對(duì)端響應(yīng)。

MBLB方式下，F(xiàn)5默認(rèn)為每條客戶端連接建立一組連通服務(wù)集群所有節(jié)點(diǎn)的長(zhǎng)連接，用戶可通過配置限制F5與各服務(wù)節(jié)點(diǎn)之間建立的連接數(shù)量。

MBLB適用于均衡網(wǎng)控器接入的POS業(yè)務(wù)。網(wǎng)控器接入的POS報(bào)文包含報(bào)文長(zhǎng)度及標(biāo)記POS通信線路的TPDU(Transport Protocol Data Unit)信息。網(wǎng)控器的每塊上聯(lián)卡可與渠道系統(tǒng)建立一條TCP雙工長(zhǎng)連接，通過這些連接向渠道系統(tǒng)轉(zhuǎn)發(fā)POS請(qǐng)求、異步接收渠道系統(tǒng)的應(yīng)答，依據(jù)應(yīng)答中的TPDU將應(yīng)答報(bào)文返回給對(duì)應(yīng)的POS。采用MBLB均衡POS業(yè)務(wù)的方案如圖5所示。

VISA、Mastercard等國(guó)際銀行卡組織與入網(wǎng)機(jī)構(gòu)之間采用TCP雙工長(zhǎng)連接方式發(fā)送聯(lián)機(jī)交易請(qǐng)求、異步接收聯(lián)機(jī)交易應(yīng)答，交易報(bào)文中包含報(bào)文長(zhǎng)度信息，適于采用MBLB方式進(jìn)行負(fù)載均衡。

銀聯(lián)與入網(wǎng)機(jī)構(gòu)之間的聯(lián)機(jī)交易報(bào)文包含報(bào)文長(zhǎng)度信息，但是采用收發(fā)分離的TCP單工長(zhǎng)連接方式進(jìn)行通信，因此采用MBLB均衡時(shí)需分別設(shè)計(jì)發(fā)送端、接收端的iRules規(guī)則。為保證處理過程的連續(xù)性，渠道服務(wù)節(jié)點(diǎn)可在發(fā)給銀聯(lián)的檢索參考號(hào)字段中設(shè)置當(dāng)前節(jié)點(diǎn)標(biāo)識(shí)，由F5根據(jù)配置的iRules規(guī)則解析銀聯(lián)應(yīng)答報(bào)文,從銀聯(lián)應(yīng)答的檢索參考號(hào)字段中取出節(jié)點(diǎn)標(biāo)識(shí)，依據(jù)節(jié)點(diǎn)標(biāo)識(shí)將應(yīng)答送回對(duì)應(yīng)的節(jié)點(diǎn)。

4.3 銀行渠道系統(tǒng)TCP長(zhǎng)連接負(fù)載均衡整體架構(gòu)

銀行渠道系統(tǒng)負(fù)載均衡整體架構(gòu)如圖6所示，其中同步、異步指接收應(yīng)答的方式。

圖6 銀行渠道系統(tǒng)TCP長(zhǎng)連接負(fù)載均衡整體架構(gòu)

4.4 技術(shù)可行性測(cè)試

使用LoadRunner模擬客戶端，80%的請(qǐng)求報(bào)文長(zhǎng)度為200～300 B，20%的長(zhǎng)度為1 200～1 400 B。

在一臺(tái)F5 BIG-IP LTM設(shè)備上開啟兩個(gè)測(cè)試端口，分別配置OneConnect及MBLB iRules規(guī)則。

測(cè)試服務(wù)端為一臺(tái)64位SuSE11.3虛擬機(jī)，CPU配置為AMD 6234 2.4 GB×2、內(nèi)存配置為4 GB。測(cè)試服務(wù)程序開3個(gè)TCP端口模擬3個(gè)節(jié)點(diǎn)，線程池最大容量為10 000。測(cè)試服務(wù)程序收到請(qǐng)求報(bào)文后隨機(jī)等待0～2 s模擬后端系統(tǒng)延遲，然后將請(qǐng)求報(bào)文直接返回給客戶端模擬后端系統(tǒng)應(yīng)答。

(1)OneConnect聚合連接技術(shù)測(cè)試

LoadRunner模擬50個(gè)客戶端，持續(xù)發(fā)壓時(shí)間5 min。各客戶端持續(xù)多輪測(cè)試，每輪測(cè)試建1條連接到F5，發(fā)送1筆請(qǐng)求、收到1筆應(yīng)答后關(guān)閉連接。接收應(yīng)答的超時(shí)時(shí)間為3 s。測(cè)試結(jié)果如表1所示。

表1 OneConnect聚合連接技術(shù)測(cè)試

(2)MBLB消息均衡技術(shù)測(cè)試

LoadRunner模擬50個(gè)客戶端，持續(xù)發(fā)壓時(shí)間為5 min。各客戶端建立1條長(zhǎng)連接到F5，之后持續(xù)多輪測(cè)試，每輪測(cè)試連續(xù)發(fā)送4筆請(qǐng)求，接收4筆應(yīng)答。接收應(yīng)答的超時(shí)時(shí)間為3 s。測(cè)試結(jié)果如表2所示。

測(cè)試結(jié)果證明OneConnect聚合短連接、MBLB均衡長(zhǎng)連接的技術(shù)可行。

表2 MBLB消息均衡技術(shù)測(cè)試

5 結(jié)論

本文所述TCP長(zhǎng)連接負(fù)載均衡方案已于2014年應(yīng)用于中國(guó)農(nóng)業(yè)銀行的銀行卡受理中心系統(tǒng)，該系統(tǒng)承載了中國(guó)農(nóng)業(yè)銀行的ATM渠道、POS渠道，以及銀聯(lián)、VISA、Mastercard等銀行卡組織的聯(lián)機(jī)交易，日均交易量5 000萬筆。自方案實(shí)施以來，迄今為止該系統(tǒng)已平穩(wěn)運(yùn)行了4年，通過了國(guó)慶、春節(jié)等多個(gè)交易高峰時(shí)段的壓力考驗(yàn)，不僅實(shí)現(xiàn)了“無縫”停機(jī)運(yùn)維、按需調(diào)整集群節(jié)點(diǎn)數(shù)量，而且系統(tǒng)運(yùn)行監(jiān)控及統(tǒng)計(jì)分析結(jié)果顯示集群中各節(jié)點(diǎn)的負(fù)載相對(duì)均勻，各節(jié)點(diǎn)的CPU占用、內(nèi)存消耗、套接字?jǐn)?shù)量、吞吐率、響應(yīng)時(shí)間等運(yùn)行指標(biāo)相對(duì)平穩(wěn)。因?qū)嵤┬Ч@著，本文所述方案已被F5公司作為金融行業(yè)優(yōu)化TCP連接、節(jié)約系統(tǒng)及網(wǎng)絡(luò)資源的典范。

TCP長(zhǎng)連接負(fù)載均衡在中國(guó)農(nóng)業(yè)銀行渠道系統(tǒng)中的成功應(yīng)用，為大型銀行建設(shè)資源節(jié)約型負(fù)載均衡體系提供了借鑒。