CN1980159A - 网际协议网络端到端性能监测***及方法 - Google Patents

Abstract

本发明公开了一种网际协议(IP)网络端到端性能监测***，包括至少两个位于IP网络中的探针端，还包括位于该IP网络中的控制端，其中：控制端，用于向探针端发送测试配置信息，并接收由探针端发送的关于网络性能监测的监测数据；探针端，用于根据测试配置信息在探针端之间执行网络性能监测，并将关于网络性能监测的监测数据发送到控制端。本发明还公开了一种IP网络端到端性能监测方法。应用本发明以后，能够提高测试精度，可以保证测试的正常进行，能够获得准确的、有效的监测数据，使得数据分析更加方便和客观，并提供一种通用的、端到端的、全天候的，以多种方式测量IP网络服务质量(QoS)的测量方式。

Description

网际协议网络端到端性能监测***及方法

技术领域

本发明涉及互联网性能监测技术领域，特别是一种网际协议(IP)网络端到端性能监测***及方法。

背景技术

随着基于IP技术的互联网的迅猛发展，越来越多的用户使用互联网来进行工作和学习。网络上的数据量以几何级数增加，对网络服务质量(QoS)也提出越来越高的要求。目前，随着多媒体应用的兴起，诸如IP电话、视频会议***以及视频点播之类的各种业务，对服务质量的要求更是远远高于传统应用。因此，要在互联网上使用这些新业务，必须提供特定的服务质量保证机制。

基础的IP协议只提供一种服务质量，即“尽力而为”(Best-Effort)的服务。在尽力而为的服务模式下，所有业务的需求都采用相同的优先级来进行排队处理，无法为特定的高要求业务提供更好的服务质量保证。为此，工程任务组(IETF)提出了诸如差分服务(DiffServ)和综合服务(InterServ)之类的IP服务质量技术。DiffServ能够为不同类型的流量提供不同的服务等级，而InterServ能够为互联网保证严格的端到端的服务质量。

然而，不管是使用上述IP QoS技术，还是通过简单增加带宽的方法，将来用户所得到的IP服务将不会是现在的没有任何QoS保证的“尽力而为”服务，而是具有一定的QoS保证的服务。因此，运营商和用户之间将签署服务等级协定(SLA)，规定所承诺的QoS性能保证，比如可用性、丢包率和延迟等，这是全球IP网络发展的必然趋势。

如果要判断运营商所提供的服务能否满足SLA的规定，就必须对运营商所提供的服务进行测量，这对于互联网运营商、政府监管部门、大型客户、***集成商、测试服务提供商以及测试仪表开发商之间促进竞争，解决纠纷，加强监管，都具有重要的意义。

可以看到，传统的互联网业务，如WWW、FTP、EMAIL以及Telnet等，对网络的丢包率要求较高，而对时延、抖动则不十分敏感；实时业务的需求恰好相反，这些业务允许一定限度的丢包率，而对时延和抖动的要求则十分严格。因此，在对服务质量的监测中不但要检测网络的丢包率，还需要监视网络的时延、抖动等重要指标。

对网络性能的监控不可避免地会对现网带来影响，比如主动式监控通常将探针端放在被测网络中，而将控制端设置在被测网络之外。从安全角度上去考虑，这必然会对网络带来不安全因素。尤其在专用网络中，安全问题更加突出，使用完全自主的网络性能监测***是最可靠的方案。

现有的网络性能监测***只能使用公有地址来进行工作，无法在私有地址和公有地址混合的场合中使用，即无法穿越NAT。另外，目前所采用的IP网络性能测量方法多是采用PING的方式，缺乏统一的采样模型、统计方法、时钟同步与误差处理，测量包大小、数据分析以及测试报告等。

目前有一种互联网端到端性能监测的方法及***，该技术使用集中式的网络架构对互联网端到端性能进行监控。该***的工作原理是：设置一个集中式的测量包发射点，再根据被测网络范围确定多个测量包反射点，建立测试网络拓扑。监测***运行中，中心发射点发送测量数据包(Ping包)给边缘反射点，所有反射点反射测量包给中心发射点，在中心发射点进行相关处理后存储。

上述技术的缺点在于：首先该方法使用集中式的测试网络拓扑，中心发射点不仅需要维护同所有反射点之间的发射进程，而且同时需要维护与所有反射点之间的接收进程，再加上***对监测数据的处理开销，必然给测试精度带来较大的误差。

其次，该技术使用双向往返RTT进行测量，只能提供往返测试结果。而互联网是典型的分组交换网络，无法保障测量数据包往返经过同一条路径，即使是经过了相同的路径，两个方向的性能也可能有很大的差别，因此该技术无法提供单向路径的性能指标。另外，该技术没有对异常情况进行分析，无法区分网络故障或反射点故障对测试结果的影响。

