专利名称：一种发现互联网性能测量系统中的探针故障的方法
技术领域：
本发明涉及互联网技术领域，特别涉及一种发现互联网性能测量系统中的探针故障的方法。
背景技术：
互联网是目前信息网络重要基础设施之一，然而互联网的端到端性能问题一直是网络管理者的一大难题。随着hternet技术和网络业务的飞速发展，用户对网络资源的需求空前增长，网络也变得越来越复杂。不断增加的网络用户和应用，导致网络负担沉重，网络设备超负荷运转，从而引起网络性能下降。这就需要对网络的性能指标进行提取与分析，对网络性能进行改善和提高。因此网络性能测量便应运而生。发现网络瓶颈，优化网络配置，并进一步发现网络中可能存在的潜在危险，更加有效地进行网络性能管理，提供网络服务质量的验证和控制，对服务提供商的服务质量指标进行量化、比较和验证，是网络性能测量的主要目的。互联网是一种分组化的网络，以TCP/IP技术为基础，在网络层上对数据报文进行逐跳的寻址与转发。由于每一跳的网络节点只负责本节点的数据转发，节点之间彼此相互独立，而当前的网络管理系统都是以单个节点为管理对象，因此网络管理者很难获得网络性能的全貌。在这种背景下，需要网络测量系统以互联网用户的身份将网络作为黑盒来对网络性能进行主动测量。在国际上进行网络主动测量研究的项目很多，如IEPM、NIMI、NLANRAMP、Surveyor 等，其中 IETF 所开发的 TWAMP (Two Way Active Measurement Protocol)协议(RFC5;357) 是其中比较有影响的方法之一。TffAMP协议基于端到端的测量方式，即测量实体都是主机，网络设备不参与测量。 TffAMP包括了两个相互独立的协议· TffAMP-Control 用于建立测量会话，协商会话的参数(如包长、起始时间、中止时间、发包的分布参数等)，开始、终止测量会话，以及获取测量结果(采用TCP协议)；· TffAMP-Test 规定了测量报文的格式等，用于在测量节点间进行测量报文的交互(采用UDP协议)。为了提高其开放性，TffAMP采用了控制协议与测量协议分离的思想，也就是说实际的TWAMP系统的控制协议不一定采用TWAMP-Contro 1，但底层的测量协议要采用 TWAMP-Test，这样可以既保证了测量过程的互通性，又使得采用不同控制协议的测量节点都可以参与到测量中来，体现了测量的开放性。TWAMP协议包括五个功能实体· Session-Sender =TffAMP-Test会话中发送测量报文的测量节点；· Session-Receiver =TffAMP-Test会话中接收测量报文的测量节点；· Server 一个服务器，管理着一个或多个TWAMPIest会话，可以在每个测量节点上为每个TWAMP-Test会话进行配置，可以返回每个TWAMP-Test会话的测量结果；
· Control-Client 一个主机，用于发起建立TWAMP-kst会话的请求，以及控制会话的开始和终止；· Fetch-Client 一个主机，用于发起获取TWAMPIest会话测量结果的请求；五个功能实体间的关系如图1所示TWAMP协议首先假定参加测量的节点Gessionlendei^nkssion-Receiver)在不同控制者的控制之下，Session-Sender 由 Control-Client 控制，Session-Receiver 由 Server 控制，因此 Session-Sender 与 Control-Client 之间，以及 Session-Receiver 与 Server之间可以是控制者自己定义的控制协议，但Control-Client与krver之间，以及 Fetch-Client与krver之间可以使用公开的TWAMP-Control协议，这样就使得在不同控制者的主机之间进行网络性能测量，并通过一个开放接口获取数据成为可能。目前一些研究机构，如Aveiro大学，已经对TWAMP协议系统进行了实现，在他们的系统中，图中未定协议也采用了 TWAMP-Control协议。TffAMP协议由于基于端到端的测量方式，采用普通UDP报文，因此测量过程不易被感知和监测，能够反映用户的真实业务情况；同时在设计时就考虑了安全问题，协议内容包括了 Client与krver间以及knder与Receiver间的认证与加密机制；另外TWAMP还支持小包测量，不加密时最小报文达到42字节，加密时为60字节。但TWAMP协议也存在一些缺点，首先测量结果反映的是只是网络边缘主机间的性能，不利于网络的Troubleshooting ； 其次，协议本身具有很大的开放性，一方面使协议的适应性增强，另一方面也引入了安全问题，如中间人攻击等。因此，综上所述，TWAMP协议是一个比较适合由用户进行的网络性能测量协议。TWAMP本身只是一个探针与探针、探针与服务器之间对于测量类型、测量控制参数的通信协议，如果将TWAMP协议用于实际的测量系统，必然要考虑整个系统的可靠性和可用性，需要实时判断探针的状态是否正常，如果出现故障，还要判断故障是发生在探针节点上还是发生在网络之中，以对测试结果进行正确的处理。目前，通过网络搜索发现，仍没有相关机构或个人提出类似思路在支持TWAMP协议的互联网性能测量系统中实现服务器对探针的故障发现机制。
发明内容
本发明的目的是在TWAMP协议系统之上，在控制服务器与探针Gession-knder 和Session-Receiver)建立一种发现故障的方法，使得整套系统能够实现对探针工作状态的判断。为实现上述目的，本发明采用以下技术方案一种发现互联网性能测量系统中的探针故障的方法，所述互联网性能测量系统基于TWAMP协议的系统，包括，在探针向服务器注册成功后，由服务器建立第一内存表和第二内存表，所述第一内存表用于保存探针发送来的实时信息和接收到所述实时信息的时间， 所述第二内存表用于保存已注册的探针的信息记录；还具体包括步骤10 设置未连接次数为0，清空所述第二内存表；步骤20 服务器接收探针发送来的实时信息，并在所述第一内存表保存该实时信息和接收到所述实时信息的时间，在所述第二内存表保存已注册的探针的信息记录，包括
5探针的名称、IP地址和网管地址信息；步骤30 从所述第二内存表中读取一条信息记录；步骤40 将所述信息记录与所述第一内存表中的实时信息匹配，如能够匹配，则证明在超时时间内收到了探针的实时信息，转至步骤50;若不能匹配，则证明在超时时间内未收到探针的实时信息，转至步骤70 ；步骤50 修改探针活动状态为“正常”；步骤60 设置探针的未连接次数为0，删除所述第一内存表中的数据，并转至步骤 30 ；步骤70 修改探针活动状态为“故障”；步骤80 设置探针的未连接次数+1，删除所述第一内存表中的数据；步骤90 判断未连接次数是否大于3，若否，则转至步骤30 ；若是，则判定被检测的探针出现故障。进一步地，所述步骤2中的服务器接收探针发送来的实时信息，并在所述第一内存表保存该实时信息和接收到所述实时信息的时间，，具体包括步骤21 从内存中读取服务器的IP地址、keepalive定时时间间隔信息；步骤22 :设定调度器每隔所述ke印al ive定时时间间隔便向服务器发送 keepalive 数据包；步骤23 接收ke印alive数据包，并在所述第一内存表保存ke印alive数据包中的信息和接收到ke印alive数据包的时间。进一步地，在所述步骤22之后还包括步骤221 创建ke印alive报告的UDP端口 ；步骤222 封装ke印alive数据包，根据已定义的ke印alive报文，填入相应信息；步骤223 发送ke印alive数据包，通过条用发送函数将ke印alive数据包通过 UDP发送给服务器；步骤2 关闭所述UDP端口。进一步地，将所述keepalive数据包的报文各字段含义分别设定为报文长度、报文类型和探针名称。进一步地，在判定被检测的探针出现故障后，还包括步骤110 从所述第二内存表中读取需检测的探针的IP地址和网关IP地址；步骤120 对步骤110中读取的IP地址进行ping测试，确定是否能够ping通，若是，则转至步骤130 ；若否，则转至步骤150 ；步骤130 判定探针的故障类型为“软件故障”；步骤140 设置探针的未连接次数为0，删除所述第一内存表中的数据，转至步骤 180 ；步骤150 对探针的网关IP地址进行ping测试，确定是否能够ping通，若是，则转至步骤160 ；若否，则转至步骤170 ；步骤160 判定探针的故障类型为“主机故障”，并转至步骤180 ；步骤170 判定探针的故障类型为“网络故障”，并转至步骤180 ；步骤180 将探针的故障类型写入日志。
进一步地，所述步骤110具体包括步骤111 从所述第二内存表中读取需检测的探针的IP地址；步骤112 判断所述第二内存表中是否含有与步骤111中所述的IP地址相应的网关IP地址，若有，则转至步骤114 ；若否，则转至步骤113 ；步骤113 从数据库探针基本信息表中读取与步骤111中所述的IP地址相应的探针信息，并添加至所述第二内存表，并转至步骤111 ；步骤114 从所述第二内存表中读取需检测的探针的网关IP地址。本发明在实现TWAMP协议的探针与服务器上增加状态维护与故障发现的方法，在探针向服务器注册之后，定期向服务器报发送Ke印alive信息，当Ke印alive超时后，服务器将发起对探针状态的探测，判断探针是否处于故障状态。
图1为现有技术中TWAMP协议功能实体的关系示意图；图2为本发明的探针端注册流程示意图；图3为本发明的探针注册请求报文格式示意图；图4为本发明的探针端Ke印alive处理流程示意图；图5为本发明的Ke印alive报文格式示意图；图6为本发明的创建监听的进程和内存表示意图；图7为本发明的探针状态判断流程示意图；图8为本发明的探针故障检测过程示意图。
具体实施例方式为了使本发明的目的、技术方案及优点更加清楚，下面结合附图及实施例，对本发明进行进一步详细说明。此处所描述的具体实施例仅用以解释本发明，但并不用于限定本发明。本发明中的探针故障发现包括探针和服务器两方面的处理流程。在探针端，首先需要由管理人员将注册信息写入探针端本地文件，在探针启动后， 自动启动注册流程，将故障发现所需信息发送至服务器端。如图2所示，处理流程包括以下步骤步骤10，创建注册所使用的TCP Socket。步骤20，通过该TCP Socket向服务器端发送连接请求。步骤30，连接请求接受后，根据注册信息文件生成注册报文，向服务器端发送注册请求。步骤40，接收并读取服务器端返回的注册回复报文。步骤50，调用公共模块关闭连接。步骤60，根据步骤40中读到的注册回复报文，取出其中的Ac^pt字段，此字段代表注册是否成功。根据Accept值返回本次注册结果。如图3所示，探针注册请求报文如下 报文长度4字节。 报文类型2字节，1代表探针注册命令，2代表定时在线命令。
探针能力4字节，32bit0 探针名称32字节，用户为探针所配置的名称。 密码32字节，用户为探针所配置的注册密码。 探针IP地址256字节，探针的IP地址。 探针网关IP地址256字节，探针的网关地址。在探针成功注册之后，将启动Keepal ive线程，定期维护服务器上的探针状态。如图4所示，探针端Ke印alive线程的处理流程如下步骤10，读ke印alive相关信息，需要从内存中读取出控制服务器的IP地址、 keepalive定时时间间隔等信息。步骤20，设定timer时间为配置时间间隔，通过固定时间调用Ke印alive发送代码，达到报到在线状态的目的。当定时时间到时便会自动开启线程处理转至步骤21处处理。步骤21，创建 Ke印alive 报告的 UDP Socket。步骤22，封装Ke印alive数据包，根据已定义的Ke印alive报文，填入相应信息。步骤23，发送Ke印al ive数据包，通过调用发送函数将数据报通过UDP端口发送给控制服务器。步骤24，关闭 Ke印alive UDP Socket。探针端发送ke印alive数据包使用UDP端口。如图5所示，Keepalive报文各字段含义如下 报文长度4字节。 报文类型2字节，2代表定时在线命令，1代表探针注册命令。 探针名称32字节，用户为探针所配置的名称。如图6所示，服务器的处理流程包括以下步骤步骤110-120 服务器接受探针注册请求，并启动探针信息处理线程；步骤121-123 服务器对接收到的探针注册请求信息与数据库内的信息进行匹配；步骤124 将探针注册信息中的IP地址，网关地址等关键信息保存到数据库相应位置；步骤125-126 向探针发送注册回复报文，并关闭连接。服务器在启动UDP侦听端口时就初始化探针的扫描进程，通过控制服务器参数文件中读出扫描探针状态时间，每隔扫描状态间隔时间扫描一次，并作出相应的探针状态判断。服务器建立一个专门的内存表1，若收到探针的ke印alive信息，则将探针名称和控制服务器接收到keepalive信息的时间保存到控制服务器端内存表中，同时建立一个内存表2为“探针名-IP地址”的哈希数据结构。如图7所示，进行探针状态判断的流程如下 步骤10 判断开始，置探针未连接次数为0，清空内存表2 ； 步骤20 根据已注册探针信息建立内存表2，其中保存了探针名称和IP地址、网关地址信息； 步骤30 从内存表2中取一条探针记录；
步骤40 将该记录与内存表1中探针名匹配，若能够匹配，则证明在超时时间内收到了探针的ke印alive信息，转到步骤50，修改探针状态为正常，并返回步骤30，取下一条探针记录；若不能匹配，则证明在超时时间内未收到探针的keepalive信息，转到步骤 70 ； 步骤70 修改探针状态为“故障”； 步骤80 该探针未连接次数加1，删除内存表1中该探针条目； 步骤90 判断未连接次数是否大于3，若未大于3，则等待ke印alive超时时间后，返回步骤40进行判断；若大于3，则开启探针故障判断线程。探针故障判断流程是为了判断探针故障的类型，包括探针软件故障、探针主机故障和探针网络故障三种情况。如图8所示，判断流程如下 步骤110 从内存表2中读取需探测探针IP地址； 步骤120 判断表2中是否含有探针、网关IP，若没有，重新从数据库中读取相应 fn息； 步骤140 读取内存表2中探针IP地址； 步骤150 对探针IP地址进行ping测试，若探针可以ping通，证明探针主机本身无故障，网络无故障，服务器未收到keepalive消息应该是由于探针软件故障所致，因此清除内存表1中与该探针相关信息，并在日志中写入探针“软件故障”；若探针无法Ping通， 进入步骤180，进行进一步故障判断； 步骤180 :ping探针网关IP地址，若可以ping通，则证明网络无故障，而探针主机出现故障，在日志中进行注明；若无法Ping通，证明连接探针的网络出现故障，在日志中应注明“网络故障”。通过以上步骤，可以将探针所有可能故障形式进行完整判断，从而使网络性能测量系统能够准确反映网络的情况。以上所述仅为本发明的较佳实施例，并非用来限定本发明的实施范围；如果不脱离本发明的精神和范围，对本发明进行修改或者等同替换，均应涵盖在本发明权利要求的保护范围当中。
权利要求
1.一种发现互联网性能测量系统中的探针故障的方法，所述互联网性能测量系统基于 TWAMP协议的系统，其特征在于，包括，在探针向服务器注册成功后，由服务器建立第一内存表和第二内存表，所述第一内存表用于保存探针发送来的实时信息和接收到所述实时信息的时间，所述第二内存表用于保存已注册的探针的信息记录；还具体包括步骤10 设置未连接次数为0，清空所述第二内存表；步骤20 服务器接收探针发送来的实时信息，并在所述第一内存表保存该实时信息和接收到所述实时信息的时间，在所述第二内存表保存已注册的探针的信息记录，包括探针的名称、IP地址和网管地址信息；步骤30 从所述第二内存表中读取一条信息记录；步骤40:将所述信息记录与所述第一内存表中的实时信息匹配，如能够匹配，则证明在超时时间内收到了探针的实时信息，转至步骤50;若不能匹配，则证明在超时时间内未收到探针的实时信息，转至步骤70 ；步骤50 修改探针活动状态为“正常”；步骤60 设置探针的未连接次数为0，删除所述第一内存表中的数据，并转至步骤30 ； 步骤70 修改探针活动状态为“故障”；步骤80 设置探针的未连接次数+1，删除所述第一内存表中的数据； 步骤90 判断未连接次数是否大于3，若否，则转至步骤30 ；若是，则判定被检测的探针出现故障。
2.根据权利要求1所述的方法，其特征在于，所述步骤2中的服务器接收探针发送来的实时信息，并在所述第一内存表保存该实时信息和接收到所述实时信息的时间，，具体包括步骤21 从内存中读取服务器的IP地址、ke印alive定时时间间隔信息； 步骤22 设定调度器每隔所述ke印alive定时时间间隔便向服务器发送ke印alive数据包；步骤23 接收ke印alive数据包，并在所述第一内存表保存ke印alive数据包中的信息和接收到ke印alive数据包的时间。
3.根据权利要求2所述的方法，其特征在于，在所述步骤22之后还包括 步骤221 创建ke印alive报告的UDP端口 ；步骤222 封装ke印alive数据包，根据已定义的ke印alive报文，填入相应信息； 步骤223 发送ke印alive数据包，通过条用发送函数将ke印alive数据包通过UDP发送给服务器；步骤224 关闭所述UDP端口。
4.根据权利要求2或3所述的方法，其特征在于，将所述keepalive数据包的报文各字段含义分别设定为报文长度、报文类型和探针名称。
5.根据权利要求1所述的方法，其特征在于，在判定被检测的探针出现故障后，还包括步骤110 从所述第二内存表中读取需检测的探针的IP地址和网关IP地址； 步骤120 对步骤110中读取的IP地址进行Ping测试，确定是否能够ping通，若是， 则转至步骤130 ；若否，则转至步骤150 ；步骤130 判定探针的故障类型为“软件故障”；步骤140 设置探针的未连接次数为0，删除所述第一内存表中的数据，转至步骤180 ； 步骤150 对探针的网关IP地址进行ping测试，确定是否能够ping通，若是，则转至步骤160 ；若否，则转至步骤170 ；步骤160 判定探针的故障类型为“主机故障”，并转至步骤180 ； 步骤170 判定探针的故障类型为“网络故障”，并转至步骤180 ； 步骤180 将探针的故障类型写入日志。
6.根据权利要求4所述的方法，其特征在于，所述步骤110具体包括 步骤111 从所述第二内存表中读取需检测的探针的IP地址； 步骤112 判断所述第二内存表中是否含有与步骤111中所述的IP地址相应的网关IP 地址，若有，则转至步骤114 ；若否，则转至步骤113 ；步骤113 从数据库探针基本信息表中读取与步骤111中所述的IP地址相应的探针信息，并添加至所述第二内存表，并转至步骤111 ；步骤114 从所述第二内存表中读取需检测的探针的网关IP地址。
全文摘要
本发明公开了一种发现互联网性能测量系统中的探针故障的方法。本发明的目的是在TWAMP协议系统之上，在控制服务器与探针(Session-Sender和Session-Receiver)建立一种发现故障的方法，使得整套系统能够实现对探针工作状态的判断。本发明在实现TWAMP协议的探针与服务器上增加状态维护与故障发现的方法，在探针向服务器注册之后，定期向服务器报发送Keepalive信息，当Keepalive超时后，服务器将发起对探针状态的探测，判断探针是否处于故障状态。
文档编号H04L29/08GK102307119SQ20111023844
公开日2012年1月4日 申请日期2011年8月18日 优先权日2011年8月18日
发明者何宝宏, 刘述, 唐浩, 张恒升, 徐贵宝, 马科, 高巍 申请人:工业和信息化部电信传输研究所