CN107819648B

CN107819648B - 网络配置netconf连接检测方法和装置

Info

Publication number: CN107819648B
Application number: CN201711121926.6A
Authority: CN
Inventors: 王汉
Original assignee: Hangzhou H3C Technologies Co Ltd
Current assignee: Hangzhou H3C Technologies Co Ltd
Priority date: 2017-11-14
Filing date: 2017-11-14
Publication date: 2020-08-04
Anticipated expiration: 2037-11-14
Also published as: CN107819648A

Abstract

网络配置NETCONF连接检测方法和装置。本申请提供了NETCONF连接检测方法和装置。本申请中，通过NETCONF客户端检测出本客户端在指定时间内未通过NETCONF连接收到来自服务端发送的任何一个消息来触发检测本客户端与服务端之间已建立的NETCONF连接，实现了NETCONF连接的检测。

Description

网络配置NETCONF连接检测方法和装置

技术领域

本申请涉及网络通信技术，特别涉及网络配置(NETCONF)连接检测方法和装置。

背景技术

NETCONF是一种基于可扩展标记语言(XML)的配置协议。在NETCONF客户端和服务端之间建立NETCONF连接后，NETCONF客户端通过NETCONF连接向服务端下发网络配置，这实现了更为灵活和方便的网络配置。在应用中，NETCONF客户端可为控制器，服务端为交换设备。

但是，因为链路故障、服务端的网络配置错误等原因，NETCONF客户端和服务端之间的NETCONF连接并不总是正常(可用)的，为方便NETCONF客户端及时感知其与服务端之间的NETCONF连接异常(不可用)，亟待需要一种可靠的检测方式来检测NETCONF客户端与服务端之间的NETCONF连接。

发明内容

本申请提供了网络配置NETCONF连接检测方法和装置，以检测NETCONF客户端与服务端之间NETCONF连接。

本申请提供的技术方案包括：

在第一方面，本申请提供了一种NETCONF连接检测方法，该方法应用于NETCONF客户端，包括：

在本客户端与服务端协商建立NETCONF连接后，若检测出本客户端在指定时间内未收到来自所述服务端发送的任何一个消息，则，

通过所述NETCONF连接向所述服务端发送用于检测所述NETCONF连接的保活消息；

依据在发出所述保活消息之后的指定时间内是否通过所述NETCONF连接接收到来自所述服务端发送的消息确定所述NETCONF连接是否正常。

结合第一方面，在第一种可能的实现方式中，所述依据在发出保活消息之后的指定时间内是否通过所述NETCONF连接接收到来自所述服务端发送的消息确定所述NETCONF连接是否正常，包括：

若在发出所述保活消息之后的指定时间内通过所述NETCONF连接接收到所述服务端发送的消息，则确定所述NETCONF连接正常；

若在发出所述保活消息之后的指定时间内未通过所述NETCONF连接接收到所述服务端发送的任何一个消息，则确定所述NETCONF连接异常。

结合第一方面的第一种可能的实现方式，在第二种可能的实现方式中，所述确定NETCONF连接正常之后，进一步包括：检查本地预设的连接检测数是否为零，若否，将本地预设的连接检测数置为零；

所述若在发出所述保活消息之后的指定时间内未通过所述NETCONF连接接收到所述服务端发送的任何一个消息，且在确定所述NETCONF连接异常之前，进一步包括：将本地预设的连接检测数增加设定值，检查增加设定值后的所述连接检测数是否不小于预设阈值，如果否，则再次向所述服务端发送用于检测所述NETCONF连接的保活消息；如果是，则将所述连接检测数清零。

结合第一方面的第一种、第二种可能的实现方式，在第三种可能的实现方式中，所述保活消息为非NETCONF消息，在所述NETCONF连接的任一时间发送。

结合第一方面的第三种可能的实现方式，在第四种可能的实现方式中，所述保活消息携带响应回复标识，所述响应回复标识用于指示收到所述保活消息的所述服务端返回所述保活消息的响应消息。

在第二方面，本申请提供了一种NETCONF连接检测装置，该装置应用于NETCONF客户端，包括：

检测单元，用于在本客户端与服务端协商建立NETCONF连接后，检测本客户端在指定时间内是否收到来自所述服务端发送的任何一个消息；

发送单元，用于若所述检测单元检测出本客户端在指定时间内未收到来自所述服务端发送的任何一个消息，则通过所述NETCONF连接向所述服务端发送用于检测所述NETCONF连接的保活消息；

