TIPC在嵌入式集群系統中的應用與優化*

施 思，葉建芳，何 睿

(東華大學 信息科學技術學院，上海 201600)

0 引言

目前嵌入式系統應用廣泛，其與網絡的結合早已成為發展的大趨勢。嵌入式系統是一個實時系統，具有實時系統的根本特點。嵌入式系統通信的實時性問題不單指嵌入式系統本身的實時性，更包括各種嵌入式設備互連通信的網絡和應用的實時性，包括協議層面的實時性保證和應用層面的實時性處理。

傳統的TCP/IP將大把的精力花在保證數據傳送的可靠性及流量控制上，在設計時考慮了互聯網傳輸延時大、傳輸差錯率較高等特性，過于復雜且需要大量的系統資源，而嵌入式設備本身資源緊張，對實時性要求又較高，而且TCP無法實現高優先級包的有效傳輸，因而傳統的TCP/IP協議并不能滿足這類系統的要求[1-2]。

TIPC(Transparent Inter Process Communication protocol)專門為集群間通信設計，具有良好的實時性[3]。本文將TIPC作為通信協議移植入嵌入式集群系統內部網絡，提出基于TIPC高可用系統的設計方案，針對其短數據包吞吐量較低的問題提出優化設計。

1 TIPC概述

TIPC是一種透明的進程間通信協議，將確認/重傳、擁塞與流控等機制放在鏈路層實現從而減少消息響應時間[4]。TIPC流式套接字通信的建立與拆除僅需3次報文的交互，同一節點內采用Netlink[5]從而優化了內部的通信。節點間多條平行鏈路支持Load Sharing(負載分擔)和Active/Standby(主/備)兩種模式，Active/Standby用于冗余保護，Load Sharing則類似于MPTCP[6]。實驗表明TIPC在節點間的通信速度比TCP快大約35%，在節點內通信時，其優勢更為明顯。

TIPC網絡由一組節點組成，網絡嚴格分層，圖1為TIPC網絡拓撲。網絡中每個節點都有一個由區域號、集群號和節點號組成的節點網絡地址，一般標記為。除網絡地址外，TIPC為上層應用提供了一種透明的邏輯服務地。兩者的映射關系以分布式數據庫的形式存于每一個節點的名字表中。

圖1 TIPC網絡拓撲

2 TIPC在嵌入式集群系統中的應用

2.1 TIPC網絡系統的搭建

本文以某通信公司自主研發的10U OTN產品為研究背景，模型如圖2所示。該產品設計有多個卡槽用于插放板卡，即為TIPC網絡中的節點。主控卡A和B為雙機熱備，構成一個HA。

圖2 板級間TIPC網絡的構建

根據圖2所示的網絡規劃完成系統中所有節點的網絡地址和套接字接口的邏輯地址分配，如圖3所示。實驗中僅使能了部分接口和板卡。

圖3 系統地址分配

2.2 基于TIPC的高可用系統設計

為防止控制節點故障而導致整個系統癱瘓，一般設計主控節點的熱備保護。主控節點A處于工作狀態時，B處于備用狀態，A一旦出現問題，B隨即接替A的工作。系統高可用性遵循的是木桶原理：木桶的容量取決于最短的那根木塊。為實現系統的高可用性[7]，除主控節點的熱備保護外，系統還需為通信鏈路設計冗余保護。高可用系統規劃如圖4所示。

圖4 系統的高可用性實現

2.2.1節點的高可用設計

TIPC邏輯服務地址可用于主控節點熱備保護中的透明切換。主控卡設置兩種不同instance值的接口，instance=0的接口用于與業務卡通信，另一類instance 的接口用于主控卡間通信。A和B擁有一些共同的虛擬接口,如{X,0}，{Y,0}。業務卡并不關注A和B何為備用卡，只需向{X, 0}, {Y, 0}等虛擬接口傳送消息。當A處于工作狀態時，A和B均可獲取來自業務卡的消息，由A進行消息的響應，B處于沉默狀態；當主控卡A由于某種原因發生故障時，備用卡B隨即啟用并代替A響應業務卡。上述整個過程中A和B之間的切換對于業務卡而言是全透明的。

2.2.2通信鏈路的高可用性設計