发明内容

有鉴于此，本发明的主要目的是提出一种IP网络端到端性能监测***，以提高测试精度。

本发明的另一目的是提出一种IP网络端到端性能监测方法，以提高测试精度。

为达到上述目的，本发明的技术方案是这样实现的：

一种IP网络端到端性能监测***，包括至少两个位于IP网络中的探针端，还包括位于该IP网络中的控制端，其中：

控制端，用于向探针端发送测试配置信息，并接收由探针端发送的关于网络性能监测的监测数据；

探针端，用于根据测试配置信息在探针端之间执行网络性能监测，并将关于网络性能监测的监测数据发送到控制端。

所述探针端位于该IP网络的边缘。

所述探针端将关于网络性能监测的监测数据发送到控制端为：控制端主动向探针端请求该关于网络性能监测的监测数据，或者控制端从探针端被动接收该关于网络性能监测的监测数据。

所述控制端进一步用于根据该关于网络性能监测的监测数据，对该IP网络的网络性能进行统计处理。

所述探针端进一步用于根据该关于网络性能监测的监测数据对该IP网络的网络性能进行统计处理，并向控制端发送网络性能统计处理结果；控制端进一步用于接收该网络性能统计处理结果。

所述探针端用于向该IP网络中的其它探针端发送监测数据包，接收由其它探针端所反射回的监测数据包，并将监测数据包和反射回的监测数据包作为该关于网络性能监测的监测数据发送到控制端；控制端进一步用于根据该监测数据包和反射回的监测数据包对该IP网络的网络性能进行统计处理。

所述探针端用于向该IP网络中的其它探针端和控制端发送监测数据包；其它探针端接收该监测数据包后向控制端发送该监测数据包，控制端进一步用于根据所述探针端发送来的监测数据包和其它探针端发送过来的监测数据包，对该IP网络的网络性能进行统计处理。

所述探针端用于向该IP网络中的其它探针端发送监测数据包，接收由其它探针端所反射回的监测数据包，并根据监测数据包和反射回的监测数据包对该IP网络的网络性能进行统计处理，并且将统计处理结果作为该关于网络性能监测的监测数据发送到控制端。

所述探针端用于向该IP网络中的其它探针端发送监测数据包；其它探针端接收该监测数据包并进行网络性能统计处理，并且将所述网络性能统计处理结果作为该关于网络性能监测的监测数据发送到控制端。

探针端进一步用于向控制端发送注册信息，控制端用于根据该注册信息对探针端进行注册。

探针端包括：

探针端控制模块，用于向控制端发送注册信息，并接收由控制端发送的测试配置信息；

探针端数据处理模块，根据测试配置信息向其它探针端发送监测数据和/或接收由其它探针端所发送的监测数据，并将向其它探针端发送的监测数据和/或由其它探针端所发送的监测数据向控制端发送；

全球定位***(GPS)同步模块，用于实现与控制端的GPS时间同步。

控制端包括：

控制端控制模块，用于接收探针端的注册信息，并根据该注册信息对探针端进行注册，并向探针端发送测试配置信息；

控制端数据处理模块，用于接收并存储由探针端发送的关于网络性能监测的监测数据，并根据该关于网络性能监测的监测数据对该IP网络的网络性能进行统计处理；

GPS同步模块，用于实现与探针端的GPS时间同步；

故障管理模块，用于对网络性能监测中的故障进行探测，并对故障进行处理。

一种IP网络端到端性能监测方法，包括以下步骤：

A、在IP网络中布置至少两个探针端，在该IP网络中进一步布置控制端；

B、控制端向探针端发送测试配置信息，探针端根据测试配置信息在探针端之间相互执行网络性能监测；

C、探针端将关于网络性能监测的监测数据发送到控制端。

该方法进一步预先包括：探针端向控制端发送注册信息，控制端根据该注册信息对探针端进行注册。

控制端进一步向探针端发送时间同步信息，探针端进一步根据该时间同步信息与控制端实现时间同步。

所述测试配置信息包括：控制端IP地址、发送监测数据包的探针端名称及IP地址、接收监测数据包的探针端名称及IP地址、监测数据包的协议类型、监测数据包的包长、监测数据包的发送分布、启动发送监测数据包的时间、结束发送监测数据包的时间。

所述探针端将关于网络性能监测的监测数据发送到控制端为：控制端主动向探针端请求该关于网络性能监测的监测数据，或者控制端从探针端被动接收该关于网络性能监测的监测数据。

所述的IP网络为互联网、电信网、电力网。

