CN102624584A - 链路检测方法及装置 - Google Patents

Abstract

本发明公开了一种链路检测方法及装置，其中，该方法包括：本端设备发送链路检测报文给对端设备，其中，该链路检测报文中携带有本端设备的状态；本端设备判断在第一预定时长内是否接收到对端设备发送的链路检测报文的回复报文或者用于指示链路发生故障的报文，其中，回复报文中携带有对端设备的状态；本端设备如果在第一预定时长内未收到回复报文或者收到用于指示链路发生故障的报文，确定本端设备和对端设备之间的链路发生故障。通过本发明，解决了相关技术中CDN系统中的链路检测方法可能会失效的问题，提高了链路检测的可靠性。

Description

链路检测方法及装置

技术领域

本发明涉及通信领域，具体而言，涉及一种链路检测方法及装置。

背景技术

三网融合的总体技术方向发展要求构建合理的体系架构、实现端到端的标准化、提升用户体验、结合运用新技术等。在三网融合发展趋势的推动下，IP城域网需要具备承载丰富的自营精品业务的能力，如IPTV、虚拟专网、以太网专线等，在为用户提供简单带宽服务基础上还要保证业务的体验感。因此精品业务承载的关键技术要点是网络故障快速恢复、安全、稳定性等。

在该技术背景下，传统的IPTV业务逐渐被新的IPTV相关技术替代，这就是目前比较热门的融合内容分发网络(Content Distributed Network，简称为CDN)技术。融合CDN是当前互联网实现内容传递的主流技术，CDN的核心是将中心的内容和服务推送到网络边缘，使得用户在最近的地方获取服务，这一方面保证了服务质量(Quality of Service，简称为QoS)(缩短了网络距离)和服务可用性(服务能力分布化)，另一方面也缓解了骨干网络带宽的压力。

由于CDN对大规模内容服务，特别是对流媒体服务性能有很明显的提升，近年来，CDN得到迅速的发展。在现网应用中，CDN设备接入IP城域网的边缘节点，通过BN网络实现用户与中心在线内容库实现端到端的互动，并通过CDN设备streamer和存储的功能，实现更高质量的流媒体获取体验。图1是根据相关技术中的CDN组网示意图，图中的方框表示CDN，如图1所示，CDN设备作为末端用户的接入侧，与IP城域网的边缘节点路由器(ServiceRouter，简称为SR)(或者宽带接入服务器(Broadband Remote Access Server，简称为BRAS)、switch)相连，通过承载网的核心节点、CN平面，实现用户与集团在线内容库端到端的链接。以IPTV为例，对于用户的流媒体请求，简单来说，流程如下：

用户通过人机交互界面(User Interface，简称为UI)，也就是主菜单对某个流媒体内容进行请求，家庭的IPTV终端机顶盒(Set-Top Box，简称为STB)采集到相关信息后将请求报文上送，请求报文到达CDN设备后，CDN进行判断，如果本端的内容库有相关内容，就直接下发，如果没有相关部分内容则继续上送请求。当请求到达调度中心后查找相应的内容所在库位，并将该内容服务器地址返回给请求STB，请求STB再发起媒体请求服务，最后由内容服务器端将内容下发。

由于CDN设备接入的用户规模巨大，CDN设备与SR设备之间通常用一条或者几条吉比特以太网(Gigabit Ethernet，简称为GE)链路连接。CDN设备上通过一定的策略配置，当通过CDN设备向上请求的用户报文超过GE链路的带宽时，会被其他GE链路承担，以保证用户请求报文上送的质量。

在整个请求上送和内容下发过程中，需要经过不同链路间的报文传递，鉴于网络对用户体验的要求，各链路的传递需要有良好的链路连接检测和故障恢复能力。

目前，对于CDN设备接入SR侧的链路连接检测，常采用的手段是PING检测。

PING检测功能是利用网际控制消息协议(Internet Control Message Protocol，简称为ICMP)的请求/响应(request/response)报文，检测目的地的可达性。

通常做法是，在CDN设备上通过脚本配置，规律的向SR发送ICMP报文，实现PING检测功能。当正常的收到SR返回的ICMP response报文，则认为链路正常，否则链路失效。但是这样的做法需要被监测目的设备开放了ICMP业务或者说关闭了PING防护功能。因此在CDN设备上直接通过PING检测链路状态的方式在某些情况下会失效：

当SR设备配置了PING防护功能时，CDN侧发送的PING检测ICMP报文request可能就无法得到正常response应答报文，CDN设备便会认为此链路失效。但是又由于目前CDN设备PING检测只是检测并未实现功能模块联动，比如备份链路切换，比如链路带宽、流量控制等，就可能造成用户请求报文丢失、报文拥塞等，影响用户体验质量，也就违背了三网融合要求的构建合理体系架构、提高用户体验的要求。

下面介绍一下PING防护功能，其一般情况下是防止设备遭受PING攻击，而PING攻击其原理是发送者A向接收者B发送一些尺寸超大的ICMP(PING命令使用的是ICMP报文)报文对其进行攻击(对于有些路由器或系统，在接收到一个这样的报文后，由于处理不当，会造成系统崩溃、死机或重启)。

