CN117675653A - 链路探测方法、装置、设备以及介质 - Google Patents

Abstract

本申请实施例提供了一种链路探测方法、装置、设备以及介质，该方法由客户端执行，该客户端部署于内容分发网络中的边缘服务节点，该方法包括：获取策略端下发的探测任务池，向该探测任务池中的探测任务所指示的目标网络地址发送探测数据包；接收针对该探测数据包的应答数据包，基于该应答数据包确定客户端至目标网络地址的链路探测信息；将链路探测信息上报至代理端，以使该代理端基于链路探测信息分析链路网络状态。采用本申请实施例，可以提高内容分发网络中的链路覆盖率，并提升链路探测结果的有效性。

Description

链路探测方法、装置、设备以及介质

技术领域

本申请涉及计算机网络技术领域，尤其涉及一种链路探测方法、装置、设备以及介质。

背景技术

内容分发网络(Content Delivery Network，CDN)是一种新型网络内容服务体系，可以尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节，使内容传输的更快、更稳定。在CDN系统的日常运维中，涉及到数以千计的机房和数十万台为现网提供服务的设备,这些设备经常由于各种不可抗因素导致链路出现故障,从而影响到CDN用户的使用体验，因此需要对CDN进行探测以确保稳定的网络质量。

目前的探测系统中，通常以HTTP(HyperText Transfer Protocol，超文本传输协议)拨测为主，通过以CDN自身机房模拟用户发出HTTP请求至CDN节点，从而得出拨测的成功率。例如，可以在HTTP拨测系统中添加对应的域名，通过对此域名进行常态化的模拟真实用户访问的真实拨测，进而可以基于拨测的成功率得知各地理区域各运营商的用户到此域名所在平台的链路情况。可见，对于每一个需要拨测的域名均需要手动添加，且每一个域名的拨测过程都是通过模拟实现的，并不能完全覆盖用户至各个域名的链路情况，很容易导致探测中出现盲区，使得链路探测结果并不准确。

发明内容

本申请实施例提供一种链路探测方法、装置、设备以及介质，可以提高内容分发网络中的链路覆盖率，并提升链路探测结果的有效性。

本申请实施例一方面提供了一种链路探测方法，该方法由客户端执行，该客户端部署于内容分发网络中的边缘服务节点，该方法包括：

获取策略端下发的探测任务池，向探测任务池中的探测任务所指示的目标网络地址发送探测数据包；

接收针对探测数据包的应答数据包，基于应答数据包确定客户端至目标网络地址的链路探测信息；

将链路探测信息上报至代理端，以使代理端基于链路探测信息分析链路网络状态。

本申请实施例一方面提供了一种链路探测方法，该方法由代理端执行，包括：

获取客户端上报的链路探测信息；客户端部署于内容分发网络中的边缘服务节点，链路探测信息是由探测数据包对应的应答数据包所确定的，探测数据包是由客户端发送至探测任务池中的探测任务所指示的目标网络地址的，探测任务池是由策略端通过心跳端下发至客户端的；

根据链路探测信息，分析客户端至目标网络地址的链路网络状态。

本申请实施例一方面提供了一种链路探测装置，装置应用于客户端，客户端部署于内容分发网络中的边缘服务节点；包括：

发送模块，用于获取策略端下发的探测任务池，向探测任务池中的探测任务所指示的目标网络地址发送探测数据包；

接收模块，用于接收针对探测数据包的应答数据包，基于应答数据包获取客户端至目标网络地址的链路探测信息；

上报模块，用于将链路探测信息上报至代理端，以使代理端基于链路探测信息分析链路网络状态。

其中，发送模块包括：

心跳包发送单元，用于按照时间频率信息向心跳端发送心跳数据包，以使心跳端基于心跳数据包的接收时间获取客户端的心跳信息，将策略端下发的探测任务池封装为心跳数据包对应的回应数据包；

任务池获取单元，用于接收心跳端返回的回应数据包，获取回应数据包所携带的探测任务池。

其中，该装置还包括：

版本更新模块，用于接收心跳端下发的针对客户端的版本更新信息，基于版本更新信息获取客户端对应的目标安装包；以及

用于在边缘服务节点中执行目标安装包对应的安装脚本，将客户端更新为版本更新信息所指示的目标版本。

其中，探测任务池包括N个探测任务，N为正整数；

发送模块包括：

格式设置单元，用于获取探测任务池中的第i个探测任务，设置第i个探测任务对应的报文格式；i为小于或等于N的正整数；

序列化单元，用于为第i个探测任务生成任务标识符和唯一识别码，基于报文格式，将任务标识符和唯一识别码序列化为探测数据包，将探测数据包发送至第i个探测任务所指示的目标网络地址。

其中，接收模块具体用于：

若应答数据包对应的数据包标识符与任务标识符相同，则对应答数据包进行反序列化，得到应答数据包对应的待校验识别码；

当待校验识别码与唯一识别码相同时，获取第i个探测任务对应的回调函数；回调函数是客户端在发送探测数据包之前，基于任务标识符和唯一识别码注册而成的；

在回调函数中校验应答数据包，得到应答数据包对应的校验结果，当校验结果指示应答数据包校验通过时，根据应答数据包确定第i个探测任务对应的执行结果；

基于执行结果确定客户端至目标网络地址的链路探测信息，为探测任务池进行内存重置。

其中，该装置还包括：

预处理模块，用于获取客户端将探测数据包发送至目标网络地址时的发送时间戳，根据发送时间戳确定探测数据包对应的应答时间范围；以及

用于若客户端在应答时间范围内未接收到探测数据包对应的应答数据包，则从探测任务池中删除目标网络地址。

其中，该装置还包括：

任务重启模块，用于当客户端的网络连接断开时，保存第i个探测任务在客户端中的运行信息；以及

用于当客户端的网络连接重新连接成功时，基于运行信息继续在客户端中执行第i个探测任务。

其中，该装置还包括：

内存限制模块，用于获取客户端在边缘服务节点中的内存占用；以及

用于当内存占用超过内存占用阈值时，在边缘服务节点中重新启动客户端。

本申请实施例一方面提供了一种链路探测装置，装置应用于代理端，包括：

获取模块，用于获取客户端上报的链路探测信息；客户端部署于内容分发网络中的边缘服务节点，链路探测信息是由探测数据包对应的应答数据包所确定的，探测数据包是由客户端发送至探测任务池中的探测任务所指示的目标网络地址的，探测任务池是由策略端通过心跳端下发至客户端的；

链路分析模块，用于根据链路探测信息，分析客户端至目标网络地址的链路网络状态。

其中，链路分析模块包括：

丢包率统计单元，用于根据链路探测信息，统计客户端至目标网络地址的第一链路丢包率；

故障标记单元，用于当第一链路丢包率大于或等于第一丢包阈值时，确定客户端至目标网络地址的链路网络状态为故障状态，将目标网络地址标记为故障网络地址。

其中，该装置还包括：

丢包率获取模块，用于获取客户端至故障网络地址的第二链路丢包率；

故障取消模块，用于当第二链路丢包率小于第二丢包阈值时，确定客户端至故障网络地址的链路网络状态为恢复状态，取消标记故障网络地址。

本申请实施例一方面提供了一种计算机设备，包括存储器和处理器，存储器与处理器相连，存储器用于存储计算机程序，处理器用于调用计算机程序，以使得该计算机设备执行本申请实施例中上述一方面提供的方法。

本申请实施例一方面提供了一种计算机可读存储介质，计算机可读存储介质中存储有计算机程序，计算机程序适于由处理器加载并执行，以使得具有处理器的计算机设备执行本申请实施例中上述一方面提供的方法。

根据本申请的一个方面，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述一方面提供的方法。

本申请实施例中，部署于内容分发网络的边缘服务节点中的客户端可以获取策略端下发的探测任务池，向该探测任务池中的探测任务所指示的目标网络地址发送探测数据包；可以接收探测数据包对应的应答数据包，基于该应答数据包可以获取客户端至目标网络地址的链路探测信息；进而可以将链路探测信息上报至代理端，以使代理端基于链路探测信息分析链路网络状态。可见，探测过程可以从内容分发网络的边缘服务节点中所部署的客户端出发，向现网真实用户访问的目标网络地址(即探测任务池中的探测任务所指示的网络地址)发送探测数据包，进而可以基于该探测数据包对应的应答数据包分析客户端至目标网络地址的链路网络状态，可以提高内容分发网络中的链路覆盖率，并提升链路探测结果的有效性。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的一种链路探测系统的结构示意图；

图2是本申请实施例提供的一种链路探测方法的流程示意图；

图3是本申请实施例提供的一种ping包的流程示意图；

图4是本申请实施例提供的一种探测任务架构的结构示意图；

图5是本申请实施例提供的一种客户端心跳与任务调度机制的示意图；

图6是本申请实施例提供的另一种链路探测方法的流程示意图；

图7是本申请实施例提供的一种代理端架构的结构示意图；

图8是本申请实施例提供的一种心跳端架构的结构示意图；

图9是本申请实施例提供的一种告警信息的示意图；

图10是本申请实施例提供的一种策略端架构的结构示意图；