从上述技术方案可以看出，在本发明中，提出了一种IP网络端到端性能监测***，包括至少两个位于IP网络中的探针端，还包括位于该IP网络中的控制端；控制端向探针端发送测试配置信息，并接收由探针端发送的关于网络性能监测的监测数据；探针端根据测试配置信息在探针端之间执行网络性能监测，并将关于网络性能监测的监测数据发送到控制端。因此，本发明中通过布置控制端和探针端，将网络测试与测试管理相分离，降低了测试对网络的影响，并且控制端无需执行具体测试工作，不需要维护与所有反射点之间的接收进程，可以将监测数据的处理开销由控制端处理，因此提高了测试精度。同时，由于将管理工作布置在控制端进行，从而可以保证测试的正常进行，能够获得准确的、有效的监测数据，使得数据分析更加方便和客观。

另外，本发明通过探针端之间互相发送测试报文包，还能够提供单向路径的性能指标。而且，本发明中利用GPS时间同步，能够保证全天候、高精度的时间同步。

因此，本发明能够提供一种通用的、端到端的、全天候的，以多种方式测量IP网络QoS的测量方法，可以为互联网运营商、政府监管部门、大型客户、***集成商、测试服务提供商以及测试工具开发商提供统一的衡量网络服务质量的度量方法。

附图说明

图1为根据本发明的IP网络端到端性能监测***的示范性结构示意图。

图2为根据本发明的IP网络端到端性能监测方法的示范性流程图。

图3为根据本发明实施例的探针端的结构示意图。

图4为根据本发明实施例的控制端的结构示意图。

图5为根据本发明实施例的探针端向控制端注册的流程图。

图6为根据本发明实施例的探针端硬件实体结构图。

具体实施方式

为使本发明的目的、技术方案和优点表达得更加清楚明白，下面结合附图及具体实施例对本发明再作进一步详细的说明。

图1为根据本发明的IP网络端到端性能监测***的示范性结构示意图。如图1所示，该IP网络性能监测***包含控制端(Console)和探针端(Probe)，其中探针端的数目至少为两台，而控制端的数目可以为一台，也可以为多台。也就是说，控制端的控制方式既可以为集中式，也可以为分布式。

在大型网络环境下，优选采用多台控制端作分布式控制；在小型网络环境下，优选采用单台控制端作集中式控制。优选地，在大型网络环境下，根据分布式结构，为一定范围内的多台探针端确定与其相对应的控制端。探针端优选位于IP网络的边缘，比如与边缘的交换机/路由器连接，从而使得对IP的性能监测更有实际意义；控制端既可以位于IP网络中央，也可以位于IP网络的边缘，对其位置并无任何限定，只要网络可达即可。

控制端用于向探针端发送测试配置信息，并接收由探针端发送的关于网络性能监测的监测数据；探针端用于根据测试配置信息在探针端之间执行网络性能监测，并将关于网络性能监测的监测数据发送到控制端。控制端既可以主动向探针端请求关于网络性能监测的监测数据，也可以从探针端被动接收该关于网络性能监测的监测数据。

可以由控制端自身对IP网络的网络性能进行统计处理。比如，统计丢包率、网络抖动、网络时延等；也可以由探针端将监测数据发送到控制端，再由控制端对该IP网络的网络性能进行统计处理。

当探针端执行双向往返RTT网络测量时，探针端向该IP网络中的其它探针端发送监测数据包，接收从其它探针端所反射回的监测数据包，并将监测数据包和反射回的监测数据包作为该关于网络性能监测的监测数据发送到控制端；控制端从而根据该监测数据包和反射回的监测数据包之间的差异，对该IP网络的网络性能进行统计处理。

可选地，当探针端执行双向往返RTT网络测量时，还可以由探针端先进行一定的网络性能统计，然后再将初步的网络统计结果发到控制端，控制端再进行相应的进一步统计或者显示等其它处理。此时，探针端向该IP网络中的其它探针端发送监测数据包，接收由其它探针端所反射回的监测数据包，并根据监测数据包和反射回的监测数据包对该IP网络的网络性能进行统计处理，并且将统计处理结果作为该关于网络性能监测的监测数据发送到控制端，由控制端对监测数据进行进一步的统计、或者输出显示等处理操作。

当探针端执行单向网络测量时，探针端向该IP网络中的其它探针端和控制端发送监测数据包；其它探针端接收该监测数据包后向控制端发送该监测数据包；控制端接收到探针端发送来的监测数据包和其它探针端发送过来的监测数据包后，通过对其进行比较，就可以了解该条单向路径的网络性能。

可选地，当探针端执行单向网络测量时，也可以由探针端先进行一定的网络性能统计，然后再将初步的网络统计结果发到控制端，控制端再进行相应的进一步统计或者显示等其它处理。此时，探针端向该IP网络中的其它探针端发送监测数据包；其它探针端接收该监测数据包并进行网络性能统计处理，比如，统计丢包率、网络抖动、网络时延等，然后将网络性能统计处理结果作为关于网络性能监测的监测数据发送到控制端，由控制端对监测数据进行进一步的统计、或者输出显示等处理操作。