确定单元，用于依据在发出所述保活消息之后的指定时间内是否通过所述NETCONF连接接收到来自所述服务端发送的消息确定所述NETCONF连接是否正常。

结合第二方面的，在第一种可能的实现方式中，所述确定单元依据在发出保活消息之后的所述指定时间内是否通过所述NETCONF连接接收到来自所述服务端发送的消息确定所述NETCONF连接是否正常包括：

结合第二方面的第一种可能的实现方式，在第二种可能的实现方式中，所述装置进一步包括：第一设置单元，用于检查本地预设的连接检测数是否为零，若否，将本地预设的连接检测数置为零；

所述装置进一步包括：第二设置单元，用于将本地预设的连接检测数增加设定值，检查增加了设定值后的所述连接检测数是否不小于预设阈值，如果否，则再次触发所述发送单元向所述服务端发送用于检测所述NETCONF连接的保活消息；如果是，则将所述连接检测数清零。

结合第二方面的第一种、第二种可能的实现方式，在第三种可能的实现方式中，所述保活消息为非NETCONF消息，在所述NETCONF连接的任一时间发送。

结合第二方面的第三种可能的实现方式，在第四种可能的实现方式中，所述保活消息携带响应回复标识，所述响应回复标识用于指示收到所述保活消息的所述服务端返回所述保活消息的响应消息。

由以上技术方案可以看出，在本申请中，NETCONF客户端检测出在指定时间内未通过NETCONF连接收到来自服务端发送的任何一个消息来触发检测本NETCONF客户端与服务端之间已建立的NETCONF连接，实现了NETCONF连接的检测；

进一步地，在本申请中，NETCONF客户端与服务端之间已建立的NETCONF连接的检测并非定期触发，而是基于NETCONF连接上的消息状态(NETCONF客户端在指定时间内未通过NETCONF连接收到来自服务端发送的任何一个消息)触发的，是不会对业务有影响的，原因为：在NETCONF连接上有很多消息比如业务消息时，因为此时NETCONF客户端会不断地通过NETCONF连接收到服务端返回的消息，不会出现诸如“NETCONF客户端在指定时间内没有通过NETCONF连接收到服务端发送的消息”的情况，因此，NETCONF客户端是不会通过NETCONF连接发送保活消息的；而当出现NETCONF客户端在指定时间内没有通过NETCONF连接收到服务端发送的消息时，说明此时NETCONF连接并不繁忙(没有或者有很少的业务消息)，这时NETCONF客户端通过NETCONF连接发送保活消息是不会对业务有什么影响。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。

图1为本申请提供的方法流程图；

图2为本申请实施例提供的步骤102实现流程图；

图3为本申请实施例提供的步骤102另一实现流程图；

图4为本申请提供的Global Request消息结构示意图；

图5为本申请提供的装置结构图；

图6为本申请提供的装置硬件结构图。

具体实施方式

在应用中，NETCONF客户端与服务端之间的NETCONF连接是基于安全外壳(英文：Secure Shell，简称：SSH)协议的NETCONF连接，简称NETCONF over SSH连接。在本申请中，作为一个实施例，NETCONF客户端可为控制器，服务端为交换设备。

为了方便NETCONF客户端及时感知其与服务端之间的NETCONF over SSH连接异常，常用的一种NETCONF连接检测方案具体为：

NETCONF客户端定期通过NETCONF over SSH连接发送任意的一个用于指定作为检测NETCONF over SSH连接的NETCONF消息(简称指定NETCONF消息)来确认是否能和NETCONFover SSH连接对端的服务端正常连通；

当NETCONF客户端在发送指定NETCONF消息之后的设定时长内通过NETCONF overSSH连接接收到服务端返回的回应时，确定NETCONF over SSH连接是正常的。此时，NETCONF客户端可将NETCONF over SSH连接正常的消息通知给上层业务管理设备，以便上层业务管理设备通过NETCONF客户端与服务端之间正常的NETCONF over SSH连接发送NETCONF配置消息给服务端来对服务端进行业务管理。

当NETCONF客户端在发送指定NETCONF消息之后的设定时长内未接收到服务端返回的回应时，则确定NETCONF over SSH连接是异常的。此时，NETCONF客户端可将NETCONFover SSH连接异常的消息通知给上层业务管理设备，并尝试重新与服务端建立NETCONFover SSH连接。