IP报文的最大长度是216-1＝65535个字节，那么去除IP首部的20个字节和ICMP首部的8个字节，实际数据部分长度最大为：65535-20-8＝65507个字节。所谓的尺寸超大的ICMP报文就是指数据部分长度超过65507个字节的ICMP报文。

针对PING攻击(即PING of Death攻击)，网络安全设备仅仅通过超大包过滤方法不能达到很好的防御效果，因为在现网中传输的大部分报文都经过了分片，所以单片报文不会超过65507个字节，只是在接收端完成组合后才会超过65507个字节。所以针对PING of Death攻击，最有效防御方式是禁止ICMP报文通过网络安全设备。

SR设备的PING保护功能可以用2种方式防止PING攻击，一种是对报文的实际长度(项目上送长度-2层头长度)进行判断，如果大于65535则丢弃，如果没有大于65535则通过；一种是限制最大PING实例个数，超过最大实例个数的PING不做处理。

因此当数据通信设备SR(Bras/Switch)开启PING保护功能时，CDN侧的PING检测就会失效，错误的反馈信息可能会导致对大量用户请求报文的不恰当处理，引起丢包、拥塞等，导致IPTV等流媒体相关服务无法正常开展。

针对相关技术中CDN系统中的链路检测方法可能会失效的问题，目前尚未提出有效的解决方案。

发明内容

针对相关技术中CDN系统中的链路检测方法可能会失效的问题，本发明提供了一种链路检测方法及装置，以至少解决上述问题。

根据本发明的一个方面，提供了一种链路检测方法，该方法包括：本端设备发送链路检测报文给对端设备，其中，所述链路检测报文中携带有所述本端设备的状态；所述本端设备判断在第一预定时长内是否接收到所述对端设备发送的所述链路检测报文的回复报文或者用于指示链路发生故障的报文，其中，所述回复报文中携带有所述对端设备的状态；所述本端设备如果在所述第一预定时长内未收到所述回复报文或者收到所述用于指示链路发生故障的报文，确定所述本端设备和所述对端设备之间的链路发生故障。

优选地，所述本端设备发送所述链路检测报文给所述对端设备包括：所述本端设备依次经由一个或多个中间设备将所述链路检测报文发送给所述对端设备，其中，所述链路检测报文中携带TTL字段，其中，所述TTL字段用于指示所述本端设备到所述对端设备经由的跳数，所述中间设备在接收到所述链路检测报文之后将所述TTL字段中的值减1或者加1并向下一个设备发送所述链路检测报文；所述本端设备收到用于指示所述链路发生故障的报文确定所述本端设备和所述对端设备之间的链路发生故障之前，还包括；所述中间设备在发送所述链路检测报文之后，在第二预定时长未收到所述回复报文或所述下一个设备对所述链路检测报文的响应报文，向所述本端设备发送所述用于指示所述链路发生故障的报文，其中，所述用于指示所述链路发生故障的报文中携带有所述TTL字段。

优选地，在所述本端设备收到所述用于指示所述链路发生故障的报文之后，还包括：所述本端设备根据所述TTL字段确定所述链路上发生故障的位置并通知上层。

优选地，所述方法还包括：如果所述本端设备在所述第一预定时长内收到所述回复报文，并且，所述回复报文中的所述对端设备的状态指示可以与所述本端设备建立会话，所述本端设备发送用于确认会话建立的链路检测报文。

优选地，在所述本端设备和所述对端设备之间的会话建立之后，所述方法还包括：所述本端设备和所述对端设备中的一方向另一方发送回音报文，其中，所述回音报文是不需要接收方进行处理而直接向该报文的发送方返回的报文；所述一方在最小回音间隔内未收到所述另一方返回的所述回音报文，则确定所述链路发生故障。

优选地，所述链路检测报文中携带有所述最小回音间隔。

优选地，所述链路检测报文中还携带有建立所述链路所需要的资源，所述方法还包括：所述本端设备在第一预定时长接收到所述回复报文；所述本端设备判断所述回复报文中是否携带有所述对端设备无法提供所述资源的指示，在判断结果为是的情况下，所述本端设备确定所述链路故障。

优选地，所述本端设备为CDN设备、所述对端设备为SR设备；或者，所述对端设备为CDN设备、所述本端设备为SR设备；或者，所述本端设备为CDN设备、所述对端设备为CDN设备。

根据本发明的另一方面，提供了一种链路检测装置，位于本端设备中，该装置包括：第一发送模块，用于发送链路检测报文给对端设备，其中，所述链路检测报文中携带有所述本端设备的状态；判断模块，用于判断在第一预定时长内是否接收到所述对端设备发送的所述链路检测报文的回复报文或者用于指示链路发生故障的报文，其中，所述回复报文中携带有所述对端设备的状态；确定模块，用于所述判断模块在所述第一预定时长内未收到所述回复报文或者收到所述用于指示链路发生故障的报文时，确定所述本端设备和所述对端设备之间的链路发生故障。