另外，控制端还可以负责整个测试过程的注册、管理、调度、存储以及分析等工作。在测试过程中，控制端和探针端协同工作，实现消息的传递，数据的采集和交互。由于将管理工作布置在控制端进行，从而可以保证测试的正常进行，能够获得准确的、有效的监测数据，使得数据分析更加方便和客观。

网络监测***的基本功能是网络性能测试。但是，在测试过程中，监测***还应该保证其自身的稳定性和可靠性，所以，在监测***中应该具有合理的、严格的管理功能，以负责测试具体项目的配置、测试流程的控制和测试故障的探测和处理。监测数据分析功能也是监测***必不可少的一部分。同时，为了方便及时地看到测试结果，监测***还应该具有测试结果的输出功能。

图2为根据本发明的IP网络端到端性能监测方法的示范性流程图。如图2所示，该方法包括以下步骤：

步骤201：在IP网络中布置至少两个探针端，在该IP网络中进一步布置控制端；

步骤202：控制端向探针端发送测试配置信息，探针端根据测试配置信息在探针端之间相互执行网络性能监测；

步骤203：探针端将关于网络性能监测的监测数据发送到控制端。

图3为根据本发明实施例的探针端的结构示意图。如图3所示，探针端包括：探针端控制模块301，用于向控制端发送注册信息，并接收由控制端发送的测试配置信息；探针端数据处理模块302，根据测试配置信息向其它探针端发送监测数据和/或接收由其它探针端所发送的监测数据，并将向其它探针端发送的监测数据和/或由其它探针端所发送的监测数据向控制端发送；GPS同步模块303，用于实现与控制端以及其它探针端的GPS时间同步。

探针端控制模块301可以包括注册机制和配置管理机制。注册机制控制探针端完成向控制端的注册发现过程，配置管理机制控制探针端由网络上接收控制端的测试配置信息。探针端通过接口模块304接收来自控制端的测试配置信息和向控制端的注册。

图4为根据本发明实施例的控制端的结构示意图。如图4所示，控制端包括：控制端控制模块401，用于接收探针端的注册信息，并根据该注册信息对探针端进行注册，并向探针端发送测试配置信息；控制端数据处理模块402，用于接收并存储由探针端发送的关于网络性能监测的监测数据，并根据该关于网络性能监测的监测数据对该IP网络的网络性能进行统计处理；GPS同步模块403，用于实现与探针端的GPS时间同步；故障管理模块405，用于对网络性能监测中的故障进行探测，并对故障进行处理。

探针端控制模块401可以包括注册机制和配置管理机制。注册机制控制控制端与探针端完成注册。具体为，在测试开始时收集探针端注册信息，在测试过程中收集探针端更改的注册信息；配置管理机制则控制控制端向探针端进行配置管理，包括测试参数的配置、配置参数的发布和以及测试过程中配置信息的更改。

探针端数据处理模块402从总线接收来自探针端的监测数据，将原始监测数据存储到数据库，并对数据库中的原始监测数据进行分析处理，并且输出和显示分析处理结果。

探针端和控制端之间交换的控制流为TCP数据包，并且通过知名端口进行交互。本发明通过开发IPMN协议进行作为整个***运行的控制规程，协调控制端和探针端的相互操作。该协议的消息以TCP数据报文的形式在控制端和探针端之间交互。IPMN PDU由IPMN头和IPMN消息组成，IPMN协议数据单元(PDU)编码格式如表1所示：

0                   1                   2                   3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

版本	PDU长度
		IPMN标识符
IPMN标识符(可选)
		IPMN标识符(可选)
IPMN标识符(可选)
		IPMN消息

表1

下面对表1各项进行说明。

版本：版本号，1个字节无符号整型，表示IPMN协议版本号。当前协议版本号为1表示IPv4网络，协议版本号为2表示IPv6网络。

PDU长度：PDU长度，3个字节无符号整型，以字节为单位表示PDU长度，不包括版本号和PDU长度字段。

IPMN标识符：IPMN标识符，唯一标识PDU所属发送消息的实体，取值为发送实体的源IP地址。协议版本号为1时，标识符长度为4字节；协议版本号为2时，标识符长度为16字节。

IPMN消息：IPMN消息使用类型-长度-值(TLV)编码方式，可以嵌套进行使用。TLV的编码格式如表2所示：

0                   1                   2                   3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

类型	长度
		值

表2

本发明的方法中还包括：探针端向控制端发送注册信息，控制端根据该注册信息对探针端进行注册。