通过上面描述可以看出，NETCONF客户端定期通过NETCONF over SSH连接发送指定NETCONF消息能够检测出NETCONF over SSH连接的异常。

但是，在上面描述的NETCONF over SSH连接检测方案中，NETCONF客户端是定期通过NETCONF over SSH连接发送指定NETCONF消息来检测NETCONF over SSH连接是否异常，其并不关心NETCONF over SSH连接当前的消息状态，即使NETCONF over SSH连接当前有很多业务消息交互，已明确指示NETCONF over SSH连接正常，但是假若NETCONF客户端发现检测NETCONF over SSH连接的时间到达，其也会通过NETCONF over SSH连接发送指定NETCONF消息来检测NETCONF over SSH连接是否异常，这导致一些完全没有必要执行的NETCONF over SSH连接检测，也会导致同一时间内NETCONF over SSH连接上有很多消息(包括业务消息、指定NETCONF消息)发送，有可能延迟业务消息交互。

为了避免上述问题，本申请提供了一种可靠的且依赖于NETCONF over SSH连接本身的消息状态的检测方法，以实现检测NETCONF客户端与服务端之间的NETCONF连接(比如NETCONF over SSH连接)。

参见图1，图1为本申请提供的方法流程图。该流程应用于NETCONF客户端。

如图1所示，该流程可包括以下步骤：

步骤101，NETCONF客户端在与服务端协商建立NETCONF连接后，若检测出本NETCONF客户端在指定时间内未收到来自所述服务端发送的任何一个消息，则向所述服务端发送用于检测所述NETCONF连接的保活消息。

作为一个实施例，在本申请中，NETCONF客户端与服务端协商建立NETCONF连接的方法类似现有NETCONF连接建立方式，这里仅简单做一下描述：NETCONF客户端向服务器端发起建立NETCONF连接(比如上述的NETCONF over SSH连接)的请求，以与服务端协商建立NETCONF连接(比如上述的NETCONF over SSH连接)，具体建立过程此处省略描述。

当NETCONF连接建立成功后，则NETCONF客户端可通知上层业务管理设备，以便上层业务管理设备通过NETCONF客户端与服务端之间的NETCONF连接(比如上述的NETCONFover SSH连接)发送NETCONF配置消息给服务端来对服务端进行业务管理。当NETCONF连接建立失败的情况，不属于本申请涉及的范围，此处不再描述。

当NETCONF客户端与服务端协商建立NETCONF连接后，为便于NETCONF客户端及时感知其与服务端之间的NETCONF连接异常，则本申请中，如步骤101描述的，NETCONF客户端会在检测出本NETCONF客户端在指定时间内未收到来自所述服务端发送的任何一个消息，则向所述服务端发送用于检测所述NETCONF连接的保活消息。以NETCONF连接为NETCONFover SSH连接为例，这里所述的来自所述服务端发送的任何一个消息是指来自所述服务端发送的任一SSH消息。这里的任一SSH消息其可为NETCONF消息，也可为非NETCONF消息。

步骤102，NETCONF客户端依据在发出保活消息之后的指定时间内是否通过所述NETCONF连接收到来自所述服务端发送的消息确定所述NETCONF连接是否正常。

作为一个实施例，这里的指定时间可根据实际情况设置，比如设置为10秒(S)。

作为一个实施例，本步骤102确定NETCONF连接是否正常可包括图2或图3所示的流程。这里暂不赘述。

至此，完成图1所示流程。

通过图1所示流程可以看出，在本申请中，NETCONF客户端检测出在指定时间内未通过NETCONF连接收到来自服务端发送的任何一个消息来触发检测本NETCONF客户端与服务端之间已建立的NETCONF连接，实现了NETCONF连接的检测；

进一步地，在本申请中，NETCONF客户端与服务端之间已建立的NETCONF连接的检测并非定期触发，而是基于NETCONF连接上的消息状态(NETCONF客户端在指定时间内未通过NETCONF连接收到来自服务端发送的任何一个消息)触发的，是不会对业务有影响的，原因为：在NETCONF连接上有很多消息比如业务消息时，因为此时NETCONF客户端会不断地通过NETCONF连接收到服务端返回的消息，不会出现诸如“NETCONF客户端在指定时间内没有通过NETCONF连接收到服务端发送的消息”的情况，因此，NETCONF客户端是不会通过NETCONF连接发送保活消息的；而当出现NETCONF客户端在指定时间内没有通过NETCONF连接收到服务端发送的消息时，说明此时NETCONF连接并不繁忙(没有或者有很少的业务消息)，这时NETCONF客户端通过NETCONF连接发送保活消息是不会对业务有什么影响，不会出现上面描述的定期检测NETCONF over SSH连接所出现的各种问题。

