APP下载

TIPC在嵌入式集群系统中的应用与优化*

2018-03-29叶建芳

网络安全与数据管理 2018年2期
关键词:实时性报文数据包

施 思,叶建芳,何 睿

(东华大学 信息科学技术学院,上海 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.

猜你喜欢

实时性报文数据包
基于J1939 协议多包报文的时序研究及应用
基于规则实时性的端云动态分配方法研究
CTCS-2级报文数据管理需求分析和实现
浅析反驳类报文要点
SmartSniff
基于虚拟局域网的智能变电站通信网络实时性仿真
航空电子AFDX与AVB传输实时性抗干扰对比
ATS与列车通信报文分析
基于Libpcap的网络数据包捕获器的设计与实现
一种车载Profibus总线系统的实时性分析