其中，认证注册机制优选在探针端与控制端的注册代理之间进行，当探针端启动参与测试时，探针端自动将环境信息(机器名、IP地址、Before-Hop等)传递给指定的注册代理。另外，在测试过程中，在探针端失效之前需发送信息来证明探针端能够保持正常通信，因此存活机制也是注册机制的一个组成部分。在测试开始之前，控制端需要获知各个探针端的状态以进行测试参数的配置，如探针端名称(每个测试点具有一个唯一的名称)、探针端的IP地址、探针端的下一跳路由器接口地址(用于探针端的故障判断)以及探针端的工作状态等信息。在探针端***启动之后，探针端收集以上信息，其中信息的收集可以自动收集，也可以手工输入。完成正确注册流程的探针端被写入在线探针端列表，可由控制端决定下一步的测试配置分发，以进行测试。每个探针端在完成正确的注册流程之后均可获得一个有效的生存时间，在生存时间之内与控制端的交互被视为正常通讯，而生存时间超期之后的数据包则视为非法数据，做丢弃处理。因此，在测试过程中，在探针端失效之前必须发送KeepAlive消息来证明探针端能够保持正常通信。为确保控制端安全，KeepAlive消息的流程与注册过程相类似，可以被视为再次注册。探针端应该在生存时间超过2/3的时候进行再次注册，如果没有收到正确的注册应答，应继续发起注册请求，直到收到正确的注册应答为止。经过再次注册之后，控制端将在线探针端列表中该探针端的生存时间进行重置。

在测试过程中，原有探针端的注册信息需要发生变化的时，探针端应该以向控制端重新进行注册，由控制端修改原有在线客户的记录，并执行配置更新的流程。另外，在测试过程中，测试拓扑增加新的探针端与测试之前的探针端注册流程完全相同，只是测试配置的分发略有不同。

图5为根据本发明实施例的探针端向控制端注册的流程图。如图5所示，包括：首先，控制端启动后等待探针端连接请求；当确定有连接请求后，控制端分析探针初次传来的时间以及相应加密数据的正确性；初始信息正确将其登入待认证队列，向其发送一个随机数(Challenge)，并等待探针端计算注册回执。若初始信息不正确，则返回等待探针端连接；探针端收到Challenge之后，将该探针端的密钥与Challenge做单向MD5 Hash算法，并将包含探针端名称、Challenged Password、探针端IP地址、下一跳路由器地址以及工作状态等相关信息的注册回执发送给控制端；控制端从数据库中调出该探针端，用探针端的密钥再次MD5 Hash计算，并将得到的结果与探针端计算结果进行对比，得到接受/拒绝认证注册的结果；计算结果一致则记录探针端相关信息，将其列入测试列表，完成注册流程。若计算结果不一致，则进入注册故障处理过程。

对于本发明中的时钟同步，首先，控制端等待串口数据，并维持超时监测机制，若超时则同步结束，未超时继续等待；接收到串口数据后，判断是否GPRMC打头；若是，则分析语句提取时间信息，若不是，继续等待串口数据；提取到时间信息之后，采样GPS秒脉冲，当秒脉冲引脚出现从低到高的跃变时，设置时间。若无从低到高的跃变，进入超时监测机制。

为确保测试配置的灵活性和有效性，监测***中在控制端和探针端之间实现配置管理机制，由控制端对测试拓扑中的探针端进行测试配置管理。控制端启动之后，即开始在一个已知端口上进行监听，当收到探针端的注册消息，并完成正确的注册流程之后，就将探针端作为在线测试点写入测试列表中，作为一个有效的测试节点。当所有的测试点(假设测试点的拓扑及数量在每一次测试之前应该是事先预知的)都加入测试列表之后，就可以开始对测试进行配置。测试参数的配置也就是对具体测试项目的配置信息。当所有参与测试的探针端完成注册，并加入在线测试列表之后，可以在控制端上按照预期测试拓扑选择若干探针端进行配置。控制端下发的配置报文包含以下信息：采集数据的主/备控制端IP地址，考虑到控制端可能是多台设备，不一定就是配置控制端的地址；发送测试数据包的探针端名称及IP地址(组)；接收测试数据包的探针端名称及IP地址(组)；测试包的协议类型，如ICMP、UDP以及TCP等；测试包的包长；测试包的发送分布，如平均、泊松以及突发等；启动发送测试包的时间；结束发送测试包的时间。以上配置参数可以由手工输入，也可从配置文件中读出。测试参数配置完成后，控制端应将配置下发到参加测试的探针端。

测试配置分发流程包括以下步骤：控制端从配置文件中提取客户要求测试的协议、包长以及发包模式(频率)；在测试任务列表中查找相关协议的测试组；若有相应测试组，通知该测试组各个探针成员添加测试点，没有则新建该协议测试组；控制端在测试组中添加测试测试点之前，必须判断该测试组是否已经开始测试。测试尚未开始可以添加，若已经开始则不能添加；在测试组满足测试条件的情况下，控制端发送测试开始命令通知测试组成员开始测试。