优选地，所述第一发送模块还用于依次经由一个或多个中间设备将所述链路检测报文发送给所述对端设备，其中，所述链路检测报文中携带TTL字段，其中，所述TTL字段用于指示所述本端设备到所述对端设备经由的跳数，所述中间设备在接收到所述链路检测报文之后将所述TTL字段中的值减1或者加1并向下一个设备发送所述链路检测报文；所述装置还包括：接收模块，用于接收来自所述中间设备的所述用于指示所述链路发生故障的报文，其中，所述用于指示所述链路发生故障的报文中携带有所述TTL字段，所述用于指示所述链路发生故障的报文是在所述中间设备发送所述链路检测报文之后，在第二预定时长未收到所述回复报文或所述下一个设备对所述链路检测报文的响应报文的情况下向所述本端设备发送的。

优选地，所述装置还包括：通知模块，用于将所述确定模块根据所述TTL字段确定的所述链路上发生故障的位置通知上层。

优选地，所述装置还包括：第二发送模块，用于在所述第一预定时长内收到所述回复报文，并且，所述回复报文中的所述对端设备的状态指示可以与所述本端设备建立会话的情况下，发送用于确认会话建立的链路检测报文。

优选地，所述装置还包括：第三发送模块，用于向对端发送回音报文，其中，所述回音报文是不需要接收方进行处理而直接向该报文的发送方返回的报文；所述确定模块还用于在最小回音间隔内未收到所述另一方返回的所述回音报文，则确定所述链路发生故障。

优选地，在所述链路检测报文中还携带有建立所述链路所需要的资源的情况下，所述判断模块还用于判断在第一预定时长内接收到的所述回复报文中是否携带有所述对端设备无法提供所述资源的指示；所述确定模块还用于在所述判断模块的判断结果为是的情况下，确定所述链路发生故障。

通过本发明，采用本端设备将携带本端设备状态的链路检测报文发送给对端设备，判断在第一预定时长内是否接收到该对端设备回复的携带对端设备状态的回复报文或者收到用于指示链路发生故障的报文，并根据判断结果确定待测链路是否发生故障，通过在第一预定时长内接收对端设备发来的回复报文或者用于指示链路发生故障的报文的方式检测链路是否发生故障，并通过将本端设备的状态发送给对端设备、本端设备获取对端设备状态的方式，解决了相关技术中CDN系统中的链路检测方法可能会失效的问题，提高了链路检测的可靠性。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据相关技术中的CDN组网示意图；

图2是根据本发明实施例的链路检测方法的流程图；

图3是根据本发明实施例的链路检测装置的结构框图；

图4是根据本发明优选实施例的链路检测装置的结构框图；

图5是根据本发明优选实施例的链路检测会话的状态机示意图；

图6是根据本发明优选实施例的应用A方法进行检测的架构示意图。

具体实施方式

下文中将参考附图并结合实施例来详细说明本发明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

考虑到相关技术中CDN系统中的链路检测方法可能会失效的问题，本实施例提供了一种链路检测方法，图2是根据本发明实施例的链路检测方法的流程图，如图2所示，该方法包括如下步骤：

步骤S202，本端设备发送链路检测报文给对端设备，其中，该链路检测报文中携带有本端设备的状态；

步骤S204，本端设备判断在第一预定时长内是否接收到对端设备发送的链路检测报文的回复报文或者用于指示链路发生故障的报文，其中，回复报文中携带有对端设备的状态；

步骤S206，本端设备如果在第一预定时长内未收到回复报文或者收到用于指示链路发生故障的报文，确定本端设备和对端设备之间的链路发生故障。

本实施例通过上述步骤，采用本端设备将携带本端设备状态的链路检测报文发送给对端设备，判断在第一预定时长内是否接收到该对端设备回复的携带对端设备状态的回复报文或者收到用于指示链路发生故障的报文，并根据判断结果确定待测链路是否发生故障，通过在第一预定时长内接收对端设备发来的回复报文或者用于指示链路发生故障的报文的方式检测链路是否发生故障，并通过将本端设备的状态发送给对端设备、本端设备获取对端设备状态的方式，解决了相关技术中CDN系统中的链路检测方法可能会失效的问题，提高了链路检测的可靠性。

在一个优选实施例中，本端设备和对端设备之间的链路上可以没有其他设备，也可以包括一个或多个中间设备。在本端设备和对端设备之间的链路中存在一个或多个中间设备时，中间设备对链路检测报文和回复报文进行透传，这样对于本端设备和对端设备而言，中间设备是不存在的。在另一个优选的实施例中，中间设备可以在接收到链路检测报文时对该报文进行处理，例如，当本端设备和对端设备之间存在一个或多个中间设备时，本端设备依次经由一个或多个中间设备将链路检测报文发送给对端设备，该链路检测报文中可以携带TTL字段，该TTL字段用于指示本端设备到对端设备经由的跳数。在这种情况下，中间设备在接收到链路检测报文之后，可以将TTL字段中的值进行有规律的改变，例如可以将TTL字段的值减1或者加1并向下一个设备发送链路检测报文。在这种情况下，当该中间设备在发送上述链路检测报文之后的第二预定时长内未收到回复报文或下一个设备对该链路检测报文的响应报文时，该中间设备可以向本端设备发送用于指示链路发生故障的报文，并在该报文中携带上述的TTL字段。

