CN111224842A - 一种互联网服务质量监测方法和装置 - Google Patents

一种互联网服务质量监测方法和装置 Download PDF

Info

Publication number
CN111224842A
CN111224842A CN201911420018.6A CN201911420018A CN111224842A CN 111224842 A CN111224842 A CN 111224842A CN 201911420018 A CN201911420018 A CN 201911420018A CN 111224842 A CN111224842 A CN 111224842A
Authority
CN
China
Prior art keywords
data
performance data
performance
end performance
probe server
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN201911420018.6A
Other languages
English (en)
Inventor
张钲
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Datang Software Technologies Co Ltd
Original Assignee
Datang Software Technologies Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Datang Software Technologies Co Ltd filed Critical Datang Software Technologies Co Ltd
Priority to CN201911420018.6A priority Critical patent/CN111224842A/zh
Publication of CN111224842A publication Critical patent/CN111224842A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/12—Network monitoring probes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/04—Network management architectures or arrangements
    • H04L41/042—Network management architectures or arrangements comprising distributed management centres cooperatively managing the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/14—Network analysis or design
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/04—Processing captured monitoring data, e.g. for logfile generation

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Mining & Analysis (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

本发明提供了一种互联网服务质量监测方法，包括：根据数据查询请求，生成端到端性能查询指令；按照预设时间周期，通过起始监测节点的探针服务器向目的节点发送端到端性能查询指令；接收探针服务器在响应于端到端性能查询指令之后，发送的第一端到端性能数据；接收探针服务器在响应于端到端性能查询指令之后，发送的第二端到端性能数据；根据第一端到端性能数据和第二端到端性能数据，生成报文文件入库分析后进行展示，本发明能够获取到完整的端到端性能数据，获取的网络性能数据形式统一，减小了管理服务器的运算量，且不需要运营商的参与，获取的全网性能整体数据为互联网建设规划提供科学依据，提高了互联网规划投资效率。

Description

一种互联网服务质量监测方法和装置
技术领域
本发明涉及互联网通信的技术领域，特别是涉及一种互联网服务质量监测方法，以及一种互联网服务质量监测装置。
背景技术
随着通信技术的快速发展，互联网通信已经成为人们生活中不可或缺的沟通方式。只有提升互联网的基础网络建设，才能丰富互联网的应用业务，使互联网更好的服务社会与生产。
目前方案中，支撑互联网进行基础网络建设所采用的全网性能整体数据是由各个电信网络运营商分别上报自己管辖范围内的网络性能数据到数据中心，由数据中心进行各个电信网络运营商的网络性能数据汇总和分析而得到，其中，各个运营商上报的网络性能数据通过各自的网络性能监控平台监控和采集。
但是，由于各个电信网络运营商上报的网络性能数据的形式不统一，路由信息不完整等问题，数据中心需要对接收到的数据进行格式统一化、路由信息完整化并形成全网性能整体数据的分析报文，导致获取全网性能整体数据的过程繁琐，加重了运营商的运行负担。
发明内容
鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分地解决上述问题的一种互联网服务质量监测方法和相应的一种互联网服务质量监测的装置。
依据本发明的一个方面，提供了一种互联网服务质量监测方法，其特征在于，应用于一种分布式管理系统中的管理服务器，所述分布式管理系统还包括多个监测节点，在每个起始监测节点中部署有探针服务器，数据包由起始监测节点发送至目的节点；
所述方法包括：根据数据查询请求，生成端到端性能查询指令；
按照预设时间周期，通过所述起始监测节点的探针服务器向所述目的节点发送所述端到端性能查询指令；
接收所述探针服务器在响应于所述端到端性能查询指令之后，发送的第一端到端性能数据；
接收所述探针服务器在响应于所述端到端性能查询指令之后，发送的第二端到端性能数据；
根据所述第一端到端性能数据和所述第二端到端性能数据，生成报文文件入库分析后进行展示。
根据本发明的另一方面，提供了一种互联网服务质量检测装置，其特征在于，应用于一种分布式管理系统中的管理服务器，所述分布式管理系统还包括多个监测节点，在每个起始监测节点中部署有探针服务器，数据包由起始监测节点发送至目的节点，包括：
查询指令生成模块，用于根据数据查询请求数据查询请求，生成端到端性能查询指令；
查询指令发送模块，用于按照预设时间周期，通过所述起始监测节点的探针服务器向所述目的节点发送所述端到端性能查询指令；
第一数据接收模块，用于接收所述探针服务器在响应于所述端到端性能查询指令之后，发送的第一端到端性能数据；
第二数据接收模块，用于接收所述探针服务器在响应于所述端到端性能查询指令之后，发送的第二端到端性能数据；
性能数据生成模块，根据所述第一端到端性能数据和所述第二端到端性能数据，生成报文文件入库分析后进行展示。
与背景技术相比，本发明包括以下优点：
依据本发明实施例，提供一种互联网服务质量监测方法，应用于一种分布式管理系统中的管理服务器，分布式管理系统包括多个监测节点，在每个起始监测节点中部署有探针服务器，数据包由起始监测节点发送至目的节点，根据数据请求，生成端到端性能查询指令，按照预设时间周期，通过起始监测节点的探针服务器向目的节点发送端到端性能查询指令，接收探针服务器在响应于端到端性能查询指令之后，发送的第一端到端性能数据和第二端到端性能数据，根据第一端到端性能数据和第二端到端性能数据，生成报文文件入库分析后进行展示，在本发明中，在分布式管理系统的每个起始监测节点中部署探针服务器，管理服务器能够通过同一端到端性能查询指令在所有探针服务器中传输直接获取到全网性能整体数据，由于端到端性能数据包由分布在全国各地、各运营商、各网络层级的起始监测节点的探针服务器统一采集，采集指令为同一端到端性能查询指令，能够保证获取到的数据形式统一，因此，采用本发明的互联网服务质量监测方法获取的互联网网络层端到端路由路径完整，方便数据汇总，网络性能数据形式统一，能够直接形成报文文件，且不需要运营商的参与，不影响运营商的正常运行，获取的全网性能整体数据为互联网建设规划提供科学依据，提高了互联网规划投资效率。
上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。
附图说明
图1示出了互联网的OSI协议架构图；
图2示出了本发明实施例提供的一种互联网服务质量监测方法实施例的步骤流程图；
图3示出了本发明实施例提供的一种互联网服务质量监测方法所建设的平台服务层级分布图；
图4示出了本发明实施例提供的一种路由绕转示意图；
图5示出了本发明实施例的一种互联网服务质量监测方法的交互图；
图6示出了本发明实施例的traceroute指令的工作原理图；
图7示出了本发明实施例提供的一种采集报文界面图；
图8示出了本发明实施例提供的另一种采集报文界面图；
图9示出了本发明实施例提供的另一种采集报文界面图；
图10示出了本发明实施例提供的另一种采集报文界面图；
图11示出了本发明实施例提供的另一种采集报文界面图；
图12示出了根据本发明实施例提供的一种互联网服务质量监测系统实施例的结构框图。
具体实施方式
下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。
为使本发明的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本发明作进一步详细的说明。
实施例一
本发明提供了一种互联网服务质量监测方法，用于监测互联网网络层端到端性能服务质量，互联网的本质就是一系列的网络协议，这个协议叫做开放式系统互联(OSI，OpenSystem Interconnection)协议，按照功能不同，分工不同，可以将OSI协议架构划分为七层。在一些其他实现方式中，还可以将OSI协议架构划分五层、四层等。其中，OSI协议架构的每一层都可以运行不同的协议。
参照图1，图1示出了互联网的OSI协议架构图，从左到右依次介绍：
四层11划分为：应用层111、传输层112、网络层113、网络接口层114。
五层12划分为：应用层121、传输层122、网络层123、数据链路层124、物理层125。
七层13划分为：应用层131、表示层132、会话层133、传输层134、网络层135、数据链路层136、物理层137。
本发明研究互联网的网络层端到端性能服务质量，端到端具体指起始监测节点到目的节点，网络层的功能包括：为数据包选择路由寻址，主要设备是路由器，对应的即传输控制(TCP，Transmission ControlProtocol)/网络之间互连的协议(IP，Internetprotocol)为IP、互联网控制报文协议(ICMP， Internet Control Message Protocol)、路由信息协议(RIP，Routing Information Protocol)、开放最短路径优先(OSPF，OpenShortest Path First)协议、边界网关协议(BGP，Border Gateway Protocol)、网际组管理协议(IGMP，Internet Group Management Protocol)。网络层用于定义网络设备间如何传输数据、如何根据唯一的网络设备地址和处理路由数据包，以及如何提供流和拥塞控制，以防止网络资源的损耗。在互联网进行通信的两个网络设备之间，可能会经过很多个数据链路，也可能还要经过很多通信子网，网络层的任务就是选择合适的网间路由和交换节点，确保数据及时传送。网络层可以将数据链路层提供的帧组成数据包，包中可以封装有网络层包头，网络层包头中含有逻辑地址信息，也就是起始监测节点和目的节点的网络地址，获取路由节点的IP 地址是网络层问题的一部分。本申请提供的一种互联网服务质量监测方法，主要用于在网络层中采集数据传输路径的中的端到端性能数据，即预先在分布式管理系统的每个起始监测节点中部署探针服务器，使得管理服务器能够通过同一端到端性能查询指令发起在所有路由路径的路径节点中传输数据包，从而直接获取到全网性能整体数据，由于各个监测节点的端到端性能数据包由各个监测节点的探针服务器统一采集，采集指令为同一端到端性能查询指令，能够保证获取到的数据形式统一。
参照图2，示出了根据本发明一个实施例的一种互联网服务质量监测方法实施例的步骤流程图，具体可以包括如下步骤：
步骤101，根据数据查询请求，生成端到端性能查询指令。
参照图3，图3示出了本发明实施例提供的一种互联网服务质量监测方法所建设的平台服务层级分布图，分布式管理系统包括：统计分析和支撑服务中心31中的管理服务器311和数据中心312，分布式管理系统还包括多个起始监测节点32、在起始监测节点32中部署的探针服务器321以及目的节点33，包括：终端用户测速设施331、网络服务设施332、应用服务设施333 和资源服务设施334，以及网站、DNS设施、IPV6资源信息等(未在图3 中示出)。
其中，统计分析和支撑服务中心31可以根据管理服务器311采集生成的报文文件和数据中心的数据库信息实现互联网优化、带宽测速分析和网络安全运行，管理服务器311通过接口服务器集群(未在图3中标出)与各个起始监测节点32连接，起始监测节点32可以包括：各地市联通服务器、各地市电信服务器、各地市移动服务器、各地市铁通服务器、国家级互联网骨干直联点等，起始监测节点32中的探针服务器321可以通过多层次监控、多种方法实时采集目的节点33中的各方面数据，本发明专注于图3中的网络服务设施332的互联网网络层端到端性能监测和分析。
在该步骤中，分布式管理系统中的管理服务器可以根据数据中心发出的数据查询请求，生成端到端性能查询指令，该数据查询请求中可以携带有起始监测节点的IP地址、目的节点的IP地址以及预设时间周期等参数。管理服务器可以根据该数据查询请求中携带的参数，生成与这些参数对应的端到端性能查询指令，进而通过端到端性能查询指令查询到从起始监测节点到目的节点的路由路径中的各个路由节点上的路由信息和端到端性能数据，以为互联网基础网络建设和维护提供全网性能整体数据的支撑。
步骤102，按照预设时间周期，通过所述起始监测节点的探针服务器向所述目的节点发送所述端到端性能查询指令。
在该步骤中，管理服务器按照预设时间周期，将生成的端到端性能查询指令通过探针服务器发送到目的节点，端到端性能查询指令能够提供一种查询数据包在探针服务器到目的节点的路由路径中的各个路由节点上传输的网络性能策略，从而使得端到端性能查询指令能够获得整个传输过程中完整的端到端性能数据，以便于根据端到端性能数据形成报文后入库分析，进而对互联网网络层端到端性能服务质量进行监测。
其中，预设时间周期可以根据客户的需求进行设置。例如，当部署探针服务器的监测节点位于城域网时，可以设置预设时间周期为30分钟，当部署探针服务器的监测节点在江苏、河南、四川、重庆等地市、省份以及直辖市的国家级互联网骨干直联点时，可以设置预设时间周期为15分钟。
进一步地，起始监测节点为互联网网络层端到端性能服务质量监测的起始监测点，这些起始监测点在我国地区、运营商、网络层方面覆盖完整，有效的保证了采集的完整性。目的节点为互联网网络层端到端性能服务质量监测的监测目的点，除了国内的监测目的节点外，在国外也有很多监测目的节点。
可选地，所述端到端性能查询指令包括：因特网包探索器指令和路由追踪指令，因特网包探索器指令和路由追踪指令能够提供一种查询数据包在探针服务器到目的节点上传输时的网络性能策略，从而，能够获取完整的端到端性能数据，简化了数据中心的数据分析的繁琐过程，且不会增加运营商的运营负担。
步骤103，接收所述探针服务器在响应于所述端到端性能查询指令之后，发送的第一端到端性能数据。
可选地，步骤103具体可以包括：
子步骤1031，通过接收所述探针服务器在响应于所述因特网包探索器指令之后，发送的所述第一端到端性能数据的方式实现。
在该步骤中，探针服务器向目的节点发送端到端性能查询指令，端到端性能查询指令可以基于ICMP协议在探针服务器至目的节点的路由路径中提供一种网络性能查询策略，ICMP协议规定目的节点必须返回ICMP回送应答消息给起始监测节点，如果起始监测节点在一定时间内收到应答消息，表明目的节点可达，起始监测节点根据接收到的应答消息对应生成第一端到端性能数据，并将该生成的第一端到端性能数据上传至管理服务器，以便管理服务器根据第一端到端性能数据生成报文，本发明中，通过端到端性能查询指令查询到的第一端到端性能数据能够直接上传给管理服务器，不需要运营商的服务器执行查询和上报的操作，不影响运营商的正常运行，也能避免多次数据传输导致的数据丢失和损坏。
步骤104，接收所述探针服务器在响应于所述端到端性能查询指令之后，发送的第二端到端性能数据。
在本步骤中，探针服务器向目的节点发送端到端性能查询指令，端到端性能查询指令接收到目的节点的IP地址后，向目的节点发送携带第一TTL (time tolive，生存时间)为1的数据包，传输路由路径中的第一个路由器在接收到数据包之后，将数据包中携带的第一TTL减1，当第一TTL变为0 之后，数据包当前所在的路由器将该数据包抛弃，并向探针服务器返回一个超时的ICMP数据包。
探针服务器接收到该数据报文后，再次发送携带第二TTL的数据包给目的节点，其中，第二TTL为第一TTL加1，则，传输路由路径中的第二路由器返回给探针服务器一个超时的ICMP数据报文，如此反复，直到将携带的数据包发送至目的节点，则根据端到端性能查询指令能够获取到传输路径中全部路由节点的IP信息，即第二端到端性能数据中的跳数、每跳IP地址和每跳时延，将第二端到端性能数据上传至管理服务器。管理服务器将第二端到端性能数据与第一端到端性能数据汇总和生成报文，采集到的第二端到端性能数据能够直接上传给管理服务器，不需要运营商的服务器执行采集和上报的操作，不影响运营商的正常运行，也能避免多次数据传输导致的数据丢失和损坏。
其中，TTL是IP协议包中的一个值，用于告诉路由器数据包在网络中的时间是否太长而应被丢弃，有很多原因使包在一定时间内不能被传递到目的地。TTL由IP数据包的发送者设置，在IP数据包从起始监测节点到目的节点的整个转发路径上，每经过一个路由器，则把该TTL的值减1，然后再将IP包转发出去。如果在IP包到达目的IP之前，TTL减少为0，路由器将会丢弃收到的TTL＝0的IP包，并向IP包的发送者发送ICMP超时消息，以防止数据包不断在IP互联网络上永不终止地循环。
可选地，步骤104具体可以包括：
子步骤1041，通过接收所述探针服务器在响应于所述路由追踪指令之后，发送的所述第二端到端性能数据的方式实现。
进一步地，以图4为例进行说明，如图4所示，图4示出了本发明实施例提供的一种路由绕转示意图，其中，北京电信41为起始监测节点，上海联通43为目的节点，数据从北京电信41发送至上海联通43时，所传输的路由路径为北京电信41—广州联通42—上海联通43，即，数据没有直接从北京电信41传输至上海联通43，而是在广州联通42实现绕转。北京电信41上的探针服务器向上海联通43上的探针服务器发送端到端性能查询指令，端到端性能查询指令接收到上海联通43的IP地址后，向上海联通43上的探针服务器发送携带TTL＝1的数据包，广州联通42上的探针服务器接收到数据包之后，将数据包中的TTL数值减1，则TTL＝0，广州联通42上的探针服务器抛弃该数据包，并向北京电信41上的探针服务器返回一个超时的 ICMP数据报文，北京电信41上的探针服务器接收到该数据报文后，再次发送携带TTL＝2的数据包给广州联通42上的探针服务器，广州联通42上的探针服务器接收到数据包之后，将数据包中的TTL数值减1，则TTL＝1，广州联通42上的探针服务器将携带TTL＝1的数据包发送给上海联通43上的目的点IP，上海联通43上的探针服务器接收该携带TTL＝1的数据包，并将数据包中的TTL数值减1，则TTL＝0，上海联通43上的探针服务器向北京电信41上的探针服务器返回端口不可达的错误报文。
步骤105，根据所述第一端到端性能数据和所述第二端到端性能数据，生成报文文件，入库分析后进行展示。
在本步骤中，管理服务器可以接收探针服务器发送的第一端到端性能数据和探针服务器发送的第二端到端性能数据，并可以将接收的数据按照预设的报文模板生成报文文件，由于采集到的第一端到端性能数据和第二端到端性能数据的数据形式较为统一，且获取的端到端路由路径完整，管理服务器可以按照预设的报文模板将采集到的第一端到端性能数据和第二端到端性能数据直接生成报文文件，入库分析后进行展示，报文文件先经过解析适配，数据清洗后入数据库。数据库根据数据地区、运营商、网络层级等维度生成数据仓库，主题报告通过数据仓库提取数据，简化了获取全网性能整体数据的过程，提高了管理服务器处理网络性能数据的效率。本发明重点针对互联网端到端基础性能数据采集方法，最后提供一些数据结果体现互联网端到端性能指标的应用价值。
综上所述，提供一种互联网服务质量监测方法，应用于一种分布式管理系统中的管理服务器，分布式管理系统包括多个监测节点，在每个起始监测节点中部署有探针服务器，数据包由起始监测节点发送至目的节点，根据数据请求，生成端到端性能查询指令，按照预设时间周期，通过起始监测节点的探针服务器向目的节点发送端到端性能查询指令，接收探针服务器在响应于端到端性能查询指令之后，发送的第一端到端性能数据和第二端到端性能数据，根据第一端到端性能数据和第二端到端性能数据，生成报文文件入库分析后进行展示，在本发明中，在分布式管理系统的每个监测节点中部署探针服务器，管理服务器能够通过同一端到端性能查询指令在所有探针服务器中传输直接获取到全网性能整体数据，由于各个监测节点的端到端性能数据包由各个监测节点的探针服务器统一采集，采集指令为同一端到端性能查询指令，能够保证获取到的数据形式统一，因此，采用本发明的互联网服务质量监测方法获取的互联网网络层端到端路由路径完整，方便数据汇总，网络性能数据形式统一，能够直接形成报文文件，步骤简单，减小了管理服务器的运算量，且不需要运营商的参与，不影响运营商的正常运行，获取的全网性能整体数据为互联网建设规划提供科学依据，提高了互联网规划投资效率。
实施例二
参考图5，图5示出了本发明实施例的一种互联网服务质量监测方法的交互图，具体可以包括如下步骤：
步骤501，管理服务器根据数据查询请求，生成端到端性能查询指令。
在本步骤中，分布式管理系统中的管理服务器可以根据数据中心发出的数据查询请求，生成端到端性能查询指令，该数据查询请求中携带有起始监测节点的IP地址、目的节点的IP地址以及预设时间周期等参数。管理服务器根据该数据查询请求中携带的参数，生成与这些参数对应的端到端性能查询指令，通过端到端性能查询指令获取到互联网端到端性能数据，互联网端到端性能数据能够形成多维度质量分析报文，客观的呈现我国互联网网络性能质量，评估当下的互联网访问和运行情况。这些性能数据主要包括互联网网络层端到端的时延、丢包率、起始监测点点和目的节点之间的跳数、每一跳的IP地址、路由时延等基础性能指标也包括抖动、跨AS数量等依赖基础性能指标计算得到的二次分析性能指标。
具体地，本发明实施例中的端到端性能查询指令可以包括：因特网包探索器指令(Packet Internet Groper，ping)指令和路由追踪指令(traceroute指令)指令，通过ping指令和traceroute指令，得到时延、丢包率、跳数、每一跳IP地址等信息，通过这些消息分析互联网网络层端到端性能服务质量。
本发明所在案例通过ping指令采集得到互联网网络层端到端的时延与丢包率，并计算时延的抖动指标，通过这些指标评估互联网端到端性能服务质量。
其中，应用层的ping指令的实质是ICMP协议的应用，用来检测网络是否畅通或者网络连接速度的指令，ping指令使用ICMP回送请求与回送回答报文，属于ICMP询问报文，它是应用层直接使用网络协议ICMP的一个特例，它没有通过运输层的TCP或用户数据报协议(UDP，User Datagram Protocol)。ping发送ICMP回送请求消息给目的节点监测节点。ICMP协议是TCP/IP协议集中的一个子协议，属于网络层协议，主要用于在监测节点与路由器之间传递控制信息，包括报告错误、交换受限控制和状态信息等。当遇到IP数据无法访问目标、IP路由器无法按当前的传输速率转发数据包等情况时，会自动发送ICMP消息。ICMP协议规定，目的节点必须返回ICMP 回答应答消息给起始监测节点，如果起始监测节点在一定时间内收到应答，则认为目的节点可达。本发明所在案例利用ping指令采集端到端时延，也就是起始监测节点ping目的节点发出包的往返时间，计算方法是ping指令在发送ICMP报文时将当时的时间值存储在ICMP报文中发出，当应答报文返回时，使用当前时间值减去存放在ICMP报文数据中存放发送请求的时间值来计算往返时间。ping指令返回接收到的数据报字节大小、TTL值、往返时间、丢包率等。
丢包率(Loss Tolerance或Packet Loss Rate)是指测试中所丢失数据包数量占所发送数据组的比率。计算方法是：“[(输入报文-输出报文)/输入报文]*100％”。丢包率与数据包长度以及包发送频率相关。本发明所在案例ping 数据包长度100个字节，每个采集周期发包20次。丢包率越低网络质量越好，如果丢包率达到100％，说明网络不可达。本发明所在案例国内到国际端到端丢包率小于1％为优，1％～5％为中，5％以上为差，发现国内到国际端到端性能丢包率普遍在5％以上，这是我国上网用户访问国际网站体验差的重要原因，急需改善。
时延是指令起始端到目的端的网络延迟，一般以毫秒作为单位。数字越大，网络越差。数字越小，网络越好。在本发明所在案例中用优、中、差描述端到端网络时延性能。互联网国内端到端时延小于40毫秒为优，40毫秒～80毫秒之间为中，80毫秒以上为差；互联网国内到国际端到端时延小于150 毫秒为优，150毫秒～300毫秒之间为中，300毫秒以上为差。缩短时延是网络提升的重要方面，多年来网络不断更新换代，时延变小，比如5G网络时延更短，使万物互联成为可能。
自治系统(AS，autonomous system)，指的是处于一个管理机构控制之下的路由器和网络群组。它可以是一个路由器直接连接到一个局域网上，同时也连到Internet上，它可以是一个由企业骨干网互连的多个局域网。在一个AS系统中的所有路由器必须相互连接，运行相同的路由协议，同时分配同一个自治系统编号，一个AS只能运行一种路由协议。
在互联网中，一个AS是一个有权自主地决定在本系统中应采用何种路由协议的小型单位。这个网络单位可以是一个简单的网络也可以是一个由一个或多个普通的网络管理员来控制的网络群体，它是一个单独的可管理的网络单元(例如一所大学，一个企业或者一个公司个体)。一个自治系统有时也被称为是一个路由选择域。一个自治系统将会分配一个全局的唯一的号码，有时我们把这个号码叫做AS号码。目前全球一共分配了165173个AS号码，中国所分配的AS号码数是2315，占总AS比为1.402％。
本发明所在案例通过traceroute指令获取端到端路径中的路由器IP、起始监测节点和目的节点之间的跳数、每一跳的IP地址、路由时延等数据。
其中，traceroute是Linux和Mac OS等系统默认提供的路由追踪小程序，是一种计算机网络工具。它可显示数据包在IP网络经过的路由器IP地址。通过traceroute可以知道互联网一个网络设备到互联网另一端的网络设备走的什么路径。traceroute有不同的实现版本，有常规基于UDP和ICMP的 traceroute和基于TCP的tcptraceroute。
如图6所示，图6示出了本发明实施例的traceroute指令的工作原理图，traceroute收到目的节点IP后，首先给目的节点发送一个TTL＝1(TTL指生存时间)的UDP数据包，而经过的第一个路由器收到这个数据包之后，自动把TTL减去1，TTL变为0之后，路由器就将这个数据包抛弃，同时产生一个监测节点不可达的ICMP超时数据报文(ICMP TimeExceeded)给监测节点。监测节点收到这个ICMP数据报以后，会发送一个TTL＝2的数据报给目的节点，这样使第二个路由器给监测节点发送访问超时的ICMP数据报文，如此反复，直到到达目的节点，这样Traceroute就可以拿到所有路由器的IP。
具体地，判断UDP是否到达目的节点涉及一个技巧，TCP和UDP协议有一个端口号定义，而普通的网络程序只监控少数的几个号码较小的端口，比如说80,比如说23,等等。而traceroute发送的是端口>30000的UDP报文。因此到达目的节点的时候，目的节点只能发送一个端口不可达的ICMP数据报给监测节点。监测节点接到这个报告就知道目的节点到了。
步骤502，所述管理服务器按照预设时间周期，向探针服务器发送所述端到端性能查询指令。
在本步骤中，管理服务器按照预设时间周期，将生成的端到端性能查询指令发送到探针服务器，以通过端到端性能查询指令查询到端到端性能数据，并根据端到端性能数据分析和形成报文，进而对互联网网络层端到端性能服务质量进行监测。具体地，管理服务器按照预设时间周期，向探针服务器发送ping指令和traceroute指令。
其中，互联网的网络层端到端具体指起始监测节点到目的节点，例如，在全国各运营商和各地市分布了800多台城域网监测节点探针服务器，覆盖全国除台湾外的所有省会城市，此外江苏、河南、四川、湖北、辽宁、黑龙江等省探针服务器覆盖所有地级市，重庆等直辖市探针服务器分布至所辖区县。监测节点所在运营商涵盖电信、联通、移动三大主导运营商，同时包含铁通、鹏博士、方正、爱普、长城宽带、歌华有线等非主导运营商。监测节点探针多数部署在各运营商城域网IDC机房，在江苏、河南、四川、重庆等省和直辖市的骨干互联互通节点也部署了监测节点探针服务器。
其中，骨干直连点是国家级互联网骨干直联点的简称，骨干直连点是国家重要通信枢纽，主要用于汇聚和疏通区域乃至全国网间通信流量，是互联网网间互联架构的顶层关键环节。例如，我国的骨干直连点有3个，分别是北京、上海、广州，运营商网间访问都经过北上广3个直连点绕转。现在我国直连点增加至10个，分别是北京、上海、广州、成都、武汉、西安、沈阳、南京、重庆、郑州以及待建的福建和浙江建设直连点。北京直连点疏导区域为北京、天津、内蒙古、河北；上海直连点疏导区域为上海、浙江；广州直连点疏导区域为广东、福建、海南、广西；成都直连点疏导区域为四川、云南、西藏；武汉直连点疏导区域为湖北、湖南、江西；西安直连点疏导区域为陕西、甘肃、青海、宁夏、新疆；沈阳直连点疏导区域为辽宁、黑龙江、吉林；南京直连点疏导区域为江苏、安徽；重庆直连点疏导区域为重庆、贵州；郑州直连点疏导区域为河南、山东、山西。上述监测节点作为端到端采集的起始监测节点，这些起始监测节点在我国地区、运营商、网络层方面覆盖完整，有效的保证了采集的完整性。
上述监测节点探针IP地址同时也是案例的目的节点，成为采集起始监测节点的国内采集目标IP。除了这些国内目的节点，案例在国外也有很多目的节点，本发明中的起始监测节点和目的节点是互联网网络层端到端性能采集的重要前提，是实现案例中端到端采集的基础设施。
本发明的监测数据涵盖互联网基础设施建设情况、互联网网络层和传输层运行性能、网站性能、互联网域名解析系统性能、网站架构建设、邮箱和文件传输协议应用性能、互联网故障告警、信息安全建设等多个方面。
其中，预设时间周期可以根据客户的需求进行设置。例如，当部署探针服务器的起始监测节点在城域网内时，可以设置预设时间周期为30分钟，当部署探针服务器的起始监测节点为江苏、河南、四川、重庆等地市、省份以及直辖市的国家级互联网骨干直联点时，可以设置预设时间周期为15分钟。
进一步地，起始监测节点为互联网网络层端到端性能服务质量监测的监测源点，在我国地区、运营商、网络层方面覆盖完整，有效的保证了采集的完整性。目的节点为互联网网络层端到端性能服务质量监测的目的点，除了国内的目的节点外，在国外也有很多目的节点。
具体地，ping指令格式为：ping[参数][监测节点名、域名、IP]。
本发明所在案例ping指令应用参数-s和-c，说明如下：
-s代表字节数，指定发送的数据字节数，预设值是56，加上8字节的ICMP 头，一共是64ICMP数据字节，本实施例中-s为100和56。-c代表数目，在发送指定数目的包后停止，本实施例中-c为20。
例如：上海联通目的节点IP地址为220.196.58.135，以每次ping100个字节，ping20次为例，案例执行ping上海联通采集具体指令如下：
ping–s 100–c 20 220.196.58.135
在本发明的另一种实施例中，所述路由追踪指令通过调用探针服务器上的scamper工具，进行采集所述第二端到端性能数据的操作。
具体地，scamper工具也可以执行ping指令进行采集，而且scamper执行结果一次性输出全部结果报文，给采集带来便捷。但考虑到scamper工具毕竟是一类封装工具，ping指令获得的时延和丢包率等网络性能指标对准确性要求很高，如果基础数据有偏差，大数据分析的结果与实际数值的差距会更大。因此，本发明所在案例直接应用ping指令采集网络性能指标，scamper 工具执行ping指令作为补充性的维护手段存在，以下做个介绍：
scamper是CAIDA开发的工具，下载地址支持IPv4和IPv6，是用于主动测量Internet的可扩展的开源数据包探测器，可称为可并行的网络拓扑结构测量工具。不仅支持常用的Traceroute和ping功能，也能实现MDA traceroute、别名解析的部分功能，并且支持控制套接字。本发明所在案例用 scamper采集端到端性能数据，包括路由IP、跳数、路由时延。
scamper执行ping指令的基本格式为scamper-c“ping指令执行参数”–i目标IP地址。
scamper执行ping指令用到了参数-c和-i，参数说明如下：
-c代表scamper所要执行的ping指令和ping指令参数，指令参数书写在双引号内。
-i代表scamper执行ping指令的目标地址。
还是以北京电信作为ping起始监测节点，上海联通作为ping目的节点为例，上海联通作为目的节点的IP地址为220.196.58.135，ping每次100个字节，执行20次，scamper执行ping上海联通采集具体指令如下：
sudo scamper-c"ping-s 100-c 20"-i 220.196.58.135
本发明所在案例用traceroute指令通过调用探针服务器上的scamper工具，进行采集第二端到端性能数据的操作，实现traceroute指令采集。原因是scamper返回报文格式规整，traceroute指令采集返回的报文有时ip和时延等采集指标位置不稳定，在采集频度较高的时候偶尔出现报文被截断的情况。scamper完成一次采集后统一返回，避免了高频采集引起的报文被分割。另外，traceroute采集的重要指标是IP地址，以便观察链路，时延只是参考指标，不必与ping一样担心时延性能指标采集不准确的问题。
scamper指令格式为scamper[参数][IP]
本发明所在案例scamper工具应用参数-i，说明如下：
-i代表ip地址，用于实现对-i后ip地址的traceroute跳数、每跳IP、每跳时延的结果返回。
还是以北京电信到上海联通目的节点为例，上海联通IP地址是 220.196.58.135。
traceroute执行采集指令：traceroute 220.196.58.135
scamper执行采集指令：sudo scamper-i 220.196.58.135
端到端性能查询指令能够使得数据包在探针服务器到目的节点的路由路径中的各个监测节点的探针服务器上传输，因此能够获取传输路径中完整的端到端性能数据，简化了数据中心的数据分析的繁琐过程，且不会增加运营商的运营负担。
步骤503，所述探针服务器响应于接收到的所述端到端性能查询指令后，对应生成第一端到端性能数据。
在本步骤中，探针服务器接收管理服务器发送的ping指令和traceroute 指令，并根据ping指令和traceroute指令将数据包转发给目的节点。其中， ping指令实现作为监测点的探针服务器与目的节点之间发送与接收数据包，得到端到端性能数据：时延、丢包率。traceroute指令能够使得数据包在探针服务器到目的节点路由路径中的各个路由节点上传输，从而使得端到端性能查询指令能够获得整个传输过程中的端到端性能数据：路由节点IP、每跳时延、跳数。根据得到的这些端到端性能数据进行抖动、跨AS数量等依赖基础性能指标计算得到的二次分析性能指标分析和形成报文，进而对互联网网络层端到端性能服务质量进行监测。
其中，探针服务器响应于接收到的ping指令，对应生成第一端到端性能数据，具体地，探针服务器基于ping指令向目的节点发送数据包，ping指令可以基于ICMP协议提供一种查询探针服务器至目的节点的网络性能的策略，探针服务器在一定时间内收到应答消息，表明监测节点可达，则探针服务器根据接收到的应答消息对应生成第一端到端性能数据，具体地，第一端到端性能数据包括：ping平均时延和丢包率。
以步骤502中的ping指令为例，根据ping指令将数据包由北京电信传输到上海联通，在北京电信监测节点探针服务器上发起查询指令，采集周期为30分钟，即每隔30分钟采集一次，北京电信监测节点生成的第一端到端性能数据详见图7，图7示出了本发明实施例提供的一种采集报文界面图。
具体地，倒数第二行中矩形框71中“0％packet loss”，说明丢包率是0％，也就是没有丢包。倒数第一行中第一个矩形框72内27.767是最小时延，第二个矩形框73内27.864是平均时延，第三个矩形框74内27.951是最大时延，在分析统计中多用平均时延27.864，最小时延27.864和最大时延27.951 作为基础参考值入库，不参与分析统计。管理服务器将每次接收的第一端到端性能数据形成报文上传至数据中心分析入库。
在本发明中，可选地，使用scamper工具执行ping命令进行采集的结果如图8所示，图8示出了本发明实施例提供的另一种采集报文界面图，其中以北京电信作为ping起始监测节点，上海联通作为ping目的点为例，上海联通作为目的点的IP地址为220.196.58.135，ping每次100个字节，执行20 次。
步骤504，所述探针服务器将接收到的所述端到端性能查询指令发送至目的节点。
在本步骤中，探针服务器接收管理服务器发送的traceroute指令，并以目的点作为命令参数向目的点发起查询指令。端到端性能查询指令能够提供一种查询探针服务器到目的节点的路由路径中的各个路由节点上的网络性能的策略，从而使得端到端性能查询指令能够获得整个传输过程中的端到端性能数据：端到端时延、丢包率和路由节点IP、每跳时延、跳数，以便于根据得到的这些端到端性能数据进行抖动、跨AS数量等依赖基础性能指标计算得到的二次分析性能指标以及分析和形成报文，进而对互联网网络层端到端性能服务质量进行监测。
步骤505，所述探针服务器响应于接收到的所述端到端性能查询指令后，对应生成端口不可达的ICMP数据包。
在本步骤中，目的节点接收探针服务器发送的traceroute指令后，由于traceroute指令可以提供一种查询数据包在探针服务器至目的节点的路由路径中传输的网络性能策略，获取端到端路由路径信息，每个路由节点根据接收到的traceroute指令传输的数据包，给探针服务器发送一个超时的ICMP 数据包，目的节点根据接收到的数据包，给探针服务器发送一个端口不可达的ICMP数据包，探针服务器接到该端口不可达的ICMP数据包后，提取该超时的ICMP数据包和该端口不可达的ICMP数据包中的路由信息生成第二端到端性能数据。
步骤5，所述探针服务器将生成的所述第一端到端性能数据发送至所述管理服务器。
本步骤中，第一探针服务器将生成的第一端到端性能数据上传给管理服务器，以便管理服务器根据第一端到端性能数据生成报文，本发明中，通过 ping指令查询到的第一端到端性能数据能够直接上传给管理服务器，不需要运营商的服务器执行采集和上报的操作，不影响运营商的正常运行，也能避免多次数据传输导致的数据丢失和损坏。
步骤507，所述目的节点将生成的所述数据包发送至所述探针服务器。
具体地，目的节点将生成的端口不可达的ICMP数据包发送给探针服务器，探针服务器提取路由节点超时的ICMP数据包和端口不可达的ICMP数据包中的路由信息，生成第二端到端性能数据并发送至至管理服务器，以便将第二端到端性能数据与第一端到端性能数据生成报文和汇总，其中，第二端到端性能数据包括：路由追踪跳数、路由追踪每跳IP地址和路由追踪每跳时延，采集到的第二端到端性能数据能够直接上传给管理服务器，不需要运营商的服务器执行采集和上报的操作，不影响运营商的正常运行，也能避免多次数据传输导致的数据丢失和损坏。
在步骤507之后，还包括：
步骤508，所述探针服务器将接收的所述数据包生成的第二端到端性能数据并发送至所述管理服务器。
在本步骤中，探针服务器接收到traceroute指令后，向路由路径中的路由节点发送数据包，并接收路由节点返回的超时的ICMP数据包，和目的节点返回的端口不可达的ICMP数据包，并将接收的数据包中的路由信息生成第二端到端性能数据。探针服务器将生成的第二端到端性能数据发送给管理服务器。其中，第二端到端性能数据包括：路由追踪跳数、路由追踪每跳IP 地址和路由追踪每跳时延。
具体地，探针服务器向目的节点发送traceroute指令，根据traceroute指令在探针服务器至目的节点的路由路径中传输数据包，目的节点根据接收到的traceroute指令，给起始监测节点发送端口不可达的ICMP数据包，起始监测节点接到该数据包后，提取路由节点超时的ICMP数据包和该数据包中的路由信息生成第二端到端性能数据。在完成一次采集后统一返回给探针服务器，以供探针服务器将该第二端到端性能数据上传给管理服务器，管理服务器将第一端到端性能数据和第二端到端性能数据分别进行汇总和生成报文，采集到的第二端到端性能数据能够直接上传给管理服务器，不需要运营商的服务器执行采集和上报的操作，不影响运营商的正常运行，也能避免多次数据传输导致的数据丢失和损坏。
本发明实施例以北京电信到上海联通目的节点为例，分别采用步骤502 中的指令执行采集：
traceroute执行采集指令：traceroute 220.196.58.135
scamper执行采集指令：sudo scamper-i 220.196.58.135
以上两个采集指令执行结果如图9所示，图9示出了本发明实施例提供的另一种采集报文界面图，图9中矩形框91内是traceroute指令执行结果，矩形框92内是scamper指令执行结果。对比可以发现scamper指令返回结果格式规整，而且是一次性返回12跳所有结果，而traceroute是逐条返回每一跳的结果，直到最后一跳结束。
图9中scamper采集结果中第一列是跳数，第二列是每跳IP地址，第三列是每跳时延，采集周期30分钟。监测节点探针服务器将此返回结果形成报文上传至北京数据中心，数据中心将跳数、路由IP，每跳时延分析入库。 traceroute时延的实际统计中用到达目标IP的时延，也就是最后一跳时延，本次北京电信到上海联通端到端traceroute时延是23.640ms，也就是图9最后一行第三列的数值。
本实施例中，端到端性能数据采集采用的指令是sudo scamper-i220.196.58.135，scamper执行traceroute也有其它的用法，比如以下两个指令，第一条指令采用ICMP协议，第二条指令采用TCP协议，在本发明所在案例研究的是网络层性能，因此应用ICMP协议，以下两个指令作为运维验证工具存在。
sudo scamper-c"trace-P ICMP"-i 220.196.58.135
sudo scamper-c"trace-P TCP"-i 220.196.58.135
以上指令执行效果如图10所示，图10示出了本发明实施例提供的另一种采集报文界面图。
可选的，在步骤508之后，还包括：
步骤509，将所述第一端到端性能数据和所述第二端到端性能数据添加至预设的报文模板，生成报文文件入库分析。
在本步骤中，管理服务器可以接收探针服务器发送的第一端到端性能数据和第二端到端性能数据，并可以将接收的数据通过算法生成时延抖动和跨 AS数量等性能二次指标数据，结合端到端性能数据的地区、运营商、网络层级、时间等多个维度进行汇总和统计，按照预设的报文模板生成报文文件，由于采集到的第一端到端性能数据和第二端到端性能数据的数据形式较为统一，且获取的端到端路由路径完整，管理服务器可以按照预设的报文模板将采集到的第一端到端性能数据和第二端到端性能数据直接生成报文文件进行展示，简化了获取全网性能整体数据的过程，提高了管理服务器处理网络性能数据的效率。本发明重点针对互联网端到端基础性能数据采集方法，最后提供一些数据结果体现互联网端到端性能指标的应用价值。
步骤510，根据所述报文文件和一个或多个预设的网络服务质量统计模板，生成一个或多个主题报告。
在本步骤中，管理服务器根据报文文件和一个或多个预设的网络服务质量统计模板，生成各类互联网网络层端到端性能服务质量报告。其中，网络服务质量报告的统计模板包括：运营商网内性能模板、运营商网间性能模板、国内到国际性能模板、国内地区性模板中的一种或多种。
Ping指令采集的指标主要是时延和丢包率，结合起始监测节点和目的节点的地区、运营商、时间、网络层级等维度统计得出端到端网络层统计报告，包括运营商网内性能、运营商网间性能、国内到国际性能、国内地区性能等，以下略作展示：
其中，表1示出了运营商网内性能，表2示出了运营商网间性能，表3 示出了国际性能，表4示出了运营商大区性能。
运营商 时间 PING时延(ms) 丢包率(％) TRACE时延(ms)
电信 20**年**月 39.62 4 39.52
联通 20**年**月 36.09 7 35.98
移动 20**年**月 38.17 3 38.29
铁通 20**年**月 53.47 6 53.26
平均值 20**年**月 39.58 5 39.48
表1
Figure RE-GDA0002429641270000211
Figure RE-GDA0002429641270000221
表2
Figure RE-GDA0002429641270000222
Figure RE-GDA0002429641270000231
Figure RE-GDA0002429641270000241
表3
Figure RE-GDA0002429641270000242
Figure RE-GDA0002429641270000251
表4
Traceroute指令采集的数据结果的主要意义是观察路由跳转情况，尤其是不同运营商间的路由跳转情况。为避免绕转带来的流量和时延开销，我国加大了骨干直连点工程建设力度，现在国家骨干直连点由3个增加到10个，减少了中国广大地区互联网访问的长途绕转，尤其是中西部地区。例如在成都建设直连点前，四川电信访问四川联通要通过北京国家直连点进行路由绕转，增加了长途距离的时延和流量开销，成都建设国家骨干直连点后四川电信访问四川联通直接在成都本地实现绕转，成都负责疏导的四川、云南、西藏地区的网络在网间访问过程中都可以经过成都直连点绕转，不必再远距离绕转。
以图9中北京电信到上海联通的端到端性能数据为例，分别将traceroute 和scamper数据汇总两张表如下所示，包括每一跳的IP地区和运营商信息：
其中，表5示出了Traceroute采集的路由，表6示出了scamper采集的路由。
跳数 IP地址 地区 运营商 AS号
1 219.141.150.165 北京 电信 4847
2 219.141.162.197 北京 电信 4847
3 219.141.158.113 北京 电信 4847
4 202.97.34.186 上海 电信 4134
5 202.97.50.249 上海 电信 4134
6 202.97.17.198 上海 电信 4134
7 219.158.6.255 广州 联通 4837
8 139.226.225.154 上海 联通 17621
9 139.226.203.14 上海 联通 17621
10 112.65.207.162 上海 联通 17621
11 140.207.207.198 上海 联通 17621
12 220.196.58.135 上海 联通 17621
表5
Figure RE-GDA0002429641270000261
Figure RE-GDA0002429641270000271
表6
由上表可以看到traceroute和scamper采集的数据显示电信到联通在广州实现绕转，路径是北京->广州，广州->上海，因为北京和上海都建设了国家骨干直连点，不同运营商跨网访问可以直接互通。因此，正常情况下的路径是北京->上海，实际路由经过广州增加了距离，带来了流量和时延等网络开销，用户上网体验下降。
以上只是举例说明，实际上多数的路由绕转是规范的。以北京电信到广州联通218.107.8.18的路由为例再次分析路由是否规范，图11示出了本发明实施例提供的另一种采集报文界面图，是scamper工具执行的路由结果。
将图11中的数据汇集成表以便观察，如表7所示，按照跳数顺序10标注每一跳的IP所属IP、地区、运营商和AS号。
Figure RE-GDA0002429641270000272
Figure RE-GDA0002429641270000281
表7
由上表可知，北京电信到广州联通是规范路由，没有经过外地远距离绕转，在广州国家骨干直连点实现了电信到联通的跨网。
互联网网络层端到端性能数据应用的方面非常广泛，可以通过时延、丢包率、抖动数值的区间定义网络服务质量标准。例如国内端到端ping时延小于40ms为优，但国内到国外端到端ping时延小于150ms为优，端到端链路根据不同的性能标准在全球地图界面上标注不同颜色，可以清晰的看到国内外互联网网络层端到端性能服务质量情况。
可选地，所述第二端到端性能数据还包括，从所述起始监测节点至所述目的节点的路由路径中的各个路由节点的IP地址。
本发明所在案例采集的互联网网络层端到端性能数据包含但不限于上述应用，随着互联网业务的发展，互联网网络层端到端性能服务质量数据的应用会持续深入。
相对在先技术，本发明实施例具备如下优点：
本发明实施例基于在分布式管理系统的每个监测节点中部署探针服务器，管理服务器能够通过在探针服务器中发送端到端性能查询指令直接获取到全网性能整体数据，端到端性能查询指令获取的网络性能数据形式统一，能够直接形成报文文件，步骤简单，减小了管理服务器的运算量，且不需要运营商的参与，不影响运营商的正常运行，获取的全网性能整体数据为互联网建设规划提供科学依据，提高了互联网规划投资效率。
实施例三
参照图12，图12示出了根据本发明实施例提供的一种互联网服务质量监测装置实施例的结构框图，应用于一种分布式管理系统中的管理服务器，所述分布式管理系统还包括多个监测节点，在每个所述监测节点中部署有探针服务器，数据包由起始监测节点发送至目的节点，本发明提供的一种互联网服务质量监测装置12，具体可以包括如下模块：
查询指令生成模块1201，用于根据数据查询请求数据查询请求，生成端到端性能查询指令。
查询指令发送模块1202，用于按照预设时间周期，通过所述探针服务器向所述目的节点的目的节点发送所述端到端性能查询指令。
第一数据接收模块1203，用于接收所述探针服务器在响应于所述端到端性能查询指令之后，发送的第一端到端性能数据。
第二数据接收模块1204，用于接收所述探针服务器在响应于所述端到端性能查询指令之后，发送的第二端到端性能数据。
性能数据生成模块1205，根据所述第一端到端性能数据和所述第二端到端性能数据，生成报文文件，入库分析后进行展示。
其中，所述端到端性能查询指令包括：因特网包探索器指令和路由追踪指令。第一数据接收模块1203，还包括：
第一数据接收子模块，用于接收所述探针服务器在响应于所述因特网包探索器指令之后，发送的所述第一端到端性能数据。
第二数据接收模块1204，还包括：
第二数据接收子模块，用于接收所述探针服务器在响应于所述路由追踪指令之后，发送的所述第二端到端性能数据。其中，所述路由追踪指令通过调用探针服务器上的scamper工具，进行采集所述第二端到端性能数据的操作。
可选地，性能数据生成模块1205还包括：
报文文件生成模块，用于将所述第一端到端性能数据和所述第二端到端性能数据添加至预设的报文模板，生成报文文件，。
主题报告生成模块，用于根据所述报文文件和一个或多个预设的网络服务质量统计模板，生成一个或多个主题报告。
其中，网络服务质量统计模板包括：运营商网内性能模板、运营商网间性能模板、国内到国际性能模板、国内地区性模板中的一种或多种。
进一步地，所述第二端到端性能数据还包括：从所述起始监测节点至所述目的节点的路由路径中的各个路由节点的IP地址；
相对在先技术，本发明实施例具备如下优点：
本发明实施例基于在分布式管理系统的每个监测节点中部署探针服务器，管理服务器能够通过在探针服务器中发送端到端性能查询指令直接获取到全网性能整体数据，提高了数据获取速度，端到端性能查询指令获取的网络性能数据形式统一，能够直接形成报文文件，步骤简单，减小了管理服务器的运算量，且不需要运营商的参与，不影响运营商的正常运行，获取的全网性能整体数据为互联网建设规划提供科学依据，提高了互联网规划投资效率。
对于系统实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。
在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。
在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。
类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求本身都作为本发明的单独实施例。
本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书(包括伴随的权利要求、摘要和附图)中公开的所有特征以及如此公开的任何方法或者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书(包括伴随的权利要求、摘要和附图)中公开的每个特征可以由提供相同、等同或相似目的的替代特征来代替。
此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使用。
本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当理解，可以在实践中使用微处理器或者数字信号处理器来实现根据本发明实施例的实现数据通讯的方法及系统设备中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。
应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。

Claims (10)

1.一种互联网服务质量监测方法，其特征在于，应用于一种分布式管理系统中的管理服务器，所述分布式管理系统还包括多个监测节点，在每个起始监测节点中部署有探针服务器，数据包由起始监测节点发送至目的节点；所述方法包括：
根据数据查询请求，生成端到端性能查询指令；
按照预设时间周期，通过所述起始监测节点的探针服务器向所述目的节点发送所述端到端性能查询指令；
接收所述探针服务器在响应于所述端到端性能查询指令之后，发送的第一端到端性能数据；
接收所述探针服务器在响应于所述端到端性能查询指令之后，发送的第二端到端性能数据；
根据所述第一端到端性能数据和所述第二端到端性能数据，生成报文文件入库分析后进行展示。
2.根据权利要求1所述的方法，其特征在于，所述端到端性能查询指令包括：因特网包探索器指令和路由追踪指令；
所述接收所述探针服务器在响应于所述端到端性能查询指令之后，发送的第一端到端性能数据，包括：
接收所述探针服务器在响应于所述因特网包探索器指令之后，发送的所述第一端到端性能数据；
所述接收所述探针服务器在响应于所述端到端性能查询指令之后，发送的第二端到端性能数据，包括：
接收所述探针服务器在响应于所述路由追踪指令之后，发送的所述第二端到端性能数据。
3.根据权利要求2所述的方法，其特征在于，所述路由追踪指令通过调用探针服务器上的scamper工具，进行采集所述第二端到端性能数据的操作。
4.根据权利要求1所述的方法，其特征在于，
第一端到端性能数据包括：因特网包探索器平均时延和丢包率；
第二端到端性能数据包括：路由追踪跳数、路由追踪每跳IP地址和路由追踪每跳时延。
5.根据权利要求1所述的方法，其特征在于，根据所述第一端到端性能数据和所述第二端到端性能数据，生成报文文件入库分析后进行展示的步骤，包括：
将所述第一端到端性能数据和所述第二端到端性能数据添加至预设的报文模板，生成报文文件入库分析；
根据所述报文文件和一个或多个预设的网络服务质量统计模板，生成一个或多个主题报告。
6.根据权利要求5所述的方法，其特征在于，
网络服务质量统计模板包括：运营商网内性能模板、运营商网间性能模板、国内到国际性能模板、国内区域性模板中的一种或多种。
7.一种互联网服务质量检测装置，其特征在于，应用于一种分布式管理系统中的管理服务器，所述分布式管理系统还包括多个监测节点，在每个起始监测节点中部署有探针服务器，数据包由起始监测节点发送至目的节点，包括：
查询指令生成模块，用于根据数据查询请求，生成端到端性能查询指令；
查询指令发送模块，用于按照预设时间周期，通过所述起始监测节点的探针服务器向所述目的节点发送所述端到端性能查询指令；
第一数据接收模块，用于接收所述探针服务器在响应于所述端到端性能查询指令之后，发送的第一端到端性能数据；
第二数据接收模块，用于接收所述探针服务器在响应于所述端到端性能查询指令之后，发送的第二端到端性能数据；
性能数据生成模块，根据所述第一端到端性能数据和所述第二端到端性能数据，生成报文文件入库分析后进行展示。
8.根据权利要求7所述的装置，其特征在于，所述端到端性能查询指令包括：因特网包探索器指令和路由追踪指令；
第一数据接收模块，还包括：
第一数据接收子模块，用于接收所述探针服务器在响应于所述因特网包探索器指令之后，发送的所述第一端到端性能数据；
第二数据接收模块，还包括：
第二数据接收子模块，用于接收所述探针服务器在响应于所述路由追踪指令之后，发送的所述第二端到端性能数据。
9.根据权利要求7所述的装置，其特征在于，所述路由追踪指令通过调用探针服务器上的scamper工具，进行采集所述第二端到端性能数据的操作。
10.根据权利要求7所述的装置，其特征在于，所述性能数据生成模块，还包括：
报文文件生成模块，用于将所述第一端到端性能数据和所述第二端到端性能数据添加至预设的报文模板，生成报文文件；
主题报告生成模块，用于根据所述报文文件和一个或多个预设的网络服务质量统计模板，生成一个或多个主题报告。
CN201911420018.6A 2019-12-31 2019-12-31 一种互联网服务质量监测方法和装置 Pending CN111224842A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201911420018.6A CN111224842A (zh) 2019-12-31 2019-12-31 一种互联网服务质量监测方法和装置

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201911420018.6A CN111224842A (zh) 2019-12-31 2019-12-31 一种互联网服务质量监测方法和装置

Publications (1)

Publication Number Publication Date
CN111224842A true CN111224842A (zh) 2020-06-02

Family

ID=70832814

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201911420018.6A Pending CN111224842A (zh) 2019-12-31 2019-12-31 一种互联网服务质量监测方法和装置

Country Status (1)

Country Link
CN (1) CN111224842A (zh)

Cited By (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112527579A (zh) * 2020-12-07 2021-03-19 东莞市嘉田电子科技有限公司 一种具有可识别计算机服务器的识别装置及识别方法
CN113516578A (zh) * 2021-08-04 2021-10-19 甘肃省建筑设计研究院有限公司 一种基于生活圈背景下的公共服务设施片区化管理系统及装置
CN113572644A (zh) * 2021-07-26 2021-10-29 武汉众邦银行股份有限公司 一种互联网云拨测自动化监控方法及装置
CN115914047A (zh) * 2022-12-07 2023-04-04 中盈优创资讯科技有限公司 一种基于twamp的算力网络的网络质量测试方法及装置
CN116579652A (zh) * 2023-05-12 2023-08-11 上海天玑科技股份有限公司 一种it服务质量监测系统及其监测方法

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102891779A (zh) * 2012-09-27 2013-01-23 北京网瑞达科技有限公司 用于ip网络的大规模网络性能测量系统和方法
CN106067854A (zh) * 2016-08-16 2016-11-02 中国联合网络通信集团有限公司 一种网络质量检测方法及设备
WO2017055225A1 (en) * 2015-09-30 2017-04-06 British Telecommunications Public Limited Company Analysis of network performance
CN108028778A (zh) * 2015-07-22 2018-05-11 动态网络服务股份有限公司 生成信息传输性能警告的方法、系统和装置

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN102891779A (zh) * 2012-09-27 2013-01-23 北京网瑞达科技有限公司 用于ip网络的大规模网络性能测量系统和方法
CN108028778A (zh) * 2015-07-22 2018-05-11 动态网络服务股份有限公司 生成信息传输性能警告的方法、系统和装置
WO2017055225A1 (en) * 2015-09-30 2017-04-06 British Telecommunications Public Limited Company Analysis of network performance
CN106067854A (zh) * 2016-08-16 2016-11-02 中国联合网络通信集团有限公司 一种网络质量检测方法及设备

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112527579A (zh) * 2020-12-07 2021-03-19 东莞市嘉田电子科技有限公司 一种具有可识别计算机服务器的识别装置及识别方法
CN113572644A (zh) * 2021-07-26 2021-10-29 武汉众邦银行股份有限公司 一种互联网云拨测自动化监控方法及装置
CN113572644B (zh) * 2021-07-26 2024-01-23 武汉众邦银行股份有限公司 一种互联网云拨测自动化监控方法及装置
CN113516578A (zh) * 2021-08-04 2021-10-19 甘肃省建筑设计研究院有限公司 一种基于生活圈背景下的公共服务设施片区化管理系统及装置
CN115914047A (zh) * 2022-12-07 2023-04-04 中盈优创资讯科技有限公司 一种基于twamp的算力网络的网络质量测试方法及装置
CN116579652A (zh) * 2023-05-12 2023-08-11 上海天玑科技股份有限公司 一种it服务质量监测系统及其监测方法

Similar Documents

Publication Publication Date Title
CN111224842A (zh) 一种互联网服务质量监测方法和装置
EP2859694B1 (en) Physical path determination for virtual network packet flows
US20180173557A1 (en) Physical path determination for virtual network packet flows
EP2518940B1 (en) Automatic network topology detection and modeling
CN107733713B (zh) 混合网络中网络拓扑的获取方法、系统、设备及存储介质
CN111934936B (zh) 网络状态检测方法、装置、电子设备及存储介质
CN112866116B (zh) 网络访问探测方法、装置、设备及存储介质
US10531168B2 (en) Low-latency data switching device and method
CN110838950B (zh) 一种网络性能抖动值的确定方法及装置
CN113746654A (zh) 一种IPv6地址管理和流量分析的方法和装置
Zhou et al. Research on network topology discovery algorithm for Internet of Things based on multi-protocol
US8467301B2 (en) Router misconfiguration diagnosis
Zhao et al. Study on network topology discovery in IP networks
WO2022132208A1 (en) Performance measurement in a segment routing network
Qiuxiang Algorithm research of topology discovery on SNMP
US11991046B2 (en) Determining an organizational level network topology
CN114826978B (zh) 链路质量的测试方法、设备及存储介质
Biagioni A Diagnostic Tool for Ad-Hoc and Delay-Tolerant Networks
Yen et al. Topology discovery service in the universal network
Wang et al. A Survey on the Classic Active Measurement Methods for IPv6
CN105262852A (zh) IPV6网络环境中OSPFv3协议下的网段冲突检测方法及系统
CN117675592A (zh) 利用lldp、arp、snmp实现内网络拓扑自动发现的方法和系统
Shi et al. Intrinsic monitoring within an IPv6 network: mapping node information to network paths
Xu The Research of topology management baseon IPv6 network
Popa Network Traffic Visualization

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination
RJ01 Rejection of invention patent application after publication
RJ01 Rejection of invention patent application after publication

Application publication date: 20200602