监测***的测试数据交互机制包括探针间的数据交互和探针端与控制端间的数据交互。

当测试配置完成并发布至各个探针端后，测试的控制权即交给了过程管理部分。测试的过程管理是控制测试进程的一套消息机制，它与测试数据的交互机制紧密相关。测试的进程控制主要是控制端对探针端应进行的动作的控制，包括两个方面：测试的流程控制(即测试包的开始、暂停、恢复和终止)以及测试数据的采集。为使控制的流程清晰明确，测试的过程主要由控制端主动发送消息进行控制，探针端只需在控制端的控制之下完成测试工作。测试的过程管理同样需要控制端与探针端之间进行消息的交换，同时，在数据采集的过程中还涉及到大量数据的传送问题。下面具体结合过程管理的控制及消息流程来描述监测***的数据交互过程。

虽然监测***的测试功能主要由探针端完成，但整个测试过程是在控制端的流程控制管理之下进行的。测试的流程控制是测试控制中相对简单的一部分，它只负责控制测试进行的正常过程，并不涉及故障情况的处理，以及测试中可能发生的配置改变的情况，这些工作将由故障管理和配置管理来完成。正常的测试流程包括测试启动、测试暂停、测试恢复以及测试终止操作，分别如下：

测试的启动：

当测试配置发布并保存在探针端之后，控制端即以轮询方式向各个探针端发送“test start”消息，表示正式的测试已经启动，当探针端收到这一消息后，立即启动测试线程，开始进行测试，并同时向控制端回送一个“teststarted”消息，以示启动成功，控制端收到这一消息后，将依次向下一个探针端发送“test start”消息，直至所有探针端都以开始启动测试。同时，控制端在收到第一个“test started”消息后即启动测试时间定时器，该定时器的超时时间设定为测试的总进行时间，测试数据采集定时器也同时启动，准备进行测试数据的采集工作。

具体到每个探针端，在测试工作启动以后，探针端根据来自控制端的测试参数配置信息，启动测试线程，配置测试数据包(包括测试包的协议类型、大小以及到达分布等)，向其接收测试数据包的探针端发送测试包。探针端每发送一个测试包，就在本端的管道中(如果测试数据量很大，可以存入本地数据库的发送表中)对其进行记录。这个工作一直进行下去，直到控制端对其发出测试终止的控制信息。

测试的暂停：在测试进行过程中，管理员可能需要暂时停止测试，此时，控制端向探针端发出“test halt”消息，探针端收到消息后，立即挂起运行中的所有测试线程；同时，控制端的数据采集计时器也应暂停。当“test halt”消息发出后，数据分析模块即将之后的时间作为无效时间，直到测试恢复。

测试的恢复：测试暂停之后，应可根据需要恢复测试，此时，控制端向探针端以轮询方式发出“test resume”消息，探针端收到此消息后，立即恢复所有测试线程；同时，控制端的数据分析模块在控制端发出此消息的同时恢复测试有效时间的计时。

测试的终止：当测试时间定时器超时，控制端向探针端以轮询方式发出“test terminate”消息，同时，开始按照数据采集的流程进行最后一次数据采集。探针端收到此消息后，终止所有测试线程，并保存当前测试数据，主动传送测试数据给控制端或等待控制端的数据采集。

探针端与控制端之间的数据交互实际上就是测试数据的采集工作，测试数据的采集也是***中的重要组成，也是比较复杂的一部分，它涉及到数据的存储、传送以及同步更新等问题。

数据采集按照探针端是否主动发起传送，本***可以采用：主动式采集和被动式采集。

主动式采集是指，探针端按照一定规律主动将测试数据发送给控制端。被动式采集是指，探针端等待控制端的数据采集指令，在收到采集指令之后，传送测试数据给控制端。

数据采集按照探针端的存储方式不同，本***可以采用：管道方式和数据库方式。管道方式是指，探针端直接将测试数据包存放于管道之中。数据库方式是指，探针端将测试数据包写入本地数据库之中。

下面对数据采集流程进行说明。数据采集流程包含以下步骤：在测试开始之后，控制端等待接收探针测试数据，并维持超时监测；若在超时之前，控制端未收到任何探针数据，进入采集故障处理；若控制端接收到数据，且数据经过合法性检验，执行命令块将数据写入数据库；若控制端接收到数据，但数据不合法，则丢弃数据，继续等待接收测试数据。

对互联网上端到端的性能测试是基于互联网这个复杂环境进行的，因此，测试的过程中就隐含着许多不确定的因素，这些因素既包括网络设备、网络链路发生的故障，也包括监测***的控制端故障(例如硬件、软件故障)，监测***的探针端故障，甚至可能是由于网络业务繁忙造成拥塞导致监测***无法正常工作。