参见图2，图2为本申请提供的步骤102实现流程图。如图2所示，该流程可包括以下步骤：

步骤201，NETCONF客户端在发出所述保活消息之后的指定时间内若通过NETCONF连接接收到服务端发送的消息，则执行步骤202，NETCONF客户端在发出所述保活消息之后的指定时间内若未通过NETCONF连接接收到服务端发送的任何一个消息，则执行步骤203。

步骤202，确定所述NETCONF连接正常。

本步骤202是NETCONF客户端在发出所述保活消息之后的指定时间内通过NETCONF连接接收到服务端发送的任何一个消息的前提下执行的。当NETCONF客户端在发出所述保活消息之后的指定时间内通过NETCONF连接接收到服务端发送的任何一个消息，则意味着此时NETCONF客户端与服务端之间已建立的NETCONF连接是正常(可用)的。以NETCONF连接为NETCONF over SSH连接为例，这里所述的来自所述服务端发送的任何一个消息是指来自所述服务端发送的保活消息的响应信息(属于SSH消息)或者其他任一SSH消息(比如NETCONF消息、非NETCONF消息等)。

步骤203，确定所述NETCONF连接异常。

本步骤203是NETCONF客户端在发出所述保活消息之后的指定时间内未通过NETCONF连接接收到服务端发送的任何一个消息的前提下执行的。当NETCONF客户端在发出所述保活消息之后的指定时间内未通过NETCONF连接接收到服务端发送的任何一个消息，则意味着此时NETCONF客户端与服务端之间已建立的NETCONF连接也意味着是异常(不可用)的。

至此，完成图2所示流程。

通过图2所示流程最终实现了NETCONF连接的检测。

参见图3，图3为本申请提供的步骤102另一实现流程图。如图3所示，该流程可包括以下步骤：

步骤301，NETCONF客户端在发出所述保活消息之后的指定时间内若通过NETCONF连接接收到服务端发送的消息，则执行步骤302，NETCONF客户端在发出所述保活消息之后的指定时间内若未通过NETCONF连接接收到服务端发送的任何一个消息，则执行步骤303。

步骤302，确定NETCONF连接正常，并检查本地预设的连接检测数是否为零，若否，将本地预设的连接检测数置为零。

在本步骤302中，若检查出本地预设的连接检测数为零，则不针对连接检测数执行任何处理，即，维持本地预设的连接检测数为零。

这里，连接检测数其可预先设置在NETCONF客户端本地，具体实现时可为计数器，用于记录连续检测NETCONF连接的次数。在本申请中，之所以在NETCONF客户端本地设置连接检测数，其目的是实现在连接检测数指示的连续检测NETCONF连接的次数不小于预设阈值时才确定NETCONF连接，并非如图2所示流程仅基于一次NETCONF连接检测就可确定NETCONF连接异常，提高NETCONF连接检测的可靠性。

步骤303，将本地预设的连接检测数增加设定值，检查增加了设定值后的所述连接检测数是否大于或等于预设阈值，如果否，则再次向所述服务端发送用于检测所述NETCONF连接的保活消息；如果是，则将本地预设的连接检测数清零，并确定所述NETCONF连接异常。

作为一个实施例，这里的设定值可为1。

在一个例子中，步骤303中的预设阈值可根据NETCONF客户端本身性能和实际需求自定义设置，比如设置为3。

至此，完成图3所示流程的描述。

通过图3所示流程最终实现了NETCONF连接的检测。

进一步地，相比于图2所示流程，图3所示流程在发出所述保活消息之后的指定时间内检查出未通过NETCONF连接接收到服务端发送的任何一个消息时，并不立即确定NETCONF连接异常，而是依赖于本地预设的用于记录连续检测NETCONF连接次数的连接检测数确定NETCONF连接异常，在连接检测数指示的连续检测NETCONF连接的次数不小于预设阈值时确定NETCONF连接，这相比于图2所示的流程，NETCONF连接检测的可靠性高，检测出的NETCONF连接是否正常的结果也更准确。

