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長連接負載均衡在中國農業銀行渠道系統中的成功應用，為大型銀行建設資源節約型負載均衡體系提供了借鑒。