例如，该链路中包括四个网元：网元1、网元2、网元3、网元4，这四个网元顺序相链接，如果网元1是本端CDN设备，网元4是对端CDN设备，是可以形成链路检测的。并且，由于在开始的建链阶段可以得知该链路所包括的网元数量，因此当出现链路出现问题时，可以根据报文中映射的TTL字段判断出在第几跳出现问题，并反馈给网管告警，以便快速定位。

当本端设备收到上述用于指示链路发生故障的报文之后，本端设备可以根据其携带的TTL字段确定链路上发生故障的位置并通知上层。例如，上述的四个网元中网元1为本端设备、网元4为对端设备，网元2和3为中间设备，当网元2接收到来自本端设备(即网元1)的链路检测报文后，将其中的TTL字段的值修改为1，并向网元3发送该链路检测报文，以此类推。当网元2在上述第二预定时长后没有收到网元3发来的该链路检测报文对应的响应报文，则网元2可以向本端设备(即网元1)发送用于指示链路发生故障的报文，并在该报文中携带上述值为1的TTL字段。本端设备(即网元1)在第一预定时长内接收到网元2发来的指示链路发生故障的报文后，可以通过该报文中携带的TTL字段得到发生故障的链路位置应该是网元2和网元3之间的链路。

如果本端设备收到回复报文，并且，回复报文中的对端设备的状态指示可以与本端设备建立会话，本端设备发送用于确认会话建立的链路检测报文。

此外，考虑到检测到的链路故障如果无法与上层功能模块实现联动，就无法快速实现链路切换或者上送用户请求报文的带宽控制，因此作为一种优选实施方式，在本端设备确定链路发生故障的链路位置后，还可以通过本端设备中确定链路发生故障的层通知上层链路或者上层模块该链路发生故障的位置，例如，可以将链路故障的位置信息通知给业务层模块，以便业务层模块及时进行流量控制或使用备份链路进行会话等处理。

在一个优选实施例中，本端的CDN设备使用上述链路检测方法检测到链路发生故障并通知给上层模块后，上层模块能够得知由于该链路发生故障，使得该CDN设备(也称为CDN节点)的当前服务带宽已经达不到预定的节点服务能力，因此上层模块可以根据链路故障的位置对该CDN节点的服务能力进行相应调整，使得该CDN节点当前服务带宽与节点服务能力取得平衡，这样就可以防止出现带宽与服务能力不匹配的情况，进而极大避免了由于带宽与服务能力不匹配导致大量的用户请求被丢包的情况。

例如，某CDN节点有两条服务链路，对外的服务能力有20G，而其中一条链路出现问题，导致该节点带宽变成只有10G，如果上层模块不能及时得知此情况，就会依然按照20G的服务能力向该CDN节点发送用户请求，这就会导致大量丢包的出现。而此时通过上述方式检测到链路有问题并通知给上层模块，上层模块就可以及时降低该节点的服务能力，例如，可以使该节点不再接收用户服务请求，并将用户服务请求调度到其他CDN节点；或者也可以将该节点的服务能力调整为10G。

在本端设备和对端设备之间的会话建立之后，本端设备依然可以通过发送链路检测报文，并根据是否在第一预定时长内接收到对端设备的回复报文或者用于指示链路发生故障的报文来确定链路是否发生故障，优选地，也可以是本端设备和对端设备中的一方向另一方发送回音报文，其中，回音报文是不需要接收方进行处理而直接向该报文的发送方返回的报文；一方在最小回音间隔内未收到另一方返回的回音报文，则确定链路发生故障。通过这种方式，由于回音报文可以专用于检测链路是否发生故障，因此其报文长度可以非常小，大大节省了系统资源，并且由于回音报文可以不需要对端设备进行处理而是直接转发回来，检测速度快，灵敏性强。而当通过回音报文检测出链路发生故障时，则可以再通过上述的链路检测报文来检测链路发生故障的具体位置，并上报给上层模块，以便上层模块及时进行流量控制或使用备份链路进行会话等处理。

其中，上述的最小回音间隔可以是固定设置的，作为一种优选实施方式，最小回音间隔也可以携带在本端设备发送给对端设备的链路检测报文中通知对端设备。

在另一个优选实施例中，链路检测报文中还可以携带有建立链路所需要的资源，例如，该链路预定的服务带宽为10G，在这种情况下，当本端设备在第一预定时长内接收到对端设备发来的回复报文后，可以判断该回复报文中是否携带有对端设备无法提供上述建立链路所需要的资源(10G)的指示，如果判断结果为是，则可以得知对端设备无法提供10G的带宽资源，也就是该链路即使建立，其所能够达到的服务带宽也不足10G，则本端设备可以确定链路发生故障。