图11是本申请实施例提供的一种链路探测系统中的设备管理页面的界面示意图；

图12是本申请实施例提供的一种CDN节点丢包率的统计示意图；

图13是本申请实施例提供的一种单个客户端探测数据的统计示意图；

图14是本申请实施例提供的一种单个探测记录的查询界面示意图；

图15是本申请实施例提供的一种链路探测装置的结构示意图；

图16是本申请实施例提供的另一种链路探测装置的结构示意图；

图17是本申请实施例提供的一种计算机设备的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

为便于理解本申请实施例所提出的技术方案，下面对本申请实施例中所涉及到的相关技术进行简单介绍。

云计算(cloud computing)是一种计算模式，它可以将计算任务分布在大量计算机构成的资源池上，使各种应用系统能够根据需要获取计算力、存储空间和信息服务。提供资源的网络被称为“云”。“云”中的资源在使用者看来是可以无限扩展的，并且可以随时获取，按需使用，随时扩展，按使用付费。作为云计算的基础能力提供商，会建立云计算资源池(简称云平台，一般称为IaaS(Infrastructure as a Service，基础设施即服务)平台，在资源池中部署多种类型的虚拟资源，供外部客户选择使用。云计算资源池中主要包括：计算设备(为虚拟化机器，包含操作系统)、存储设备、网络设备。

按照逻辑功能划分，在IaaS(Infrastructure as a Service，基础设施即服务)层上可以部署PaaS(Platform as a Service，平台即服务)层，PaaS层之上再部署SaaS(Software as a Service，软件即服务)层，也可以直接将SaaS部署在IaaS上。PaaS为软件运行的平台，如数据库、web容器等。SaaS为各式各样的业务软件，如web(网页)门户网站、短信群发器等。一般来说，SaaS和PaaS相对于IaaS是上层。

内容分发网络(CDN)节点可以部署在多个地点、多个不同的网络上。这些节点之间可以动态地互相传输内容，对用户的下载行为进行优化，并借此减少内容供应者所需要的带宽成本，改善用户的下载速度，提高系统的稳定性。内容分发网络所需要的节点数量随着需求不同，可以依照所需要服务的对象大小，有可能需要数万台服务器。

ICMP(Internet Control Message Protocol，因特网控制报文协议)是TCP/IP(Transmission Control Protocol/Internet Protocol，传输控制协议/网际协议)协议族的一个子协议，用于在IP主机、路由器之间传递控制消息。控制消息是指网络通不通、主机是否可达、路由是否可用等网络本身的消息。

ping(Packet Internet Groper，因特网包探测器)是指可以用于测试网络连接量的程序；ping命令可以用来作为网络可用性的检查，如ping命令可以对一个网络地址发送测试数据包(或者称为探测数据包)，看该网络地址是否有响应并统计响应时间，以此来测试网络。其中，ping命令发送测试数据包时所使用的协议为ICMP协议。

边缘机房(Outer Center，OC)可以是指企业与运营商合作搭建在各个城市的EIC机房(边缘互联网机房)和GOC机房(运营商合作机房)，边缘机房也可以称为边缘数据中心，或者称为边缘节点。

运营商可以是指进行网络运营和提供服务的通信服务企业，运营商不仅需要从网络角度知道网络运行状况，还需要从服务角度知道网络运行状况。本申请实施例中所涉及的运营商可以是指提供固定电话、移动电话和互联网接入的通信服务公司。

本申请实施例提供了一种基于ICMP协议的链路探测系统，该链路探测系统也可以称为CDN反ping探测系统，该链路探测系统所指示的探测过程可以从CDN本身服务器出发，对现网真实用户访问的目标IP以及中间节点的运营商IP进行链路探测，如可以向现网真实用户访问的目标IP发出探测数据包，进而可以根据接收到的回包来判断该链路的情况。其中，此处的反ping可以是指探测过程中向现网真实用户访问的目标IP发出探测数据包的路径，与现网真实用户访问目标IP的路径是相反的；CDN本身服务器可以是指CDN机房中部署的服务器，此处的服务器可以称为CDN节点，CDN节点可以部署有反ping客户端(用于执行探测任务的客户端)；客户端可以认为是链路探测系统中的探测对象，上述目标IP和运营商IP都可以认为是链路探测系统中的被探测对象。可见，通过该链路探测系统可以全面覆盖从用户到CDN机房整条链路的情况，全面反映真实的现网情况。此外，该链路探测系统可以针对各个地理区域和各个运营商(例如，全国所有省份和各大运营商等)，在所有CDN机房全面覆盖部署客户端，可以实现全链路无遗漏的探测，进而可以提高链路探测的有效性。

其中，CDN节点对应的服务器可以为独立的物理服务器，或者为提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN、以及大数据和人工智能平台等基础云计算服务的云服务器，本申请对此不做限定。

为便于理解，在详细介绍本申请实施例提出的链路探测系统之前，先对本申请实施例所涉及的几个概念进行简单说明，CDN节点可以是指CDN网络中的任一个节点服务器，一个CDN节点都可以认为是一个IP对应的一个服务器，这些服务器可以组成机房来进行现网服务，也就是说，CDN机房可以由多个CDN节点组成。CDN简单来说是一项能够有效缩短时延的技术，其核心理念就是将内容缓存在终端用户的附近，如可以在靠近终端用户的地方，新建一个缓存服务器，此时新建的缓存服务器可以称为CDN边缘服务节点(或者可以称为OC节点)；也就是说，OC节点为CDN节点的主要类型，在CDN节点中部署反ping客户端意味着OC节点中同样可以部署反ping客户端(此处的反ping客户端也可以称为OC客户端，为便于理解，后续直接将其简称为客户端)，本申请实施例以CDN节点中的OC节点类型为例进行具体描述。

请参见图1，图1是本申请实施例提供的一种链路探测系统的结构示意图。如图1所示，该链路探测系统可以包括客户端、心跳端、代理端以及策略端等，其中：

客户端可以部署在OC节点中。该客户端的功能特性可以包括：①客户端本身不保留策略，只起执行作用；例如，客户端本身不保留探测策略(该探测策略包括探测系统中设计的探测任务)，只用于执行探测任务。②客户端可以将结果上报管控工具，或者将结果上报消息队列(Message Queue，MQ)；例如，客户端可以将探测任务的探测结果上报至管控工具或消息队列。其中，管控工具可以是指为用户提供IT(internet Technology，互联网技术)性能管控的SaaS产品，可以定时管控网站、服务和服务器的可用率(Uptime)和响应时间(Response Time)，一旦网站无法连接、web服务器负载过高、数据库压力过大、或是服务器发生错误，该管控工具就会在最短的时间内通知网站管理员，让因网站停摆而造成的损失降到最低；消息队列是分布式系统中重要的组件，主要用于解决应用耦合、异步消息、流量削锋等问题。③客户端可以断连维持,延期任务的执行；例如，客户端可以在网络断开时继续维持正在执行的探测任务，并延期探测任务的执行。④客户端可以将自身状态(例如，客户端所属的OC节点的存活状态，当OC节点所连接的网络通畅时，可以确定该客户端的自身状态为存活状态；当OC节点所连接的网络连接断开时，可以确定该客户端的自身状态为故障状态)与执行结果(例如，客户端所执行的探测任务的结果)上报日志汇。⑤客户端可以自我限制资源使用；例如，客户端可以根据自身需求实时限制资源使用，此处的资源使用可以包括但不限于：客户端在所属OC节点中的CPU(central processing unit，中央处理器)使用率、内存占用等。

心跳端可以为自建机房，心跳端所对应的自建机房比CDN机房的性能要稳定一些。该心跳端的功能特性可以包括：①心跳端可以接收客户端的状态上报，并维持状态；例如，客户端向日志汇上报自身状态时，首先需要将自身状态发送给心跳端，再由心跳端将客户端的状态上报给日志汇，且心跳端在接收到客户端发送的状态后，可以在心跳端维持该状态。②心跳端可以为策略端提供数据查询功能；例如，策略端可以通过心跳端提供的数据查询功能查询整个链路探测系统的运转情况。③心跳端同时接收来自策略端的命令,进行下发，即心跳端可以接收来自策略端发送的命令，并将策略端发送的命令下发至客户端；例如，心跳端可以通过链路探测系统中部署的脚本箱AJS以及拉取的CDNBEST，将策略端发送的命令下发至客户端。

需要说明的是，脚本箱AJS可以是指将客户端版本下发到OC节点的内部工具，负责下发安装包到OC节点并执行相应的安装脚本；CDNBEST是一个安装包存储的源站，如脚本箱AJS可以从CDNBEST获取需要下发至OC节点的客户端版本安装包。

策略端的功能特性可以包括：①策略端可以通过心跳端获取整个CDN系统的运转情况；例如，可以通过心跳端为策略端提供的数据查询功能查询CDN系统中的各个OC节点的运转信息。②策略端可以下发客户端至OC节点，以便于在OC节点中部署客户端；也就是说，OC节点中是否需要部署客户端可以由策略端来确定，当策略端通过心跳端向OC节点下发客户端部署命令时，可以通过该客户端部署命令从CDNBEST拉取对应的客户端版本的安装包，并由脚本箱AJS负责将安装包下发至OC节点并执行相应的安装脚本，由此可以在OC节点中成功部署用于执行探测任务的客户端。③策略端可以对探测任务进行同机房打散或者细分；例如，策略端可以负责分配每一个CDN机房中的OC节点的探测任务数量等。④策略端可以负责客户端IP到目的IP端粒度的下发控制；此处的客户端IP可以是指探测对象(客户端)的网络地址(也可以认为是客户端所属的OC节点的IP)，目的IP可以是指被探测对象的网络地址，如现网真实用户访问的目标IP以及中间节点的运营商IP。⑤策略端可以保留所有的策略UUID(Universally Unique Identifier，通用唯一识别码)；其中，UUID是一种软件构建的标准，其目的是让分布式系统中的所有元素都能有唯一的辨识信息；此处的策略UUID可以是指链路探测系统中所有探测策略的UUID，如策略端可以为链路探测系统中的每一个探测策略(例如，每一个探测任务)保留其唯一的辨识信息，即UUID。

代理端的功能特性可以包括：①代理端可以收拢所有的客户端探测信息；例如，OC节点中所部署的所有客户端关于探测任务的相关信息，都可以上报至代理端，使得代理端可以收拢各个客户端的探测信息。②代理端可以标记全局故障IP；例如，当客户端向现网真实用户访问的目标IP发送探测数据包时，接收到的回包超时，或者根本未接收到回包，那么可以将该目标IP标记为故障IP。③代理端可以汇总上报es集群；例如，代理端可以将收拢到的所有客户端探测信息、全局故障IP进行汇总，并将汇总后的结果上报至es集群。

其中，es是一个分布式全文检索框架，隐藏了复杂的处理机制，内部使用分片机制、集群发现、分片负载均衡(Load Balancer，LB)请求路由；es可以把一个完整的索引分成多个分片，这样可以把一个大的索引拆分为多个，并将其分布到不同的节点上；es集群中可以包括多个节点，其中一个节点为主节点，这个主节点可以通过选举产生，除主节点之外的其余节点可以称为从节点，此处的主从节点是对于es集群内部而言的。

如图1所示，该链路探测系统中还可以包括管控工具、日志汇、缓存数据库、数据库(Database，DB)。其中，管控工具可以实时管控客户端、心跳端、策略端以及代理端的运转情况；日志汇可以用于记载客户端、心跳端、策略端以及代理端的状态等信息；数据库可以用于存储心跳端、代理端以及策略端的数据；缓存数据库可以用于缓存心跳端的数据，该缓存数据库可以包括但不限于：Redis(一种key-value(键值)型的数据库)、Memcached(一种内存型数据库)、Mongodb(一种基于分布式的文件存储的文档型数据系统)。为便于理解，本申请实施例以缓存数据库是Redis为例进行描述，该Redis是一个开源的、基于内存的结构化数据存储媒介，可以作为数据库、缓存服务或消息服务使用。

请参见图2，图2是本申请实施例提供的一种链路探测方法的流程示意图；可以理解地，该链路探测方法可以由图1所示的链路探测系统中的客户端执行，该客户端部署于内容分发网络(CDN)中的边缘服务节点(可以简称为CDN边缘服务节点)。如图2所示，该链路探测方法可以包括以下步骤S101至步骤S103：

步骤S101，获取策略端下发的探测任务池，向探测任务池中的探测任务所指示的目标网络地址发送探测数据包。

在一个或多个实施例中，在图1所示的链路探测系统中，策略端可以负责下发客户端至CDN边缘服务节点(OC节点)，例如，当策略端给CDN系统中的某个OC节点下发了客户端部署命令时，该OC节点中可以部署用于执行探测任务的客户端(也可以称为反ping客户端)。换言之，CDN系统中的各个OC节点中是否需要部署客户端，这是由策略端来决定的。

其中，对于部署了客户端的OC节点而言，该客户端可以获取到策略端为当前所在OC节点下发的探测任务池，该探测任务池中可以包含一个或多个探测任务，如该探测任务池中所包含的探测任务的数量可以记为N个，N为正整数。客户端在执行探测任务时，可以向探测任务所指示的目标网络地址(目标IP)发送探测数据包，该探测数据包可以用于检测客户端(也可以理解为该客户端所在OC节点)至目标IP的链路网络连接性，此处的目标IP可以认为是现网真实用户访问的IP。

需要说明的是，策略端下发的探测任务池并不是直接下发至客户端的，而是将心跳端作为策略端下发探测任务(或者称为探测策略)的渠道，如策略端向CDN系统中的OC节点所部署的客户端下发探测策略时，首先可以将探测策略下发至心跳端，而心跳端在接收到策略端下发的探测策略后，可以对接收到的探测策略进行整理。其中，OC节点中部署的客户端与心跳端之间可以建立心跳机制，该心跳机制可以用于维持客户端与心跳端之间的长连接；例如，当客户端向心跳端每发送一个心跳数据包都可以接收到心跳端返回的回应数据包时，可以确定客户端与心跳端之间一直保持长连接；当客户端向心跳端发送的心跳数据包未接收到心跳端返回的回应数据包时，可以确定客户端与心跳端之间的连接出现故障。

具体的，客户端可以按照时间频率信息向心跳端发送心跳数据包，以使心跳端基于心跳数据包的接收时间获取客户端的心跳信息，进而可以将策略端下发的探测策略所指示的探测任务池封装为心跳数据包对应的回应数据包；客户端可以接收心跳端返回的回应数据包，并获取回应数据包所携带的探测任务池。其中，上述时间频率信息可以是指客户端向心跳端发送心跳数据包的时间间隔信息，如该时间频率信息可以设置为1分钟，此时的客户端可以每分钟向心跳端发送心跳数据包，即每分钟向心跳端进行心跳上报，这样心跳端就可以获得该客户端的心跳信息；同理，对于CDN系统中的各个OC节点中所部署的客户端，均可以向心跳端上报心跳信息，也就是说，心跳端可以获取各个客户端的心跳信息，通过这些心跳信息可以直接反映现网的网络连接状态。心跳端在接收到客户端发送的心跳数据包之后，可以将策略端下发的探测任务以应答数据包的形式下发给客户端，客户端可以通过接收到的应答数据包获取策略端下发的探测任务池。

对于探测任务池中的任意一个探测任务(如第i个探测任务，i可以为小于或等于N的正整数)，可以定义该第i个探测任务对应的报文格式，进而可以为第i个探测任务生成随机的任务标识符(可以记为ID，全称可以为Identification)和唯一识别码(也可以称为通用唯一识别码，可以记为UUID)，基于该报文格式，可以将任务标识符和唯一识别码序列化为探测数据包，进而可以将探测数据包发送至第i个探测任务所指示的目标网络地址。其中，探测数据包的具体结构可以参见下述图3所对应实施例中的描述，此处不再进行赘述。

在一个或多个实施例中，OC节点中部署的客户端可以进行版本更新，而更新的客户端版本是由心跳端下发给OC节点的；例如，OC节点所部署的客户端可以接收心跳端下发的针对该客户端的版本更新信息，基于该版本更新信息可以从CDNBEST获取该客户端对应的目标安装包(例如，最新安装包)，进而可以由脚本箱AJS负责在OC节点中执行该目标安装包对应的安装脚本，并将该客户端更新为版本更新信息所指示的目标版本。

步骤S102，接收针对探测数据包的应答数据包，基于应答数据包确定客户端至目标网络地址的链路探测信息。

具体的，客户端可以接收该探测数据包对应的应答数据包，通过该应答数据包可以确定客户端至目标IP的链路探测信息，如客户端在接收到返回的应答数据包后，可以对应答数据包的数据包标识进行验证，若应答数据包对应的数据包标识符与任务标识符相同(即满足探测任务包的ID与应答数据包的ID相同)，则可以对应答数据包进行反序列化(例如，可以反序列化Data(数据)，该Data可以采用8+16位表示)，得到应答数据包对应的待校验识别码(或者可以称为待校验的UUID)；当待校验识别码与唯一识别码相同时，获取第i个探测任务对应的回调函数，该回调函数是客户端在发送探测数据包之前，基于任务标识符和唯一识别码注册而成的；在回调函数中校验应答数据包(以序列化表示的应答数据包)，得到应答数据包对应的校验结果，当校验结果指示应答数据包校验通过时，根据应答数据包确定第i个探测任务对应的执行结果；基于执行结果确定客户端至目标网络地址的链路探测信息，为探测任务池进行内存重置。其中，客户端对应答数据包的处理过程同样可以参见图3所对应实施例中的描述，此处不再进行赘述。

步骤S103，将链路探测信息上报至代理端，以使代理端基于链路探测信息分析链路网络状态。

具体的，客户端可以将链路探测信息上报至代理端，代理端接收到客户端上报的链路探测信息后，可以基于链路探测信息分析对应的链路网络状态。可以理解的是，CDN系统中的各个OC节点所部署的客户端均可以将探测任务对应的链路探测信息上报至代理端，也就是说代理端可以获取各个OC节点所部署的客户端的链路探测信息，并对接收到的所有链路探测信息进行汇合，并基于汇合的链路探测信息分析链路网络状态，此处的链路网络状态可以包括故障状态和正常状态，故障状态可以认为对应链路的目标IP出现连接故障，正常状态可以认为对应链路的目标IP连接正常。其中，在链路探测系统中部署代理端，可以用于隔离链路探测系统中的客户端与策略端，进而可以避免策略端直接暴露在外网中。

可选地，OC节点中所部署的客户端在执行探测任务池中的探测任务之前，可以对探测任务池中的探测任务进行预处理，如可以获取客户端将探测数据包发送至目标网络地址时的发送时间戳，根据发送时间戳确定探测数据包对应的应答时间范围；若客户端在应答时间范围内未接收到探测数据包对应的应答数据包，则从探测任务池中删除目标网络地址。换言之，客户端向探测任务所指示的目标IP发送探测数据包，若在预设时长(即该应答时间范围的时长，该应答时间范围以发送时间戳为起始时间点)未接收到应答数据包，则可以从探测任务池中删除该目标IP。

可选地，客户端还可以断连维持，延期探测任务的执行，如在客户端执行探测任务池所包含的第i个探测任务的过程中，若检测到客户端的网络连接断开，则可以保存第i个探测任务在客户端中的运行信息；当客户端的网络连接重新连接成功时，可以基于运行信息继续在客户端中执行第i个探测任务，如在重启客户端后可以恢复执行第i个探测任务。

可选地，OC节点中部署的客户端可以设置自限机制，该自限机制可以包括但不限于：CPU(central processing unit，中央处理器)限制、内存限制以及错误重启等。下面以内存限制(也可以称为兜底机制)为例进行具体说明，如可以获取客户端在边缘服务节点(OC节点)中的内存占用，当内存占用超过内存占用阈值(例如，内存占用阈值可以设置为512MB，当然也可以根据实际需求设置为其它数值，本申请对此不做限定)时，在边缘服务节点中重新启动客户端。对于上述CPU限制和错误重启等机制，可以参见下述图3所对应实施例中的描述，此处不再进行赘述。

下面将结合图2至图10，对图1所示的链路探测系统中的各个部分分别进行描述。

在一个或多个实施例中，针对图1所示的链路探测系统中用于执行探测任务的客户端，该客户端需要关注的问题包括但不限于：单个客户端性能问题(如每个客户端在执行探测任务时均不能影响现网业务)、每日探测的IP动态变化(如客户端在执行探测任务时需要动态适配现网状况)、自重启机制(如通过客户端的自重启机制实现链路探测系统的自动化运转，以减少人力参与)、追溯(Trace)机制(如在链路探测系统中通过客户端获取现网服务的目标IP)、过期策略维持(如通过客户端以确保不会出现探测的空白时间区)以及故障IP剔除(如客户端对常态ping不同的IP不关注，更关注于动态的丢包)等。基于前述问题，客户端的设计机制可以从ping包、探测任务以及客户端本身三个方面进行具体描述。其中：

(1)ping包的具体设计可以参见图2，图2是本申请实施例提供的一种ping包的流程示意图；如图2所示，部署在OC节点中的客户端可以从ping任务存储池中获取新的ping任务，并对这新的ping任务进行执行。其中，该ping任务存储池可以供外部调用，ping任务存储池中的每个ping任务都可以认为是pingIP任务，此处的ping任务属于链路探测系统中的探测任务。

在新的ping任务的执行过程中，客户端首先可以定义新的ping任务对应的报文格式，具体可以包括Echo request回显请求(ping请求)和Echo Reply回显应答(ping应答)的报文格式；例如，可以通过Message{Type:8 code:0 body:icmp.Echo{}}来定义Echorequest回显请求(ping请求)，此处的“Type:8”表示ICMP类型字段为8，“code:0”表示ICMP类型字段为0，“body:icmp.Echo{}”表示ICMP的主体为icmp.Echo包；可以通过Message{Type:0 code:0 body:icmp.Echo{}}来定义Echo Reply回显应答(ping应答)，Echo Reply回显应答(ping应答)与Echo request回显请求(ping请求)之间的定义区别在于ICMP的类型字段不同，Echo Reply回显应答(ping应答)对应的ICMP类型字段为0。

进一步地，客户端可以对新的ping任务进行标记，即基于新的ping任务产生随机UUID和随机ID(可以为0-65534范围内的任意数，此处的ID也可以称为任务标识符)，随后可以对UUID和ID进行序列化，如可以将UUID和ID序列化为icmp.Echo包，接着以UUID和ID注册新的ping任务的回调函数，向新的ping任务所指定的网络地址发送icmp.Echo请求，如可以向ping任务指定的网络地址发送IMCP Echo request数据包(也可以称为发包，或者称为探测数据包)。

若客户端接收到ping任务指定的网络地址所返回的应答数据包(可以理解为该网络地址所对应的网络设备在接收到IMCP Echo request数据包后所做出的回应，如可以为IMCP Echo Reply数据包，或者可以称为回包)，则可以对回包的ID进行校验，校验通过后可以通过反序列化数据(Data)取出UUID，并对UUID进行校验并读取出回调函数；在回调函数内校验seq(可以是指以序列化形式来表示的回包)，对每个ping任务对象进行收尾与重置内存。

如图2所示，ping包的设计可以包括对icmp.Echo包的设计，该icmp.Echo包的设计机制可以理解为数据回传机制。该icmp.Echo包的设计中可以自定义ID，即前述产生的随机ID是自定义的，且发包ID和回包ID是相同的，seq(序列)可以表示为第N个回包；该icmp.Echo包的设计中还可以自定义数据(Data)，该Data可以包括24位(即8+16)，前8位序列化时间戳，后16位序列化UUID。

ping包的设计可以增加任务管理者，这样可以保证大量并发下的数据隔离性。该任务管理者的作用可以包括：①任务管理者可以负责测听raw socket(原始套接字)；②任务管理者可以注册ping任务的回调函数；③任务管理者可以在接收到回包后经过双锁过滤，获取回包ID和UUID并执行回调函数。

其中，在ping包设计中引入双锁过滤机制，可以优化CDN网络中的单个客户端性能。在双锁过滤机制中，ID的校验可以使用原子锁进行存取操作，以提高存取操作效率；由于不同ping任务的ID可能会重复，因此可以生成UUID和回调函数之间的映射关系；在执行每一个ping任务时，每个ping任务对象都可以支持内存重置，无需重新分配内存。通过在ping包设计中引入内存重置可以避免频繁的内存分配和回收，seq(序列)校验的内部锁可以为锁指针，这样可以避免回包丢失。

(2)探测任务的架构设计可以参见图4，图4是本申请实施例提供的一种探测任务架构的结构示意图；如图4所示的pingRerport探测任务即为图1所示的链路探测系统所涉及的探测任务。其中，pingRerport探测长任务是链路探测系统中的主力探测任务，除探测长任务之外，还可以包括追溯(Trace)短任务和ping短任务，追溯(Trace)短任务和ping短任务可以在策略端寻找和校验目标IP时使用。

pingRerport探测长任务主流程可以包括任务存储/恢复、定时重置平滑器、目标IP预处理机制以及聚合上报(例如，可以通过coffee来进行聚合上报，此处的coffee可以是CDN质量观测平台，可以根据链路探测系统提供的数据将质量差的链路剔除现网)等。其中，任务存储/恢复可以是指探测长任务的存储以及探测长任务的恢复等过程。定时重置平滑器可以包括：pingRerport探测长任务每个周期都可以释放一个pingIP任务池(也可以认为是前述图2所示的ping任务存储池，或者可以称为探测池)，如一个周期可以为一分钟，那么可以每分钟释放一个pingIP任务池，每个pingIP任务都可以认为是一个阻塞的协程(coroutine，一种程序组件)，由一个令牌产生器来控制该协程的执行速度；并于下一周期重置任务池和令牌产生器，以防止协程累积。其中，该平滑器可以包括使用通道chan的令牌产生器，通过采用类似于令牌的方式来控制协程的最大数量，使用通道chan来实现pingIP任务池。

pingRerport探测长任务每个周期(例如，每分钟)都可以从文件重置需要探测的IP，此处可以给手动去除探测IP留出了插入点，客户端可以对每个周期(如每分钟)要ping的IP进行临时文件存储，来保留现场故障分析和允许脚本介入操作探测流程。目标IP预处理机制可以是指pingRerport探测长任务在执行前需要进行预处理，未正常回包的IP会被剔除pingIP任务池，这样可以避免常态丢包过高。聚合上报可以是指通过CDN质量观测平台(例如，coffee)对探测长任务的执行结果进行收集聚合并上报。

(3)客户端的架构设计可以参见图5，图5是本申请实施例提供的一种客户端心跳与任务调度机制的示意图；如图5所示，客户端的设计可以包括但不限于以下机制：支持三种任务(如ping/trace/pingReport任务等)策略、心跳机制、智研上报(例如，可以通过对客户端的链路探测信息进行整理研究，以生成报告并上报)、任务解析、策略服务上报、任务等待队列、过期任务堆持以及任务恢复等。客户端可以通过两个外网网络云负载均衡(CloudLoadBalancer，CLB)接入到云容器服务(Tencent Kubernetes Engine，TKE)工作负载，如心跳端和代理端；需要说明的是，此处CLB的数量仅为举例说明，本申请可以根据实际需求确定CLB的数量，本申请对此不做限定。

具体地，客户端以agent(代理)的形式部署于现网OC节点上，可以负责具体的任务执行，该客户端的核心机制可以包括：①客户端的架构设计中可以包括心跳机制，如客户端每分钟都可以进行心跳信息上报,并从心跳端获取其下发的策略；②客户端可以支持ping/trace/pingReport三种任务类型，即ping任务、trace任务以及pingReport任务，ping任务和trace任务为短任务，pingReport任务为长时间探测任务；③客户端可以保存运行信息，支持agent重启后任务恢复，如在agent重启时可以恢复重启之前的任务；④过期的pingReport任务不会被关闭，直到下一个pingRerpot任务被下发；⑤对于ping/trace任务,执行前可以进入等待队列，这样可以防止同时执行过多任务；通常情况下，任务并发执行的默认数量可以为10，当然还可以将任务并发数量设置为其他数值，本申请对此不做限定。

客户端除前述核心机制之外还可以设计自限机制，该自限机制可以确保单个客户端业务不受影响。其中，该自限机制可以包括：①CPU限制，可以使用CPULIMIT命令启动对应的OC节点中所部署的客户端，锁死cpu使用率在固定值(例如，可以为15％，本申请对此不做限定)；该CPULIMIT命令可以用于限制CPU速率，可以限制指定进程的CPU百分比；②内存限制，每个周期(此处的周期可以设置为6个小时，本申请对此不做限定)检查进程内存占用，超过预先设置的阈值(例如，512MB，本申请对此不做限定)就会重启(也可以称为兜底机制)；③错误重启，出现底层错误后可以进行重启。

请参见图6，图6是本申请实施例提供的另一种链路探测方法的流程示意图；可以理解地，该链路探测方法由图1所示的链路探测系统中的代理端执行；其中，该链路探测方法可以包括以下步骤S201至步骤S202：

步骤S201，获取客户端上报的链路探测信息；客户端部署于内容分发网络中的边缘服务节点，链路探测信息是由探测数据包对应的应答数据包所确定的，探测数据包是由客户端发送至探测任务池中的探测任务所指示的目标网络地址的，探测任务池是由策略端通过心跳端下发至客户端的。

步骤S202，根据链路探测信息，分析客户端至目标网络地址的链路网络状态。

其中，代理端可以获取客户端上报的链路探测信息，通过对接收到的所有链路探测信息，可以分析客户端至目标IP的链路网络状态。更为具体地，代理端可以根据链路探测信息，可以统计客户端至目标网络地址的第一链路丢包率；当第一链路丢包率大于或等于第一丢包阈值(此处的第一丢包阈值可以设置为98％，或者也可以设置为其它数值)时，确定客户端至目标网络地址的链路网络状态为故障状态，将目标网络地址标记为故障网络地址。获取客户端至故障网络地址的第二链路丢包率，当第二链路丢包率小于第二丢包阈值(此处的第二丢包阈值可以设置为70％，或者也可以设置为其它数值)时，确定客户端至故障网络地址的链路网络状态为恢复状态，取消标记故障网络地址。

需要说明的是，代理端的设计机制除了标记故障IP以及取消故障IP之外，还可以包括其他机制，如针对每个客户端所属的地理区域(例如，部署该客户端的OC节点所属的省份)+客户端运营商(即部署该客户端的OC节点所属的运营商)维度,单独拉取IP进行TOP(此处的TOP可以是指TOP指令，通过该TOP指令可以用于显示每个进程的CPU使用量、内存使用量)，这样可以避免数据失真。

针对图1所示的链路探测系统中的代理端，在代理端架构设计中，该代理端的设计内容可以包括但不限于：①代理端用于隔离客户端和策略端，以避免策略端直接暴露在外网，可以提高策略端的安全性；②代理端可以增加全局处理策略，所有的探测信息都在代理端汇聚，可以针对数据做二次处理；③对于所有探测端(被探测对象)都丢包100％的目标IP，代理端可以将其标记为故障IP，以避免此类数据影响后续的自动化剔除决策。

基于前述设计内容，代理端的架构设计可以参见图7，图7是本申请实施例提供的一种代理端架构的结构示意图；如图7所示，部署在OC节点的客户端agent可以通过两个外网CLB接入到TKE工作负载，此处的两个外网CLB可以为不同地理区域的CLB，如区域1的CLB和区域2的CLB。代理端处于链路探测系统中全量数据的一个交汇点，可以加入全局类型的策略，如故障IP策略，因此在链路探测系统中设计代理端是非常必要的；代理端可以负责数据转换、故障IP标识、上报insight(一种CDN日志采集系统)、故障IP寻找以及数据解压缩等功能，如代理端可以每个周期都进行故障IP检查，并负责故障IP标记与取消标记，此处的周期可以为一分钟，每分钟都进行故障IP检查，该周期可以根据实际需求进行设置，本申请不做限定。

其中，故障IP策略在逻辑上可以包括但不限于：①一个周期内全链路丢包率超过第一丢包阈值的，可以标记为故障IP；②一个周期内故障IP全链路丢包率小于第二丢包阈值时，可以取消故障IP的标记；③针对每个客户端省份+客户端运营商维度，单独拉取IP进行TOP，以避免数据失真；④所有节点(此处的节点是指代理端节点)争取一把分布式锁，每天的检查任务与恢复任务持续由不同的节点进行执行。通过上述故障IP筛选策略，现网的某链路丢包率可以从1.6左右下降到0.15左右，很显然可以大幅度降低链路丢包率。

需要说明的是，上述第一丢包阈值可以设置为98％，第二丢包阈值可以设置为70％。对于上述分布式锁，可以是指对故障IP的寻找，需要一把分布式锁来保证所有节点的节奏统一，此处的场景由于没有性能要求，因此可以选择mysql(一种关系型数据库)表来实现该分布锁；例如，代理端可以通过PDO(PHP Data Objects，PHP数据对象)连接数据库(mysql)，该PDO是一种在PHP(Hypertext Preprocessor，超文本预处理器；是一种计算机编程语言)里连接数据库的使用接口。前述上报insight可以理解为数据上报，反ping数据可以提交到insight指定的MQ(即为insight-MQ)，并被采集到es集群存储，以供CDN质量观测平台coffee进行数据统计和剔除决策。此外，代理端的自身状态等信息可以上报日志汇，代理端的运转状况等信息可以上报管控工具。

针对图1所示的链路探测系统中的心跳端，在心跳端的架构设计中，该心跳端的设计内容可以包括但不限于：①心跳端的本质是将反映现状的心跳信息与需要决策计算的策略分离为心跳端和策略端；②心跳端可以获取全量的客户端心跳信息，进而可以直接反映现网；③心跳端可以独立维持整个客户端覆盖网络，每日都进行巡检，以进行查漏补缺；④心跳端可以作为策略下发的渠道，即策略端下发的探测策略可以先发送给心跳端，进而由心跳端将探测策略下发给客户端。

心跳端的设计机制可以包括但不限于：om(可以理解为CDN资源设备管理系统)信息cache(缓存)、版本更新机制、心跳信息、策略下发、每日拉活、每日覆盖检查，mysql分布式锁等。下面请参见图8，图8是本申请实施例提供的一种心跳端架构的结构示意图；如图8所示，该心跳端架构可以包括策略中心、心跳中心以及管理中心。其中，该策略中心可以包括策略收集和策略整合等；具体地，策略中心可以接收来自策略服务(策略端)下发的探测策略，并在对应的OC节点心跳时进行整理与下发。

心跳中心可以包括心跳流程、单个客户端信息整合与校验、策略下发以及心跳信息查询等；具体地，心跳中心可以接收来自客户端的http心跳数据包，并将探测策略以回包(也可以称为该心跳数据包对应的回应数据包)的形式传递给客户端；此外，心跳中心还可以向策略服务提供所有的可用OC节点的心跳信息。心跳流程可以包括：接收心跳，更新DB(数据库)记录；检查策略中心是否有已接收的探测策略需要下发；若检查到策略中心有已接收的探测策略需要下发，则可以进行策略下发。

管理中心可以包括版本更新、每日拉活、每日覆盖检查以及设备可用性管理(可以理解为OC节点的可用性管理)等；具体地，管理中心可以负责管理所有客户端的存活状态，维持整个链路探测系统中的OC节点的可用性；日常的检查告警与现网部署都可以由管理中心来实现。

其中，客户端版本更新策略可以包括但不限于：①单个客户端下发部署新版本；②机房下发部署新版本；③多次以10％的粒度批量灰度新版本；④多次以30％的粒度批量灰度新版本；⑤全量后，将不可用设备下发部署新版本，并根据结果设置设备可用状态。

每日机房覆盖检查可以包括机房筛选规则和管控规则，该机房筛选规则是在所有om上记录的CDN机房基础上，同时满足状态为“正常”，运营商为“第一类型运营商”/“第二类型运营商”/“第三类型运营商”，名字内含有“OC”字样这三个条件时，可以纳入管控；该管控规则可以包括：每天在固定时间点(或者说在每个周期的固定时间点)检查，如果存在未覆盖机房且该未覆盖机房名下存在未覆盖IP，则可以进行告警推送。

请参见图9，图9是本申请实施例提供的一种告警信息的示意图；如图9所示，可以每天都进行CDN机房覆盖检查，若向CDN机房下发部署客户端后仍然存在未覆盖机房，则表示由于其它因素(即除未下发部署客户端之外的因素)造成下发部署客户端失败，进而可以将告警信息推送给相关的负责人，该告警信息可以包括但不限于：项目介绍、项目所使用应用、IP、异常时间以及告警内容(例如，该警告内容可以包括需要部署客户端的机房数量，部署客户端失败的具体机房以及机房数量)等信息。

需要说明的是，心跳端所包含的策略中心、心跳中心以及管理中心均可以连接到数据库MySQL，通过MySQL可以对策略中心、心跳中心以及管理中心中的数据进行管理，其中心跳中心还可以连接到缓存数据库；此外，心跳端的自身状态等信息同样可以上报日志汇，心跳端的运转状况等信息可以上报管控工具。

针对图1所示的链路探测系统中的策略端，在策略端架构设计中，该策略端的设计内容可以包括但不限于：①策略端可以每日捞取现网访问的真实请求IP(也可以称为目标IP，如现网对CDN网络访问的IP)，并对其进行追溯(trace)操作，得到结果后可以在次日将其打散下发至客户端执行新的探测任务；②在策略端，单IP可以ping同个地理区域中所有的运营商；如单IP可以ping同省份所有的运营商；③同机房IP可以轮询切割目标IP，进行协同探测，这样可以成倍扩大探测面；④策略端可以每日下发新的探测策略，以控制客户端的探测行为。

策略端的设计机制可以包括但不限于：每日地区(地理区域)目标IP收集，目标IP-trace任务调度，IP地区校验，目标IP-ping任务调度，回调机制，每日策略下发，单IP全部地理区域(例如，省份)，同机房轮询切割目标IP，以及最低数量目标IP等。下面请参加图10，图10是本申请实施例提供的一种策略端架构的结构示意图；如图10所示，该策略端架构可以包括链路计算模块、策略中控以及任务下发模块。其中，链路计算模块可以包括trace(追溯)策略下发、ping策略下发以及数据处理等操作，此处的trace策略和ping策略都可以称为探测策略；该链路计算模块所对应的链路计算机制可以包括：①可以将“目标运营商+目标地理区域+机房运营商”定义为一条链路；②每一条链路单独计算需要下发的目标IP；③链路计算过程需要OC节点(CDN服务边缘节点)参与，下发trace任务和ping任务，共同创建需要下发的IP池。

策略中控可以包括目标IP轮询收集和策略分发等操作，该策略中控所对应的策略机制可以包括：①每日地区目标IP收集；②每日策略下发；③单IP全部地理区域(例如，省份)，同机房轮询切割目标IP，最低数量目标IP。

任务下发模块可以包括trace任务回调注册、ping任务回调注册以及pingReport任务下发等操作，该任务下发模块所对应的下发回调注册机制可以包括：①trace任务与ping任务下发，注册回调处理；②该任务下发模块可以访问心跳端，将策略任务下发至心跳端，在对应的客户端IP心跳时下发任务；③可以测听消息队列(MQ)，并接收返回信息；④以任务UUID为key(键)，执行回调处理结果。

需要说明的是，策略端的自身状态等信息同样可以上报日志汇，策略端的运转状况等信息可以上报管控工具；策略中控还可以将其轮询收集的目标IP存储到数据库(DB)；策略端架构的设计机制可以依赖于insight现网日志。本申请实施例所涉及的时间周期“每日”仅为一种举例，在实际应用中还可以采用其余时间周期，本申请对此不做限定。

本申请实施例中，针对客户端上报的链路信息，以“目标运营商+目标地理区域+机房运营商”三元组进行链路剔除，对于链路出现故障的场景，可以自动将其剔除现网覆盖，采用其他正常的机房进行此条链路的覆盖，在无人工参与的情况下可以完成对现网故障的剔除恢复，可以保证CDN用户的使用体验，减轻CDN运维人员对现网的运营压力。此外，本申请实施例所提供的链路探测系统可以定期进行覆盖检查和设备检查，以保证自身探测设备池(可以包括多个OC节点)的全面覆盖，自动进行新建机房的客户端部署，以保证自身的高可靠性和高可用性，可以为现网提供稳定可靠的服务；与此同时，可以每日进行目标IP的维护和探寻,通过追溯(trace)现网日志和追溯策略寻找到真实可探测的目标IP,以实现自动化维护目标IP池的目的。

在一个或多个实施例中，上述链路探测系统还可以为用户提供数据查询功能，通过该数据查询功能可以查询用户(例如，CDN系统运维人员或开发人员)需要的链路信息，下面将结合图11至图14对链路探测系统所提供的数据查询功能进行具体描述。

用户可以通过链路探测系统提供的数据查询功能，查询客户端在各个地理区域各个运营商所部署的机房数量，这样可以确保各个地理区域链路的探测能力。例如，可以在链路探测系统中的任意OC节点前端展示区域节点管理页面，在区域节点管理页面中选择需要查询的运营商类型(例如，第一类型运营商)，以及需要查询的对象(例如，CDN机房)等信息；在完成选择操作后可以对区域节点管理页面中的查询控件执行触发操作，进而可以在该区域节点管理页面中展示客户端在各个地理区域第一类型运营商部署的机房数量，这样就可以直观地看到各个地理区域部署有客户端的机房数量。当然，也可以选择所有类型的运营商，这样就可以在该区域节点管理页面中展示客户端在各个地理区域所有运营商部署的机房数量。

可选地，对于部署有客户端的OC节点(或者可以称为部署有客户端的OC设备)，可以对其进行调整和开启禁用操作，以实现细粒度地调整探测系统的探测设备池的目的，进而可以提高链路探测系统中的设备管理有效性。请参见图11，图11是本申请实施例提供的一种链路探测系统中的设备管理页面的界面示意图；如图11所示的设备管理页面中可以包括“启动设备”控件、“禁用设备”控件、“新增OC设备”控件、“更新客户端版本”控件、“查询”控件等；其中，“启动设备”控件用于启动部署有客户端的OC设备，“禁用设备”控件用于禁用部署有客户端的OC设备，“新增OC设备”控件可以用于新增部署有客户端的OC设备，“更新客户端版本”控件用于更新OC设备中所部署的客户端版本，“查询”控件用于根据设备管理页面中所输入的查询条件查找相应的信息。

如图11所示，用户可以在设备管理页面的区域10a中输入查询条件(或者选择查询条件)，该查询条件可以包括地理区域范围(如省份)、运营商类型、机房、客户端版本以及状态(可以包括启动状态和禁用状态)，在完成查询条件的输入操作后，可以对区域10a中的“查询”控件执行触发操作，此时可以在响应针对该“查询”控件的触发操作，在设备管理页面中显示各个OC设备在前述查询条件下的相关信息，如可以显示各个OC设备分别对应的IP、所属地理区域(省份)、所属运营商、所属机房、所部署的客户端的版本信息以及状态等，此处设备管理页面中所展示的内容仅为一种举例，实际应用中可以根据实际需求选择展示的内容，本申请对此不做限定。如图11所示，各个OC设备的状态均为启动状态，若用户选中区域10b所对应的OC设备，并对“禁用设备”控件执行触发操作，则可以将区域10b所对应的OC设备的状态由启动状态切换为禁用状态。

可选地，用户还可以通过链路探测系统中的管控工具，查看各个CDN节点至全国链路的丢包率。请参见图12，图12是本申请实施例提供的一种CDN节点丢包率的统计示意图；如图12所示，某个CDN节点至全国链路的丢包率如统计图20a所示，该统计图20a可以包括该CDN节点在当前周期和对比周期内的丢包率，可以直观地感知到该CDN节点在当前周期和对比周期的丢包率之间的区别。

可选地，用户还可以通过链路探测系统中的管控工具查看单个客户端(单机)探测数据(一个客户端可以包括多个目标IP的探测数据)，该探测数据可以包括但不限于：探测包数、丢包数量以及丢包率等。请参见图13，图13是本申请实施例提供的一种单个客户端探测数据的统计示意图；如图13所示，当用户通过管控工具查看单个客户端探测数据时，可以选择单个客户端探测数据的呈现方式，如选择当前周期为查看当天(或者可以自定义时间)、选择不同比或者同比呈现、选择以曲线图或者柱状图的形式呈现等。针对单个客户端探测数据，其探测丢包数可以如图13中的统计图30a所示，探测丢包率可以如图13中的统计图30b所示，探测包数可以如图13中的统计图30c所示；其中，统计图30a、统计图30b以及统计图30c都可以包括当前周期和对比周期内的相关数据统计，可以直观地比对两个周期内的探测数据。

可选地，用户还可以通过链路探测系统中的管控工具查询的单个客户端的探测记录，也可以根据实际需求进行聚合查看。请参见图14，图14是本申请实施例提供的一种单个探测记录的查询界面示意图；如图14所示的探测记录查询结果为聚集性分析，用户可以选择聚集性分析中所涉及的指标项数、维度以及该维度进行TOP时参考的数量等信息，如用户选择的维度可以为客户端IP，客户端IP进行TOP时参考的数量为1000，选择的指标可以包括当前结果占比(％)/总占比(％)、均值丢包率(％)、总失败数量(次)、总包数量(次)、丢包率(％)、平均时延(ms)等。在用户完成上述选择后，可以对分析控件执行触发操作，以显示各个客户端IP针对上述所选指标的数值。

本申请实施例中，当某些地理区域对CDN节点(例如，OC节点)封禁时，CDN平台可以自动将被封禁的IP剔除，可以提高现网的反应能力；当存在故障时，平台运维也可以通过对链路探测系统(CDN反ping探测系统)数据的查看,直接拿到反映现网的真实数据,可以更快地定位故障原因，进而可以制定故障恢复策略，可以增加CDN平台的服务质量，并缩短了故障的恢复时间。

可以理解的是，在本申请的具体实施方式中，可能涉及到用户访问的网络地址(IP地址)，当本申请以上实施例运用到具体产品或技术中时，需要获得用户的许可或同意，且相关数据的收集、使用和处理需要遵守相关国家和地区的相关法律法规和标准。

请参见图15，图15是本申请实施例提供的一种链路探测装置的结构示意图。可以理解地，该链路探测装置可以应用在链路探测系统中的客户端中，该客户端部署于内容分发网络中的边缘服务节点(可以称为CDN边缘服务节点)；其中，图15所示的链路探测装置1可以包括：发送模块11，接收模块12，上报模块13；

发送模块11，用于获取策略端下发的探测任务池，向探测任务池中的探测任务所指示的目标网络地址发送探测数据包；

接收模块12，用于接收针对探测数据包的应答数据包，基于应答数据包获取客户端至目标网络地址的链路探测信息；

上报模块13，用于将链路探测信息上报至代理端，以使代理端基于链路探测信息分析链路网络状态。

可选地，接收模块12具体用于：

若应答数据包对应的数据包标识符与任务标识符相同，则对应答数据包进行反序列化，得到应答数据包对应的待校验识别码；

当待校验识别码与唯一识别码相同时，获取第i个探测任务对应的回调函数；回调函数是客户端在发送探测数据包之前，基于任务标识符和唯一识别码注册而成的；

在回调函数中校验应答数据包，得到应答数据包对应的校验结果，当校验结果指示应答数据包校验通过时，根据应答数据包确定第i个探测任务对应的执行结果；

基于执行结果确定客户端至目标网络地址的链路探测信息，为探测任务池进行内存重置。

其中，发送模块11，接收模块12，上报模块13的具体功能实现方式可以参见图2所对应实施例中的步骤S101至步骤S103，此处不再进行赘述。

在一个或多个实施例中，发送模块11包括：心跳包发送单元111，任务池获取单元112，格式设置单元113，序列化单元114；

心跳包发送单元111，用于按照时间频率信息向心跳端发送心跳数据包，以使心跳端基于心跳数据包的接收时间获取客户端的心跳信息，将策略端下发的探测任务池封装为心跳数据包对应的回应数据包；

任务池获取单元112，用于接收心跳端返回的回应数据包，获取回应数据包所携带的探测任务池。

格式设置单元113，用于获取探测任务池中的第i个探测任务，设置第i个探测任务对应的报文格式；i为小于或等于N的正整数；

序列化单元114，用于为第i个探测任务生成任务标识符和唯一识别码，基于报文格式，将任务标识符和唯一识别码序列化为探测数据包，将探测数据包发送至第i个探测任务所指示的目标网络地址。

其中，心跳包发送单元111，任务池获取单元112，格式设置单元113，序列化单元114的具体功能实现方式可以参见图2所对应实施例中的步骤S101，此处不再进行赘述。

在一个或多个实施例中，该链路探测装置1还包括：版本更新模块14，预处理模块15，任务重启模块16，内存限制模块17；

版本更新模块14，用于接收心跳端下发的针对客户端的版本更新信息，基于版本更新信息获取客户端对应的目标安装包；以及

用于在边缘服务节点中执行目标安装包对应的安装脚本，将客户端更新为版本更新信息所指示的目标版本。

可选地，探测任务池包括N个探测任务，N为正整数；

预处理模块15，用于获取客户端将探测数据包发送至目标网络地址时的发送时间戳，根据发送时间戳确定探测数据包对应的应答时间范围；以及

用于若客户端在应答时间范围内未接收到探测数据包对应的应答数据包，则从探测任务池中删除目标网络地址。

任务重启模块16，用于当客户端的网络连接断开时，保存第i个探测任务在客户端中的运行信息；以及

用于当客户端的网络连接重新连接成功时，基于运行信息继续在客户端中执行第i个探测任务。

内存限制模块17，用于获取客户端在边缘服务节点中的内存占用；以及

用于当内存占用超过内存占用阈值时，在边缘服务节点中重新启动客户端。

其中，版本更新模块14，预处理模块15，任务重启模块16，内存限制模块17的具体功能实现方式可以参见图2所对应实施例中的步骤S102，此处不再进行赘述。

本申请实施例中，探测过程可以从内容分发网络的边缘服务节点中所部署的客户端出发，向现网真实用户访问的目标网络地址(即探测任务池中的探测任务所指示的网络地址)发送探测数据包，进而可以基于该探测数据包对应的应答数据包分析客户端至目标网络地址的链路网络状态，可以提高内容分发网络中的链路覆盖率，并提升链路探测结果的有效性。

请参见图16，图16是本申请实施例提供的一种链路探测装置的结构示意图。可以理解地，该链路探测装置可以应用在链路探测系统中的代理端中；其中，图16所示的链路探测装置2可以包括：获取模块21，链路分析模块22；

获取模块21，用于获取客户端上报的链路探测信息；客户端部署于内容分发网络中的边缘服务节点，链路探测信息是由探测数据包对应的应答数据包所确定的，探测数据包是由客户端发送至探测任务池中的探测任务所指示的目标网络地址的，探测任务池是由策略端通过心跳端下发至客户端的；

链路分析模块22，用于根据链路探测信息，分析客户端至目标网络地址的链路网络状态。

其中，获取模块21，链路分析模块22的具体功能实现方式可以参见图6所对应实施例中的步骤S201至步骤S202，此处不再进行赘述。

链路分析模块22包括：丢包率统计单元221，故障标记单元222；

丢包率统计单元221，用于根据链路探测信息，统计客户端至目标网络地址的第一链路丢包率；

故障标记单元222，用于当第一链路丢包率大于或等于第一丢包阈值时，确定客户端至目标网络地址的链路网络状态为故障状态，将目标网络地址标记为故障网络地址。

其中，丢包率统计单元221，故障标记单元222的具体功能实现方式可以参见图6所对应实施例中的步骤S202，此处不再进行赘述。

在一个或多个实施例中，该链路探测装置2还包括：丢包率获取模块23，故障取消模块24；

丢包率获取模块23，用于获取客户端至故障网络地址的第二链路丢包率；

故障取消模块24，用于当第二链路丢包率小于第二丢包阈值时，确定客户端至故障网络地址的链路网络状态为恢复状态，取消标记故障网络地址。

其中，丢包率获取模块23，故障取消模块24的具体功能实现方式可以参见图6所对应实施例中的步骤S202，此处不再进行赘述。

本申请实施例中，探测过程可以从内容分发网络的边缘服务节点中所部署的客户端出发，向现网真实用户访问的目标网络地址(即探测任务池中的探测任务所指示的网络地址)发送探测数据包，进而可以基于该探测数据包对应的应答数据包分析客户端至目标网络地址的链路网络状态，可以提高内容分发网络中的链路覆盖率，并提升链路探测结果的有效性；通过代理端部署的故障IP筛选策略，可以大幅度降低链路丢包率。

进一步地，请参见图17，图17是本申请实施例提供的一种计算机设备的结构示意图。如图17所示，该计算机设备1000可以包括：处理器1001，网络接口1004和存储器1005，此外，该计算机设备1000还可以包括用户接口1003，和至少一个通信总线1002。其中，通信总线1002用于实现这些组件之间的连接通信；用户接口1003可以包括标准的有线接口、无线接口。网络接口1004可选的可以包括标准的有线接口、无线接口(如WI-FI接口)。存储器1005可以是高速RAM存储器，也可以是非不稳定的存储器(non-volatile memory)，例如至少一个磁盘存储器。存储器1005可选的还可以是至少一个位于远离前述处理器1001的存储装置。如图17所示，作为一种计算机可读存储介质的存储器1005中可以包括操作系统、网络通信模块、用户接口模块以及设备控制应用程序。

其中，在图17所示的计算机设备1000中，网络接口1004可提供网络通讯功能，而用户接口1003主要用于为用户提供输入的接口；而处理器1001可以用于调用存储器1005中存储的设备控制应用程序，以实现：

获取策略端下发的探测任务池，向探测任务池中的探测任务所指示的目标网络地址发送探测数据包；

接收针对探测数据包的应答数据包，基于应答数据包确定客户端至目标网络地址的链路探测信息；

将链路探测信息上报至代理端，以使代理端基于链路探测信息分析链路网络状态；

其中，该客户端部署于内容分发网络中的边缘服务节点。

或者，处理器1001可以用于调用存储器1005中存储的设备控制应用程序，以实现：

获取客户端上报的链路探测信息；客户端部署于内容分发网络中的边缘服务节点，链路探测信息是由探测数据包对应的应答数据包所确定的，探测数据包是由客户端发送至探测任务池中的探测任务所指示的目标网络地址的，探测任务池是由策略端通过心跳端下发至客户端的；

根据链路探测信息，分析客户端至目标网络地址的链路网络状态。

应当理解，本申请实施例中所描述的计算机设备1000可执行前文图2或图6任一项所对应实施例中对链路探测方法的描述，也可执行前文图15所对应实施例中对链路探测装置1以及图16所对应实施例中对链路探测装置2的描述，在此不再赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。

此外，这里需要指出的是：本申请实施例还提供了一种计算机可读存储介质，且计算机可读存储介质中存储有前文提及的链路探测装置1和链路探测装置2所执行的计算机程序，且计算机程序包括计算机指令，当处理器执行计算机指令时，能够执行前文图2或图6任一项所对应实施例中对链路探测方法的描述，因此，这里将不再进行赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。对于本申请所涉及的计算机可读存储介质实施例中未披露的技术细节，请参照本申请方法实施例的描述。作为示例，计算机指令可被部署在一个计算设备上执行，或者在位于一个地点的多个计算设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个计算设备上执行，分布在多个地点且通过通信网络互连的多个计算设备可以组成区块链系统。

此外，需要说明的是：本申请实施例还提供了一种计算机程序产品或计算机程序，该计算机程序产品或者计算机程序可以包括计算机指令，该计算机指令可以存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器可以执行该计算机指令，使得该计算机设备执行前文图2或图6任一项所对应实施例中对链路探测方法的描述，因此，这里将不再进行赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。对于本申请所涉及的计算机程序产品或者计算机程序实施例中未披露的技术细节，请参照本申请方法实施例的描述。

需要说明的是，对于前述的各个方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请并不受所描述的动作顺序的限制，因为依据本申请，某一些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本申请所必须的。

本申请实施例方法中的步骤可以根据实际需要进行顺序调整、合并和删减。

本申请实施例装置中的模块可以根据实际需要进行合并、划分和删减。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，计算机程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，存储介质可为磁碟、光盘、只读存储器(Read-Only Memory，ROM)或随机存储器(Random Access Memory，RAM)等。

以上所揭露的仅为本申请较佳实施例而已，当然不能以此来限定本申请之权利范围，因此依本申请权利要求所作的等同变化，仍属本申请所涵盖的范围。

Claims (16)

1.一种链路探测方法，其特征在于，所述方法由客户端执行，所述客户端部署于内容分发网络中的边缘服务节点；所述方法包括：

获取策略端下发的探测任务池，向所述探测任务池中的探测任务所指示的目标网络地址发送探测数据包；

接收针对所述探测数据包的应答数据包，基于所述应答数据包获取所述客户端至所述目标网络地址的链路探测信息；

将所述链路探测信息上报至代理端，以使所述代理端基于所述链路探测信息分析链路网络状态。

2.根据权利要求1所述的方法，其特征在于，所述获取策略端下发的探测任务池，包括：

按照时间频率信息向心跳端发送心跳数据包，以使所述心跳端基于所述心跳数据包的接收时间获取所述客户端的心跳信息，将策略端下发的探测任务池封装为所述心跳数据包对应的回应数据包；

接收所述心跳端返回的所述回应数据包，获取所述回应数据包所携带的探测任务池。

3.根据权利要求1所述的方法，其特征在于，还包括：

接收所述心跳端下发的针对所述客户端的版本更新信息，基于所述版本更新信息获取所述客户端对应的目标安装包；

在所述边缘服务节点中执行所述目标安装包对应的安装脚本，将所述客户端更新为所述版本更新信息所指示的目标版本。

4.根据权利要求1所述的方法，其特征在于，所述探测任务池包括N个探测任务，N为正整数；

所述向所述探测任务池中的探测任务所指示的目标网络地址发送探测数据包，包括：

获取所述探测任务池中的第i个探测任务，设置所述第i个探测任务对应的报文格式；i为小于或等于N的正整数；

为所述第i个探测任务生成任务标识符和唯一识别码，基于所述报文格式，将所述任务标识符和所述唯一识别码序列化为探测数据包，将所述探测数据包发送至所述第i个探测任务所指示的目标网络地址。

5.根据权利要求4所述的方法，其特征在于，所述基于所述应答数据包获取所述客户端至所述目标网络地址的链路探测信息，包括：

若所述应答数据包对应的数据包标识符与所述任务标识符相同，则对所述应答数据包进行反序列化，得到所述应答数据包对应的待校验识别码；

当所述待校验识别码与所述唯一识别码相同时，获取所述第i个探测任务对应的回调函数；所述回调函数是所述客户端在发送所述探测数据包之前，基于所述任务标识符和所述唯一识别码注册而成的；

在所述回调函数中校验所述应答数据包，得到所述应答数据包对应的校验结果，当所述校验结果指示所述应答数据包校验通过时，根据所述应答数据包确定所述第i个探测任务对应的执行结果；

基于所述执行结果确定所述客户端至所述目标网络地址的链路探测信息，为所述探测任务池进行内存重置。

6.根据权利要求1所述的方法，其特征在于，还包括：

获取所述客户端将所述探测数据包发送至所述目标网络地址时的发送时间戳，根据所述发送时间戳确定所述探测数据包对应的应答时间范围；

若所述客户端在所述应答时间范围内未接收到所述探测数据包对应的应答数据包，则从所述探测任务池中删除所述目标网络地址。

7.根据权利要求4所述的方法，其特征在于，还包括：

当所述客户端的网络连接断开时，保存所述第i个探测任务在所述客户端中的运行信息；

当所述客户端的网络连接重新连接成功时，基于所述运行信息继续在所述客户端中执行所述第i个探测任务。

8.根据权利要求1所述的方法，其特征在于，还包括：

获取所述客户端在所述边缘服务节点中的内存占用；

当所述内存占用超过内存占用阈值时，在所述边缘服务节点中重新启动所述客户端。

9.一种链路探测方法，其特征在于，所述方法由代理端执行，包括：

获取客户端上报的链路探测信息；所述客户端部署于内容分发网络中的边缘服务节点，所述链路探测信息是由探测数据包对应的应答数据包所确定的，所述探测数据包是由所述客户端发送至探测任务池中的探测任务所指示的目标网络地址的，所述探测任务池是由策略端通过心跳端下发至所述客户端的；

根据所述链路探测信息，分析所述客户端至所述目标网络地址的链路网络状态。

10.根据权利要求9所述的方法，其特征在于，所述根据所述链路探测信息，分析所述客户端至所述目标网络地址的链路网络状态，包括：

根据所述链路探测信息，统计所述客户端至所述目标网络地址的第一链路丢包率；

当所述第一链路丢包率大于或等于第一丢包阈值时，确定所述客户端至所述目标网络地址的链路网络状态为故障状态，将所述目标网络地址标记为故障网络地址。

11.根据权利要求10所述的方法，其特征在于，还包括：

获取所述客户端至所述故障网络地址的第二链路丢包率；

当所述第二链路丢包率小于第二丢包阈值时，确定所述客户端至所述故障网络地址的链路网络状态为恢复状态，取消标记所述故障网络地址。

12.一种链路探测装置，其特征在于，所述装置应用于客户端，所述客户端部署于内容分发网络中的边缘服务节点；所述装置包括：

发送模块，用于获取策略端下发的探测任务池，向所述探测任务池中的探测任务所指示的目标网络地址发送探测数据包；

接收模块，用于接收针对所述探测数据包的应答数据包，基于所述应答数据包获取所述客户端至所述目标网络地址的链路探测信息；

上报模块，用于将所述链路探测信息上报至代理端，以使所述代理端基于所述链路探测信息分析链路网络状态。

13.一种链路探测装置，其特征在于，所述装置应用于代理端，包括：

获取模块，用于获取客户端上报的链路探测信息；所述客户端部署于内容分发网络中的边缘服务节点，所述链路探测信息是由探测数据包对应的应答数据包所确定的，所述探测数据包是由所述客户端发送至探测任务池中的探测任务所指示的目标网络地址的，所述探测任务池是由策略端通过心跳端下发至所述客户端的；

链路分析模块，用于根据所述链路探测信息，分析所述客户端至所述目标网络地址的链路网络状态。

14.一种计算机设备，其特征在于，包括存储器和处理器；

所述存储器与所述处理器相连，所述存储器用于存储计算机程序，所述处理器用于调用所述计算机程序，以使得所述计算机设备执行权利要求1至11任一项所述的方法。

15.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机程序，所述计算机程序适于由处理器加载并执行，以使得具有所述处理器的计算机设备执行权利要求1至11任一项所述的方法。

16.一种计算机程序产品，其特征在于，包括计算机程序/指令，所述计算机程序/指令被处理器执行时实现权利要求1至11任一项所述的方法。