在本申请中，作为一个实施例，NETCONF客户端向服务端发送的用于检测NETCONF连接的保活消息，是要求服务端回复响应消息的。在一个例子中，NETCONF客户端向服务端发送的用于检测NETCONF连接的保活消息可携带响应回复标识，所述响应回复标识用于指示收到所述保活消息的服务端返回所述保活消息的响应消息。这里的响应消息不限响应消息的内容是成功响应消息(比如SSH-MSG-REQUEST-SUCCESS)还是失败响应消息(比如SSH-MSG-REQUEST-FAILURE)。

在本申请中，保活消息、保活消息的响应消息为非NETCONF消息，不要求在所述NETCONF连接上串行发送，可在任意时间发送。

基于上面对保活消息的描述，则作为一个实施例，本申请中的保活消息可优选为RFC 4254定义的全局请求(Global Request)消息。Global Request消息不为NETCONF消息，不要求在NETCONF连接上串行发送。图4示出了Global Request消息的格式。

作为一个实施例，在本申请中，当保活消息为RFC 4254定义的Global Request消息时，上述的响应回复标识可为Global Request消息新增加的一个字段携带的标识。

作为另一个实施例，在本申请中，当保活消息为RFC 4254定义的Global Request消息时，上述的响应回复标识也可为承载于所述Global Request消息的需要回复(wantreply)字段的一个标识。如图4所示，Global Request消息中有一个want reply字段，当want reply字段为响应回复标识比如True时意味着收到Global Request消息的设备必须回应成功响应消息(比如SSH-MSG-REQUEST-SUCCESS)或者失败响应消息(比如SSH-MSG-REQUEST-FAILURE)。其中，当收到Global Request消息的设备不支持Global Request消息的消息类型时，可直接回应失败响应消息(比如SSH-MSG-REQUEST-FAILURE)。

下面以保活消息为Global Request消息、NETCONF连接为NETCONF over SSH连接为例对本申请提供的方法进行描述：

当NETCONF客户端与服务端协商成功建立NETCONF over SSH连接后，NETCONF客户端会启动对NETCONF over SSH连接的如下检测：

NETCONF客户端在指定时间(比如10s)没有通过NETCONF over SSH连接接收到服务端发来的任何一个消息，则主动通过本NETCONF客户端与服务端之间已建立的NETCONFover SSH连接发送一个Global Request消息，以试探一下本NETCONF客户端与服务端之间已建立的NETCONF over SSH连接是否正常。如上针对Global Request消息的描述，服务端收到Global Request消息后会回应响应消息，但是也有可能出现以下情况：服务端当前比较繁忙正处理业务消息，服务端向NETCONF客户端发送业务消息先于回应响应消息。

但是，不管NETCONF客户端在发送Global Request消息之后的指定时间(比如10s)内是通过本NETCONF客户端与服务端之间已建立的NETCONF over SSH连接收到GlobalRequest消息的响应消息，还是其他SSH消息，只要NETCONF客户端通过本NETCONF客户端与服务端之间已建立的NETCONF over SSH连接收到，则意味着本NETCONF客户端与服务端之间已建立的NETCONF over SSH连接是正常可用的。

反之，NETCONF客户端在发送Global Request消息之后的指定时间(比如10s)内未通过本NETCONF客户端与服务端之间已建立的NETCONF over SSH连接收到任何一个消息，则结合图3所示流程，NETCONF客户端会将本地预设的连接检测数增加1，检查增加了1后的连接检测数是否大于或等于预设阈值，如果否，再次通过本NETCONF客户端与服务端之间已建立的NETCONF over SSH连接发送一个Global Request消息，如果是，则确定NETCONF连接异常。

需要说明的是，在本申请中，一旦NETCONF客户端检测出本NETCONF客户端与服务端之间建立的NETCONF连接比如NETCONF over SSH连接异常，则NETCONF客户端会关闭承载于该异常NETCONF连接的所有会话比如SSH会话，将关闭会话的消息通知上层业务管理设备，并开始尝试重新与服务端协商建立NETCONF连接，当重新建立NETCONF连接后，返回图1所示流程。

以上对本申请提供的实施例进行了描述。

下面对本申请提供的装置进行描述：

参见图5，图5为本申请提供的装置结构图。该装置应用于NETCONF客户端，如图5所示，该装置包括：

检测单元501，用于在本客户端与服务端协商建立NETCONF连接后，检测本客户端在指定时间内是否收到来自所述服务端发送的任何一个消息；