上述链路检测方法可以应用于任何CDN系统中链路的检测，优选地，上述本端设备可以为内容分发网络(CDN)设备、而对端设备可以为边缘节点路由器(SR)设备；或者，对端设备也可以为CDN设备、而本端设备则可以为SR设备；当然，本端设备和对端设备也可以都为CDN设备。

对应于上述方法，本实施例还提供了一种链路检测装置，该装置可以位于本端设备中，用于实现上述实施例及优选实施方式，已经进行过说明的不再赘述。如以下所使用的，术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

图3是根据本发明实施例的链路检测装置的结构框图，如图3所示，该装置包括：第一发送模块32、判断模块34、确定模块36，下面对上述模块进行详细说明。

第一发送模块32，用于发送链路检测报文给对端设备，其中，该链路检测报文中携带有本端设备的状态；判断模块34，与第一发送模块32相连，用于判断在第一预定时长内是否接收到对端设备发送的上述链路检测报文的回复报文或者用于指示链路发生故障的报文，其中，该回复报文中携带有对端设备的状态；确定模块36，与判断模块34相连，用于判断模块34在第一预定时长内未收到回复报文或者收到所述用于指示链路发生故障的报文时，确定本端设备和对端设备之间的链路发生故障。

本实施例通过上述装置，采用本端设备将携带本端设备状态的链路检测报文发送给对端设备，判断在第一预定时长内是否接收到该对端设备回复的携带对端设备状态的回复报文或者收到用于指示链路发生故障的报文，并根据判断结果确定待测链路是否发生故障，通过在第一预定时长内接收对端设备发来的回复报文或者用于指示链路发生故障的报文的方式检测链路是否发生故障，并通过将本端设备的状态发送给对端设备、本端设备获取对端设备状态的方式，解决了相关技术中CDN系统中的链路检测方法可能会失效的问题，提高了链路检测的可靠性。

图4是根据本发明优选实施例的链路检测装置的结构框图，如图4所示，第一发送模块32还可以用于依次经由一个或多个中间设备将链路检测报文发送给对端设备，其中，该链路检测报文中携带TTL字段，该TTL字段用于指示本端设备到对端设备经由的跳数，中间设备在接收到链路检测报文之后将TTL字段中的值减1或者加1并向下一个设备发送该链路检测报文；此时，上述装置还可以包括：接收模块42，与判断模块34和确定模块36相连，用于接收来自中间设备的用于指示链路发生故障的报文，其中，用于指示链路发生故障的报文中携带有TTL字段，该用于指示链路发生故障的报文是在中间设备发送链路检测报文之后，在第二预定时长未收到回复报文或下一个设备对该链路检测报文的响应报文的情况下，向本端设备发送的。

参考图4，上述装置还可以包括：通知模块44，与确定模块36相连，用于将根据上述TTL字段确定的链路上发生故障的位置通知上层。

参考图4，上述装置还可以包括：第二发送模块46，与判断模块34相连，用于在第一预定时长内收到回复报文，且该回复报文中的对端设备的状态指示可以与本端设备建立会话的情况下，发送用于确认会话建立的链路检测报文。

参考图4，上述装置还可以包括：第三发送模块48，与第二发送模块46相连，用于向对端发送回音报文，其中，该回音报文是不需要接收方进行处理而直接向该报文的发送方返回的报文；则此时，确定模块36还可以用于在最小回音间隔内未收到另一方返回的回音报文，则确定链路发生故障。

优选地，第一发送模块32发送的链路检测报文中可以携带最小回音间隔。

优选地，在上述链路检测报文中还携带有建立链路所需要的资源的情况下，判断模块34还可以用于判断在第一预定时长内接收到的回复报文中是否携带有对端设备无法提供上述资源的指示；在这种情况下，确定模块36还可以用于在判断模块34的判断结果为是的情况下，确定该链路发生故障。

下面结合优选实施例进行说明，该优选实施例结合了上述实施例及其优选实施方式。

在本优选实施例中以CDN设备为本端设备、SR设备为对端设备为例进行说明，针对之前CDN通过PING检测来判断链路连接状态方法的弊端，本优选实施例提供了一种为CDN设备实现链路检测联动的方法。(下面统一将此新的链路检测方法称为A方法)

A方法对链路故障检测具有单一性，专注于转发故障的快速检测，报文内容少、负荷轻、检测时间短(能达到秒(s)级以下)。对某些应用(数据速率到吉比特)来说，故障感应时间短代表着降低数据丢包数量，实现秒以下的间歇性故障修复功能。

该链路检测方法通过内部接口还可为上层应用模块(如：静态路由模块、上层控制协议)实现联动，从而提供一种通用的低开销快速故障检测服务，联动模块可以利用A检测提供的服务来决定自己采取相应操作，比如链路切换、带宽重分配等。此链路检测方法故障检测时间短，因此在故障检测时间段就不会出现大量数据丢失的情况，可以为客户提供所需的高可靠性、高适用性语音、视频及其他点播业务、实时业务等。