TIPC中多Link的機制具備類似MPTCP的功能。Link在創建時可指定優先級(Link Priority)。節點間同時存在多條Link時，Link Priority決定了它們之間的關系。Link間的關系分為兩種：負載分擔(Load Sharing)以及主備保護(Active/Standby)。當Link優先級相同時，進行負載分擔；當Link優先級不同時，高優先級的Link為Active狀態，低優先級的Link為Standby狀態。利用TIPC多Link的機制完成系統中不同類型流量的分流管控和冗余保護。如圖4所示，主控卡A和B設計有兩塊網卡分別為eth1和eth2，業務卡僅有一塊網卡eth1，所有eth1均接到同一背板交換芯片上，而主控卡的eth2連接至另一塊背板交換芯片，即所有eth1共用背板總線1，eth2共用背板總線2。為隔離主控卡之間的流量與主控卡業務卡之間的流量，可在主控卡上為eth1和eth2設置不同的優先級，eth2優于eth1。如圖5所示，在主控卡A和主控卡B之間存在兩條鏈路，分別為Link1(1.1.101:eth1—1.1.102:eth1)和Link2(1.1.101:eth2—1.1.102:eth2)。Link1的優先級為9，Link2的優先級為10，故Link1處于備用(standby)狀態，Link2處于活躍(active)狀態。兩節點之間的流量傳輸由Link2負責，當Link2出現故障時，Link1狀態轉為active，從而實現鏈路冗余保護。

圖5 TIPC的鏈路冗余

3 板級間通信環境中TIPC的優化

研究發現，相比TCP/IP，TIPC在通信的實時性上有明顯的優勢，但當傳輸的消息是大量的小數據報文時，TIPC的吞吐量不及TCP/IP。這一現象的原因在于TCP協議中使用Nagle算法[8]，該算法很好地解決了網絡環境較差情況下短幀泛濫的問題。Nagle算法是一種自適應的組塊技術，用確認的到達來觸發其余數據的傳輸，它沒有引入額外的延時，且能有效減少網絡上小數據包的流量。

TIPC中存在一種稱之為消息捆綁 (Message Bundling) 的機制。不同于純粹的組包技術，Message Bundling捆綁的不是data，而是包含TIPC頭部在內的消息，因此在帶寬利用率上并不會有很大的提高。而且Message Bundling是用于擁塞的快速恢復而不是避免擁塞。

3.1 Nagle算法

Nagle算法針對的是連接的發送方，在TCP中原理如下：連接中的第一個發送數據包到達緩沖區后直接發送。在已經傳輸的數據還沒有被確認的情況下，發送方的應用程序發生了后續數據，并照常送到輸出緩沖區，但這時并不直接發送后續報文段，而是等到有足夠的數據填滿一個達到最大長度MSS(Maximum Segment Size，最大分段大小)的報文段之后或者在此期間接收到上一個數據包的ACK信息后再把緩沖區中的等待數據一起發送出去，如果新的數據包長度本身大于MSS，則直接發送。

利用MATLAB建立簡單的發送接收模型，分析Nagle算法如何根據網絡擁塞和數據流量情況自適應地對短包進行合理打包發送。模型的建立并非本文重點，故不詳述。圖6和圖7分別為網絡良好和一般情況下基于Nagle算法模型和普通模型的分析結果。數據接收曲線中，橫坐標表示第i個應用數據到達發送緩沖區的時間，記為ti，縱坐標表示應用數據到達接收端的時間，記為tai。數據傳輸曲線中，橫坐標表示應用數據包編號，縱坐標表示每個數據包從到達發送緩沖區到傳送至接收端的時間，記為t_trani，則t_trani=tai-ti。網絡情況較好時，兩個模型的表現基本一致，應用數據到達緩沖區后都能及時發送并到達接收端。當網絡環境一般或較差時，在普通發送模型中，每個應用數據包不論大小均需添加一個報文頭后發送，增加了網絡負擔。從圖7可以看出每個數據包的傳輸時間t_trani越來越大并呈現發散的趨勢，而在Nagle模型中依舊能保持t_trani≈C，維持在一個較小的范圍內并保持收斂。分析結果表明，在網絡帶寬資源相對有限時，Nagle算法能通過合理的數據包組塊提升網絡利用率，降低通信延時。

圖6 網絡良好時模型表現

圖7 網絡一般時模型表現