发送单元502，用于若检测单元501检测出本客户端在指定时间内未收到来自所述服务端发送的任何一个消息，则通过所述NETCONF连接向所述服务端发送用于检测所述NETCONF连接的保活消息；

确定单元503，用于依据在发出所述保活消息之后的指定时间内是否通过所述NETCONF连接接收到来自所述服务端发送的消息确定所述NETCONF连接是否正常。

作为一个实施例，所述确定单元503依据在发出保活消息之后的所述指定时间内是否通过所述NETCONF连接收到来自所述服务端发送的消息确定所述NETCONF连接是否正常包括：

作为一个实施例，所述装置进一步包括：

第一设置单元504，用于检查本地预设的连接检测数是否为零，若否，将本地预设的连接检测数置为零；

第二设置单元505，用于将本地预设的连接检测数增加设定值，检查增加了设定值后的所述连接检测数是否不小于预设阈值，如果否，则再次触发发送单元502向所述服务端发送用于检测所述NETCONF连接的保活消息；如果是，则将所述连接检测数清零。

作为一个实施例，所述保活消息为非NETCONF消息，在所述NETCONF连接的任一时间发送。

作为一个实施例，所述保活消息携带响应回复标识，所述响应回复标识用于指示收到所述保活消息的所述服务端返回所述保活消息的响应消息。

至此，完成图5所示装置的描述。

对应地，本申请还提供了图5所示装置的硬件结构图。如图6所示，该硬件结构包括：

可包括处理器601、存储有机器可执行指令的机器可读存储介质602。处理器601与机器可读存储介质602可经由系统总线603通信。并且，通过读取并执行机器可读存储介质602中与NETCONF会话状态检测逻辑对应的机器可执行指令，处理器601可执行上文描述的NETCONF连接检测方法。

本文中提到的机器可读存储介质602可以是任何电子、磁性、光学或其它物理存储装置，可以包含或存储信息，如可执行指令、数据，等等。例如，机器可读存储介质可以是：随机存取存储器(英文：Radom Access Memory，简称：RAM)、易失存储器、非易失性存储器、闪存、存储驱动器(如硬盘驱动器)、固态硬盘、任何类型的存储盘(如光盘、dvd等)，或者类似的存储介质，或者它们的组合。

至此，完成图6所示的硬件结构描述。

在本申请中，还提供了一种包括机器可执行指令的机器可读存储介质，例如图6中的机器可读存储介质602，所述机器可执行指令可由NETCONF连接检测装置中的处理器601执行以实现以上描述的NETCONF连接检测方法。

具体地，通过调用并执行机器可读存储介质中与NETCONF连接检测逻辑对应的机器可执行指令，处理器601可执行以上NETCONF连接检测方法中的操作。

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

Claims

1.一种NETCONF连接检测方法，其特征在于，该方法应用于NETCONF客户端，包括：

2.根据权利要求1所述的方法，其特征在于，所述依据在发出保活消息之后的指定时间内是否通过所述NETCONF连接接收到来自所述服务端发送的消息确定所述NETCONF连接是否正常，包括：

3.根据权利要求2所述的方法，其特征在于，所述确定NETCONF连接正常之后，进一步包括：检查本地预设的连接检测数是否为零，若否，将本地预设的连接检测数置为零；

4.根据权利要求1至3任一所述的方法，其特征在于，所述保活消息为非NETCONF消息，在所述NETCONF连接的任一时间发送。

5.根据权利要求4所述的方法，其特征在于，所述保活消息携带响应回复标识，所述响应回复标识用于指示收到所述保活消息的所述服务端返回所述保活消息的响应消息。

6.一种NETCONF连接检测装置，其特征在于，该装置应用于NETCONF客户端，包括：

7.根据权利要求6所述的装置，其特征在于，所述确定单元依据在发出保活消息之后的所述指定时间内是否通过所述NETCONF连接接收到来自所述服务端发送的消息确定所述NETCONF连接是否正常包括：

8.根据权利要求7所述的装置，其特征在于，所述装置进一步包括：第一设置单元，用于检查本地预设的连接检测数是否为零，若否，将本地预设的连接检测数置为零；

9.根据权利要求6至8任一所述的装置，其特征在于，所述保活消息为非NETCONF消息，在所述NETCONF连接的任一时间发送。

10.根据权利要求9所述的装置，其特征在于，所述保活消息携带响应回复标识，所述响应回复标识用于指示收到所述保活消息的所述服务端返回所述保活消息的响应消息。