下面重点介绍该链路检测A方法：可以将A方法看成是一个简单的Hello协议，和我们熟悉的数据通信路由协议的Hello机制类似，只不过更简洁更通用。建立链接会话的两个系统之间周期性的互发报文，如果在一个商定的时间段内没有收到对端报文，就认为和对端的通信通道出现故障，链路检测会话Down，并通知上层协议重新选路或者联动模块做其他的操作。为了减少设备负荷，还可以通过一些特殊的应用方式，在这些方式下，可以减少检测报文发送，或者不必周期性的发送检测报文，只在需要的时候才发送。

A方法进行链路检测的简单步骤概述如下：建立了检测会话的两个系统之间周期性的互发检测报文，如果某个系统在商定的时间段内一直没有收到对端发来的报文，则认为对端Down。如果系统报文处理负担比较重，为了减少检测报文的周期性发送接收，减少系统的CPU负荷，可以在报文周期会话功能基础上增加报文回音功能。某个系统的回音功能一旦激活，则发送端可以发送回音报文，对端把回音报文沿转发路径环回(loop back)回来，如果发送端在一段时间内没有收到回音报文，则认为对端Down。因为回音报文事实上可起到检测连通性的作用，所以一定程度上可以减少链路检测控制报文的发送。回音报文可以减少报文往返的延迟，能提供更短的故障检测时间，这是因为其只检测连通性，因而报文可以比普通的链路检测控制报文更简单，处理开销更小。回音功能可以只在一个方向上激活，称某个系统的回音功能是激活的是指：本端能发送回音报文，且对端能环回回音报文。要注意的是，回音功能的开启需要建立在链路检测报文握手成功之后，通过回音功能减少后期检测链路连通性报文往返的开销。

其中，上述链路检测报文的详细封装格式可以和具体的应用相关，例如，在IPV4环境下的应用，就可以使用用户数据报协议(User Datagram Protocol，简称为UDP)封装链路检测报文。不管在什么应用环境下，使用何种具体封装，检测报文需要含有强制部分字段。例如，强制部分的格式需要可以包括：实例号、链路状态标记、报文长度、会话本地描述、会话远端描述、最小发送间隔、最大接收间隔、最小回音接收间隔、是否开启回音功能的标志位等。后续可以根据实际应用需要加入认证等可选功能部分字段。此处，会话本地描述和远端描述采用本地IP地址和目的地IP地址描述。

实例号：session号用来表示本会话。

链路状态标记：status用来表示链路状态，分别为如下几个值：0-AdminDown，管理员强制Down；1-Down，故障导致Down；2-Init，初始化状态；3-Up，连通性建立up状态。

报文长度：以字节计数的报文长度。

会话本地描述：本端区分符，作为本地的唯一标识。

源地址：需配置为本地IP地址。

会话远端描述：目的端区分符，存放远端的描述。

目的地址：需配置为目的端IP地址。

最小发送间隔：本端发送检测报文的最小时间间隔，单位为微秒(百分之一秒)。

最大接收间隔：本端允许收到对端回复的检测报文最长时间，超过该时间，置检测状态为Down。位为微秒(百分之一秒)。

最小回音间隔：本端希望收到对端发送的检测回音报文的最大间隔，超过该时间，置检测状态为Down。如果这个值为0，表示本端去使能回音功能，不能还回对端发过来的回音报文。位为微秒(百分之一秒)。

下面简单介绍A方法进行链路检测的工作原理：A链路检测方法在没有邻居发现功能时，可以由人工配置提供邻居的地址信息(也就是会话远端描述信息)，然后向邻居发送检测报文。

在获取对端系统地址后，如果本地系统是主动(Active)角色，那么主动向对端发送检测控制报文，启动会话建立；如果是被动(Passive)角色，那么在收到对端发来的本会话的检测报文之前，不发送检测报文。在IPV4和IPV6应用环境下，一般要求两端系统都必须是Active角色，即主动发起会话连接。

图5是根据本发明优选实施例的链路检测会话的状态机示意图，图5中的三个方框分别代表Up、Init和Down状态(即Up state、Init state和Dowm state)，图5中的up、int和down分别代表携带Up状态的报文(Up state in packet)、携带Init状态的报文(Init state in packet)和携带Down状态的报文(Down state in packet)，如图5所示，该链路检测方法具体的状态机切换方式如下：

主动方首先发送报文，携带好本端的描述、源地址、目的地址信息，并将被动方的描述设置为0(因为此时会话未建立不知道对方描述)，status为“Down”；

被动方在收到主动方的报文后，发现报文目的地址是自己，将对方描述写入自己报文，并携带自己的描述，回复报文给主动方，Status为“Init”；