圖8 TIPC Link level 植入Nagle

3.2 Nagle算法在TIPC中的植入

TIPC在結構上被分為3個層次：Connection Level、Link Level和Bear Level。不同于TCP/IP模型，TIPC的流控、確認/重傳等機制主要在Link Level層實現，stream類型的TIPC連接在Connection Level也有部分這類機制。

Link Level的確認是基于報文的。link每接收一個TIPC報文，不論是何種類型，計數器unacked_window加1，當超過預設值TIPC_MIN_LINK_WIN時隨即返回一個Link_State報文給對端，該報文中攜帶確認序列號。當本端link上發送了任意一個TIPC報文(除廣播報文外)至對端后，都會將unacked_window重置為0。

每一個link都有一個發送緩沖隊列，當長度大于TIPC_MIN_LINK_WIN時，則認為該link發生了擁塞。一旦link發生了擁塞，之后需要追加到該link 發送緩沖隊列中的數據需要進行過濾篩選之后才會被追加到發送隊列，并且追加的方式也會有所不同，依據為數據包的優先級，如LOW 優先級的數據會直接被丟棄。

TCP的Nagle以同一TCP connection中上一個報文的ACK信息和待發數據長度作為判定是否需要組包的依據。本文設計的TIPC Nagle在Link Level實現，根據同一link中前第TIPC_MIN_LINK_WIN個報文的ACK信息、同一Connection Level中待發數據包的長度以及用戶數據的優先級作為判定是否需要組包的依據，流程如圖8所示,虛線部分為植入Nagle而添加的處理流程。當link發送隊列長度大于TIPC_MIN_LINK_WIN時，即對端未及時發送ACK，將發送隊列同一connection上待發送的數據進行組塊，判斷數據的優先級，如果不是高優先級數據則遵循原來的流程進行數據包的處理，否則判斷隊列長度和待發數據包的長度，當同時滿足發送隊列長度小于TIPC_MAX_LINK_WIN，待發數據長度大于MSS時，直接發送數據，否則依然遵循原來的流程。

3.3 結果分析

分別建立基于TCP和TIPC的server和client，由server向client連續發送1 000個僅含1 B的應用數據，通過Wireshark抓取報文，并分析帶寬利用情況。圖9中自上而下分別為TCP、TIPC、Bundling TIPC以及Nagle TIPC模式下網絡流量情況。在TCP協議中由于采用了Nagle算法，應用數據被打包發送，網絡帶寬的利用率達59.7%。在未經改進的TIPC中，網絡帶寬的利用率僅為2.2%；采用Message Bundling后，利用率提高為3.3%；在Link Level植入Nagle后，利用率可提高至22.5%，極大地提高了網絡帶寬的利用率。

圖9 網絡流量情況統計

4 結束語

本文提出了基于TIPC的高可用強實時嵌入式集群系統的設計方案。結合應用數據的優先級設計具有TIPC特色的Nagle算法并植入Link層中，提高了網絡狀態不佳時帶寬資源的利用率。

[1] 肖謙. 基于慢啟動改進的TCP擁塞控制算法研究[J]. 科技展望,2017,27(1):1-2.

[2] 王彬.TCP/IP網絡擁塞控制策略研究[D].杭州：浙江大學,2004.

[3] 馮鵬斐，辛陽. Linux TIPC網絡協議棧的分析與改進 [C]//中國電子學會信息論分會，中國電子學會第十六屆信息論學術年會論文集,2009:781-787.

[4] 冀映輝，蔡煒，蔡惠智.TIPC透明進程間通信協議研究和應用[J]. 計算機系統應用,2010,19(3):76-79，11.

[5] 周莉，柯健，顧小晶. Netlink套接字在Linux系統通信中的應用研究[J]. 計算機與現代化,2007(3):109-111.

[6] Cao Yuanlong, Chen Shengyang, Liu Qinghua, et al. QoE-driven energy-aware multipath content delivery approach for MPTCP-based mobile phones[J]. China Communications,2017,14(2):90-103.

[7] 繆劍斌. 基于LVS的高可用負載均衡集群系統的設計與實現[D].北京：北京郵電大學，2010.

[8] NAGLE J. RFC896-Congestion control in IP/TCP internetworks[Z].Internet Engineering Task Force, 1984.