基于上述分析，监测***应该首先能够察觉到故障的发生；其次应该明确对故障进行定位，由于各种故障的表现可能是相同的——都是无法接收到正确的测试包，因此，要用各种手段判断故障的原因所在，这也是故障管理的一个重要内容；最后，对故障定位之后应对不同的故障采取不同的处理方法，以保证测试能正确顺利的进行。在***设计中，假设控制端的鲁棒性很好，并有专人管理，出现故障的几率很小，所以故障处理仅考虑探针端和网络故障两种情况。监测***通过注册机制的KeepAlive过程来实现故障的发现。探针端正确注册之后，控制端为该探针端维护一个生存时间定时器，正常情况下探针端在注册生存时间超期之前进行再次注册，证明该探针端工作状态正常。控制端在收到再次注册之后，将该探针端生存时间进行更新重置。如果在定时器超时之前，都没有收到再次注册的消息，则确认可能发生故障。如果控制端随后收到探针端的keepalive消息，则表探针端明故障已解除，可将其状态改为″可用″，并恢复正常的测试程序，并记录故障发生/结束的时间以及故障性质。监测***发生的故障主要来自探针端，包括探针端的网络故障和探针端故障两种情况，所以监测***中的故障处理模块主要处理来自探针端的故障。监测***根据故障探测的不同结果，将采取不同的措施来处理故障。

探针端故障的处理：

对于探针端故障，控制端把探针端在在线测试点列表中的状态设置为“不可用”，并在测试点注册表中的最后错误时间中记录故障时间，以备数据分析所用。若探针***的测试模块发生故障，可对模块实施重启操作；若探针***(或探针到网关的链路)发生故障，则需要***操作员的介入。

网络故障的处理：

对于网络故障，控制端不作处理，只是把该探针端在测试点注册列表中的状态设置为″网络故障″。因为网络故障本身也是测试内容的一部分，所以此时的数据可作为正常数据处理。

故障处理流程包含以下步骤：探针端再次注册定时器超时，控制端判断发生故障，向故障探针发送联络包；若收到联络回应，记录探针端的测试模块发生故障，并查阅探针端记录。若探针端记录到测试模块的故障次数达到上限(可设置)，则下达命令重启测试模块；若未收到联络回应，判断是否达到联络包最大重发次数；未达到联络最大重发次数时，继续向故障探针发送联络包；达到联络最大重发次数时，控制端向探针端的网关发送ping包；未收到网关ping响应的情况下，判断网络发生故障，并记录故障事件；收到网关ping响应的情况下，判断探针端(或探针到网关链路)故障，弹出提示告知操作员，并记录故障。

图6为根据本发明实施例的探针端硬件实体结构图。包括以下模块：中央处理***，硬件***的核心部件，通过总线及专用接口与各***互连；存储***，包括FLASH存储器和SDRAM存储器；总线***，包括地址总线和数据总线；I/O***，包括键盘输入及图像输出；同步***，包括GPS同步及NTP同步。

此时，对于整个探针端的软件体系，可以包括以下步骤：探针端开始测试后，首先产生UDP/ICMP套接字；初始化接收缓冲区，并分析测试任务数据；遍历ICMP发送链表，为发送时钟已经到达的探针节点发送测试数据包，并重置该探针节点的发送时钟；发送结束之后，等待套接字接收数据；若收到数据，分析数据；若未收到数据，等待超时继续；遍历UDP发送链表，为发送时钟已经到达的探针节点发送测试数据包，并重置该探针节点的发送时钟；若收到数据，分析数据；若未收到数据，等待超时继续；遍历UDP发送链表，为发送时钟已经到达的探针节点发送测试数据包，并重置该探针节点的发送时钟；整理接收缓冲区数据；遍历ICMP发送链表，处理超时数据；将所有测试数据装帧，计算校验结果后，发送给服务器，等待服务器回应；若发送不成功将数据搜集，挂入链表重新测试；若发送成功则等待控制端的结束信号；收到控制端的结束信号，测试结束；未收到结束信号则继续测试。

以上实施例以互联网为例说明了IP网络端到端实时在线监测***，但本发明并不局限应用于互联网，还可以应用本发明到其它领域，比如，移动通信网络、电力网络、PSTN网络、各种电信网络等，只要该领域涉及到对IP网络端到端在线监测即可。

以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (18)

1、一种网际协议IP网络端到端性能监测***，其特征在于，包括至少两个位于IP网络中的探针端，还包括位于该IP网络中的控制端，其中：

控制端，用于向探针端发送测试配置信息，并接收由探针端发送的关于网络性能监测的监测数据；

探针端，用于根据测试配置信息在探针端之间执行网络性能监测，并将关于网络性能监测的监测数据发送到控制端。