启动会话的系统收到回应报文后，发现自己的描述已经在其中的“远端描述”中，知道双向通信已经完成，会话可以UP，发送的报文中会话Status为“UP”，“远端描述”字段拷贝刚收到的报文的“本地描述”，此时状态一端up一端init；

对端收到后，也确认双向通信完成，会话状态设为“Up”。两端状态都UP。

于是，三次握手过程完成，会话建立成功。

会话启动时和会话建立过程中，会话报文发送间隔可以稍长，例如，1秒1次。会话建立后的链路状态检测报文按照配置的最小发送间隔发送报文，保持状态。

会话建立成功后，如果本端能支持回音报文的发送，对端支持回音报文的环回，那么本端系统可以启用回音功能。启用回音功能后，回音报文可用来检测连通性，如果在商定的时间内没有收到环回回来的回音报文，则可以认为对端故障，会话状态置为Down。因为回音报文有检测连通性的作用，回音报文的发送可以控制在比较高的速率，而链路检测报文的发送可以控制在比较低的速率，例如1秒1个。

在会话建立过程中，如果在最大接收间隔设定的时间内没有收到回应报文，则可以认为对端故障，会话Down，即可以将Status字段设为Down。

如果会话Down，则可以停止发送回音报文，并将检测控制报文的发送速率降到启动会话建立时的低速率，重新进行会话握手判断。如果两个系统之间存在多个检测会话，可以在同一个会话实例配置相同的Session标志，则通过检测Session进行比较，就能够知道该实例应当归入哪个检测会话。

图6是根据本发明优选实施例的应用A方法进行检测的架构示意图，如图6所示，应用见A检测方法的具体流程描述如下：

CDN1与SR1之间的链路为主链路，如果接入用户较多，会存在多条链路相连(如链路1和链路2)，当用户请求超过一条链路带宽时，链路2分担用户报文，进行上送。CDN1与SR2的链路为备份链路。此时，可能出现故障的几种情况及A检测方法的应用如下：

情况一：如果链路1出现故障，故障并不会被检测并及时通知到业务层进行流量控制，用户请求上送报文带宽重分配，而是都会从链路2上送，这样必然导致拥塞和丢包；同理链路2故障。传统的CDN设备PING包检测的方式，能检测到链路故障，但是没法实现功能模块联动通知业务层进行流量控制。如果此时CDN1\SR1都配置了A链路检测，正常链路时检测会话保持，一旦链路出现故障，会话Down，链路检测通过与业务层的接口，通知业务层进行流量控制，并且这个检测时间是毫秒级，因此造成的用户报文丢失大大降低。

情况二：如果链路都正常，但是SR1开启了PING保护功能，对PING检测的ICMP报文过滤，这样传统的CDN侧采取的PING检测就会产生误报警。而配置A链路检测方法就不会受SR侧配置PING保护功能的影响。

情况三：如果节点SR1出现故障，故障也不会被及时检测并通知到业务成进行链路切换，启用备份链路(CDN1与SR2的链路)，当通过传统的PING检测方法发现SR故障链路失效，再从业务层切换到备份链路时，用户请求报文已出现大量丢包。而配置A链路检测方法，当无法收到SR1的检测报文时，会话Down，并通过相应的接口通知业务层切换下一跳为SR2的备份链路。故障恢复能够达到毫秒级，从而大大降低用户报文的丢失。

从以上的描述中，可以看出，本发明实现了如下技术效果：采用本端设备将携带本端设备状态的链路检测报文发送给对端设备，判断在第一预定时长内是否接收到该对端设备回复的携带对端设备状态的回复报文或者收到用于指示链路发生故障的报文，并根据判断结果确定待测链路是否发生故障，通过在第一预定时长内接收对端设备发来的回复报文或者用于指示链路发生故障的报文的方式检测链路是否发生故障，并通过将本端设备的状态发送给对端设备、本端设备获取对端设备状态的方式，解决了相关技术中CDN系统中的链路检测方法可能会失效的问题，提高了链路检测的可靠性。

在另外一个实施例中，还提供了一种软件，该软件用于执行上述实施例及优选实施例中描述的技术方案。

在另外一个实施例中，还提供了一种存储介质，该存储介质中存储有上述软件，该存储介质包括但不限于光盘、软盘、硬盘、可擦写存储器等。

显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (14)

1.一种链路检测方法，其特征在于，包括：

本端设备发送链路检测报文给对端设备，其中，所述链路检测报文中携带有所述本端设备的状态；

所述本端设备判断在第一预定时长内是否接收到所述对端设备发送的所述链路检测报文的回复报文或者用于指示链路发生故障的报文，其中，所述回复报文中携带有所述对端设备的状态；

所述本端设备如果在所述第一预定时长内未收到所述回复报文或者收到所述用于指示链路发生故障的报文，确定所述本端设备和所述对端设备之间的链路发生故障。

2.根据权利要求1所述的方法，其特征在于，

所述本端设备发送所述链路检测报文给所述对端设备包括：所述本端设备依次经由一个或多个中间设备将所述链路检测报文发送给所述对端设备，其中，所述链路检测报文中携带TTL字段，其中，所述TTL字段用于指示所述本端设备到所述对端设备经由的跳数，所述中间设备在接收到所述链路检测报文之后将所述TTL字段中的值减1或者加1并向下一个设备发送所述链路检测报文；

所述本端设备收到用于指示所述链路发生故障的报文确定所述本端设备和所述对端设备之间的链路发生故障之前，还包括；所述中间设备在发送所述链路检测报文之后，在第二预定时长未收到所述回复报文或所述下一个设备对所述链路检测报文的响应报文，向所述本端设备发送所述用于指示所述链路发生故障的报文，其中，所述用于指示所述链路发生故障的报文中携带有所述TTL字段。

3.根据权利要求2所述的方法，其特征在于，在所述本端设备收到所述用于指示所述链路发生故障的报文之后，还包括：

所述本端设备根据所述TTL字段确定所述链路上发生故障的位置并通知上层。

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

如果所述本端设备在所述第一预定时长内收到所述回复报文，并且，所述回复报文中的所述对端设备的状态指示可以与所述本端设备建立会话，所述本端设备发送用于确认会话建立的链路检测报文。

5.根据权利要求4所述的方法，其特征在于，在所述本端设备和所述对端设备之间的会话建立之后，所述方法还包括：

所述本端设备和所述对端设备中的一方向另一方发送回音报文，其中，所述回音报文是不需要接收方进行处理而直接向该报文的发送方返回的报文；

所述一方在最小回音间隔内未收到所述另一方返回的所述回音报文，则确定所述链路发生故障。

6.根据权利要求5所述的方法，其特征在于，所述链路检测报文中携带有所述最小回音间隔。

7.根据权利要求1所述的方法，其特征在于，所述链路检测报文中还携带有建立所述链路所需要的资源，所述方法还包括：

所述本端设备在第一预定时长接收到所述回复报文；

所述本端设备判断所述回复报文中是否携带有所述对端设备无法提供所述资源的指示，在判断结果为是的情况下，所述本端设备确定所述链路故障。

8.根据权利要求1至7中任一项所述的方法，其特征在于，

所述本端设备为内容分发网络CDN设备、所述对端设备为边缘节点路由器SR设备；或者，

所述对端设备为CDN设备、所述本端设备为SR设备；或者，

所述本端设备为CDN设备、所述对端设备为CDN设备。

9.一种链路检测装置，位于本端设备中，其特征在于，包括：

第一发送模块，用于发送链路检测报文给对端设备，其中，所述链路检测报文中携带有所述本端设备的状态；

判断模块，用于判断在第一预定时长内是否接收到所述对端设备发送的所述链路检测报文的回复报文或者用于指示链路发生故障的报文，其中，所述回复报文中携带有所述对端设备的状态；

确定模块，用于所述判断模块在所述第一预定时长内未收到所述回复报文或者收到所述用于指示链路发生故障的报文时，确定所述本端设备和所述对端设备之间的链路发生故障。

10.根据权利要求9所述的装置，其特征在于，

所述第一发送模块还用于依次经由一个或多个中间设备将所述链路检测报文发送给所述对端设备，其中，所述链路检测报文中携带TTL字段，其中，所述TTL字段用于指示所述本端设备到所述对端设备经由的跳数，所述中间设备在接收到所述链路检测报文之后将所述TTL字段中的值减1或者加1并向下一个设备发送所述链路检测报文；

所述装置还包括：接收模块，用于接收来自所述中间设备的所述用于指示所述链路发生故障的报文，其中，所述用于指示所述链路发生故障的报文中携带有所述TTL字段，所述用于指示所述链路发生故障的报文是在所述中间设备发送所述链路检测报文之后，在第二预定时长未收到所述回复报文或所述下一个设备对所述链路检测报文的响应报文的情况下向所述本端设备发送的。

11.根据权利要求10所述的装置，其特征在于，所述装置还包括：通知模块，用于将所述确定模块根据所述TTL字段确定的所述链路上发生故障的位置通知上层。

12.根据权利要求9所述的装置，其特征在于，所述装置还包括：

第二发送模块，用于在所述第一预定时长内收到所述回复报文，并且，所述回复报文中的所述对端设备的状态指示可以与所述本端设备建立会话的情况下，发送用于确认会话建立的链路检测报文。

13.根据权利要求12所述的装置，其特征在于，所述装置还包括：

第三发送模块，用于向对端发送回音报文，其中，所述回音报文是不需要接收方进行处理而直接向该报文的发送方返回的报文；

所述确定模块还用于在最小回音间隔内未收到所述另一方返回的所述回音报文，则确定所述链路发生故障。

14.根据权利要求9所述的装置，其特征在于，

在所述链路检测报文中还携带有建立所述链路所需要的资源的情况下，所述判断模块还用于判断在第一预定时长内接收到的所述回复报文中是否携带有所述对端设备无法提供所述资源的指示；

所述确定模块还用于在所述判断模块的判断结果为是的情况下，确定所述链路发生故障。

Images