2、根据权利要求1所述的***，其特征在于，所述探针端位于该IP网络的边缘。

3、根据权利要求1所述的***，其特征在于，所述探针端将关于网络性能监测的监测数据发送到控制端为：控制端主动向探针端请求该关于网络性能监测的监测数据，或者控制端从探针端被动接收该关于网络性能监测的监测数据。

4、根据权利要求1所述的***，其特征在于，所述控制端进一步用于根据该关于网络性能监测的监测数据，对该IP网络的网络性能进行统计处理。

5、根据权利要求1所述的***，其特征在于，所述探针端进一步用于根据该关于网络性能监测的监测数据对该IP网络的网络性能进行统计处理，并向控制端发送网络性能统计处理结果；控制端进一步用于接收该网络性能统计处理结果。

6、根据权利要求1所述的***，其特征在于，所述探针端用于向该IP网络中的其它探针端发送监测数据包，接收由其它探针端所反射回的监测数据包，并将监测数据包和反射回的监测数据包作为该关于网络性能监测的监测数据发送到控制端；控制端进一步用于根据该监测数据包和反射回的监测数据包对该IP网络的网络性能进行统计处理。

7、根据权利要求1所述的***，其特征在于，所述探针端用于向该IP网络中的其它探针端和控制端发送监测数据包；其它探针端接收该监测数据包后向控制端发送该监测数据包，控制端进一步用于根据所述探针端发送来的监测数据包和其它探针端发送过来的监测数据包，对该IP网络的网络性能进行统计处理。

8、根据权利要求1所述的***，其特征在于，所述探针端用于向该IP网络中的其它探针端发送监测数据包，接收由其它探针端所反射回的监测数据包，并根据监测数据包和反射回的监测数据包对该IP网络的网络性能进行统计处理，并且将统计处理结果作为该关于网络性能监测的监测数据发送到控制端。

9、根据权利要求1所述的***，其特征在于，所述探针端用于向该IP网络中的其它探针端发送监测数据包；其它探针端接收该监测数据包并进行网络性能统计处理，并且将所述网络性能统计处理结果作为该关于网络性能监测的监测数据发送到控制端。

10、根据权利要求1所述的***，其特征在于，探针端进一步用于向控制端发送注册信息，控制端用于根据该注册信息对探针端进行注册。

11、根据权利要求1所述的***，其特征在于，探针端包括：

探针端控制模块，用于向控制端发送注册信息，并接收由控制端发送的测试配置信息；

探针端数据处理模块，根据测试配置信息向其它探针端发送监测数据和/或接收由其它探针端所发送的监测数据，并将向其它探针端发送的监测数据和/或由其它探针端所发送的监测数据向控制端发送；

全球定位***GPS同步模块，用于实现与控制端的GPS时间同步。

12、根据权利要求1所述的***，其特征在于，控制端包括：

控制端控制模块，用于接收探针端的注册信息，并根据该注册信息对探针端进行注册，并向探针端发送测试配置信息；

控制端数据处理模块，用于接收并存储由探针端发送的关于网络性能监测的监测数据，并根据该关于网络性能监测的监测数据对该IP网络的网络性能进行统计处理；

GPS同步模块，用于实现与探针端的GPS时间同步；

故障管理模块，用于对网络性能监测中的故障进行探测，并对故障进行处理。

13、一种IP网络端到端性能监测方法，其特征在于，包括以下步骤：

A、在IP网络中布置至少两个探针端，在该IP网络中进一步布置控制端；

B、控制端向探针端发送测试配置信息，探针端根据测试配置信息在探针端之间相互执行网络性能监测；

C、探针端将关于网络性能监测的监测数据发送到控制端。

14、根据权利要求13所述的方法，其特征在于，该方法进一步预先包括：探针端向控制端发送注册信息，控制端根据该注册信息对探针端进行注册。

15、根据权利要求13所述的方法，其特征在于，控制端进一步向探针端发送时间同步信息，探针端进一步根据该时间同步信息与控制端实现时间同步。

16、根据权利要求13所述的方法，其特征在于，所述测试配置信息包括：控制端IP地址、发送监测数据包的探针端名称及IP地址、接收监测数据包的探针端名称及IP地址、监测数据包的协议类型、监测数据包的包长、监测数据包的发送分布、启动发送监测数据包的时间、结束发送监测数据包的时间。

17、根据权利要求13所述的方法，其特征在于，所述探针端将关于网络性能监测的监测数据发送到控制端为：控制端主动向探针端请求该关于网络性能监测的监测数据，或者控制端从探针端被动接收该关于网络性能监测的监测数据。

18、根据权利要求13所述的方法，其特征在于，所述的IP网络为互联网、电信网、电力网。

Images