CN114363419A - 基于netconf协议的传输方法、设备及存储介质 - Google Patents

Abstract

本申请实施例涉及通信技术领域，公开了一种基于NETCONF协议的传输方法、设备及存储介质。本申请中，不论是发送端还是接收端，在与对方建立会话后，通过与建立会话的对端设备进行压缩能力交换来确定适用于两者的目标压缩格式，从而在进行数据传输的过程中，发送端可以根据目标压缩格式对需要传输的数据进行压缩，接收端在接收到发送端根据目标压缩格式压缩后的数据后，可以采用相同的目标压缩格式进行解压缩，进而还原出原数据，通过这种方式可以在大数据量交互的情况下，尽可能减小对网络资源的占用，同时大幅度缩短网络传输时间，降低网络压力。

Description

基于NETCONF协议的传输方法、设备及存储介质

技术领域

本申请实施例涉及通信技术领域，特别涉及一种基于NETCONF协议的传输方法、设备及存储介质。

背景技术

NETCONF是国际互联网工程任务组(The Internet Engineering Task Force，IETF)提出的一种管理网络设备的协议，基于此，用户可以对被控制网络设备的配置数据进行增加、删除、修改操作，也可以从被控制设备读取配置数据和状态数据。

目前，基于NETCONF协议的传输通常是非压缩文本传输方式，虽然基于这种传输方式可以实现客户端与服务端的消息交互。但是，随着设备复杂度的提高，以及云化设备的出现，一个管理设备的配置数据量可能会大幅上升，甚至可以达到几百兆规模。因此，如果使用目前NETCONF协议中规定的非压缩文本传输方式，势必会消耗大量网络资源和时间，造成极大的传输瓶颈。

发明内容

本申请实施例的目的在于提供一种基于NETCONF协议的传输方法、设备及存储介质，旨在解决上述技术问题。

为解决上述技术问题，本申请的实施例提供了一种基于NETCONF协议的传输方法，包括：

在与接收端建立会话后，与所述接收端进行压缩能力交换，确定目标压缩格式；

在向所述接收端传输数据时，根据所述目标压缩格式对所述数据进行压缩，并将压缩后的数据传输给所述接收端。

为实现上述目的，本申请实施例还提供了一种基于NETCONF协议的传输方法，包括：

在与发送端建立会话后，与所述发送端进行压缩能力交换，确定目标压缩格式；

在接收到所述发送端传输的数据后，根据所述目标压缩格式对所述数据进行解压缩。

为实现上述目的，本申请实施例还提供了一种基于NETCONF协议的传输设备，包括：

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如上所述的任意一种基于NETCONF协议的传输方法。

为实现上述目的，本申请实施例还提供了一种计算机可读存储介质，存储有计算机程序。所述计算机程序被处理器执行时实现上述所述的任意一种基于NETCONF协议的传输方法。

本申请提出的基于NETCONF协议的传输方法、设备及存储介质，不论是发送端还是接收端，在与对方建立会话后，通过与建立会话的对端设备进行压缩能力交换来确定适用于两者的目标压缩格式，从而在进行数据传输的过程中，发送端可以根据目标压缩格式对需要传输的数据进行压缩，接收端在接收到发送端根据目标压缩格式压缩后的数据后，可以采用相同的目标压缩格式进行解压缩，进而还原出原数据，通过这种方式可以在大数据量交互的情况下，尽可能减小对网络资源的占用，同时大幅度缩短网络传输时间，降低网络压力。

附图说明

一个或多个实施例通过与之对应的附图中的图片进行示例性说明，这些示例性说明并不构成对实施例的限定。

图1是本申请第一实施例提供的基于NETCONF协议的传输方法的流程图；

图2是本申请第二实施例提供的基于NETCONF协议的传输方法的流程图；

图3是本申请第三实施例提供的基于NETCONF协议的传输方法的流程图；

图4是本申请第四实施例提供的基于NETCONF协议的传输方法的流程图；

图5是本申请第七实施例提供的基于NETCONF协议的传输方法的发送端与接收端之间的交互示意图；

图6是本申请第八实施例提供的基于NETCONF协议的传输设备的结构示意程图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合附图对本申请的各实施例进行详细的阐述。然而，本领域的普通技术人员可以理解，在本申请各实施例中，为了使读者更好地理解本申请而提出了许多技术细节。但是，即使没有这些技术细节和基于以下各实施例的种种变化和修改，也可以实现本申请所要求保护的技术方案。以下各个实施例的划分是为了描述方便，不应对本申请的具体实现方式构成任何限定，各个实施例在不矛盾的前提下可以相互结合相互引用。

本申请的第一实施例涉及一种基于NETCONF协议的传输方法。该方法主要应用于交互过程中数据的发送端。

具体的说，在本实施例中，上述所说的发送端可以是客户端，也可以是服务端。

相应地，用于接收上述所说的发送端传输的数据的接收端可以是服务端，也可以是客户端。

此外，在本实施例中，上述所说的客户端，具体是NETCONF客户端，即遵循NETCONF协议的客户端。

相应地，上述所说的服务端，具体是NETCONF服务端，即遵循NETCONF协议的服务端。

此外，应当理解的是，在实际应用中，进行数据交互的两方，通常是客户端与服务端。因此，在本实施例中，若发送端是NETCONF客户端，则接收端是NETCONF服务端。

下面对本实施例的基于NETCONF协议的传输方法的实现细节进行说明，以下内容仅为方便理解而提供的实现细节，并非实施本方案的必须。

本实施例的具体流程如图1所示，具体包括以下步骤：

步骤101，在与接收端建立会话后，与所述接收端进行压缩能力交换，确定目标压缩格式。

具体的说，本实施例所说的压缩能力交互，实质就是指发送端与接收端协商确定目标压缩格式的过程。

关于该过程的实现，对于发送端来说，具体是通过以下几个步骤实现：

(1)获取本地支持的压缩格式，即获取发送端支持的压缩格式。

具体的说，由于不同的发送端自身支持的硬件资源的不同，因而不同的发送端所支持的压缩格式可能存在差异。故而，在与接收端协商确定目标压缩格式时，需要先获取自身支持的压缩格式，以保障最终确定的目标压缩格式是双方都支持的压缩格式。

(2)根据预设的压缩格式排序规则，对所述压缩格式进行排序，得到发送端压缩列表。

具体的说，本实施例中所说的压缩格式排序规则，是针对目前常见的压缩格式确定的。该压缩格式排序规则可以是根据压缩速度的快慢确定，也可以是根据压缩后的数据大小来确定，还可以是兼顾着二者，即根据压缩效率的高低来确定。

比如说，若所述压缩格式排序规则要求根据压缩速度的快慢对发送端支持的压缩格式进行排序，则得到的发送端压缩列表中，压缩速度越快的压缩格式所处的位置越靠前，压缩速度越慢的压缩格式所处的位置越靠后，即发送端压缩列表中的压缩格式是按照压缩速度从快到慢的顺序进行降序排列的。

还比如说，若所述压缩格式排序规则要求根据压缩后的数据大小对发送端支持的压缩格式进行排序，则得到的发送端压缩列表中，压缩后数据大小越小的压缩格式所处的位置越靠前，压缩后数据大小越大的压缩格式所处的位置越靠后，即发送端压缩列表中的压缩格式是按照压缩后数据的大小从小到大的顺序进行升序排列的。

还比如说，若所述压缩格式排序规则要求根据压缩效率的高低对发送端支持的压缩格式进行排序，则得到的发送端压缩列表中，压缩效率越高的压缩格式所处的位置越靠前，压缩效率越低的压缩格式所处的位置越靠后，即发送端压缩列表中的压缩格式是按照压缩效率从高到低的顺序进行降序排列的。

应当理解的是，上述示例仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

此外，值得一提的是，在实际应用中，为了保证发送端生成的发送端压缩列表和接收端生成的接收端压缩列表中相同压缩格式之间的位置关系相同，在生成发送端压缩列表和接收端压缩列表之前，需要先与进行数据交互的对端设备，在本实施例中具体是发送端与接收端进行协商，进而确定双方在生成对应的压缩列表(发送端压缩列表或接收端压缩列表)时所依据的压缩格式排序规则。即，数据交互双方所依据的压缩格式排序规则是相同的。

为了便于理解，以下结合实例进行说明：

假设，经发送端与接收端协商确定的压缩格式排序规则，规定的是按照压缩效率从高到低的顺序进行排序。

以现有常用的几种压缩格式zip、7z、gz、bz2为例，基于上述压缩格式排序规则，针对这几种压缩格式排序后得到的压缩格式列表顺序为：7z、bz2、zip、gz。

也就是说，在基于上述压缩格式排序规则，对发送端和接收端的压缩格式进行排序时，上述4中压缩格式的位置关系是确定的。

假设，发送端自身支持的压缩格式为7z和bz2，则基于上述压缩格式排序规则可知，7z的压缩效率要高于bz2，故而得到的发送端压缩格式列表中压缩格式的排列顺序为：7z、bz2。

应当理解的是，上述示例仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

(3)将所述发送端压缩列表传输给所述接收端，并接收所述接收端传输的接收端压缩列表，即进行压缩能力的交换。

(4)按序对所述接收端压缩列表进行遍历，将遍历到的所述接收端支持的压缩格式与所述发送端压缩列表中的压缩格式进行匹配。

相应地，若遍历到的所述接收端支持的压缩格式与所述发送端压缩列表中的压缩格式匹配，则将所述压缩格式确定为所述目标压缩格式。

此外，值得一提的是，由于本实施例中协商确定的压缩格式排列规则是将压缩效率高，或者压缩速度快，或者压缩后的数据大小小的压缩格式排在靠前的位置，因而为了保证确定的目标压缩格式为压缩效率高，或压缩速度快，或压缩后的数据大小小的压缩格式，故而上述所说的按序对所述接收端压缩列表进行遍历的操作，具体是按照从前往后的顺序进行遍历。

为了便于理解，此处以接收到的接收端压缩列表中的压缩格式为：bz2、gz为例，则在生成的客户端压缩列表为：7z、bz2时，通过将遍历到的接收端支持的压缩格式与发送端压缩列表中的压缩格式匹配，最终确定的目标压缩格式为bz2。

此外，应当理解的是，在实际应用中，发送端与接收端建立会话的过程，具体是由发送端先向需要进行数据交互的接收端发起建链请求，即建立会话链接的请求；然后，接收端在接收到发送端发起的建链请求后，作出针对该建链请求的建链响应，进而实现发送端与接收端双方的会话链路或会话通道的建立。

步骤102，在向所述接收端传输数据时，根据所述目标压缩格式对所述数据进行压缩，并将压缩后的数据传输给所述接收端。

具体的说，由于压缩是需要占用设备资源的，因此对于数据量较小的数据，在不影响带宽和网络传输负载，以及耗时较小的情况下，发送端与接收端在进行数据传输时，可以对此类数据不进行压缩，即直接进行传输。故而，为了使得本实施例提供的基于NETCONF协议的传输方法既可以兼顾传输效率，又可以兼顾对设备资源的消耗。对于数据的发送端，不论是NETCONF客户端还是NETCONF服务端，均可以预先设置压缩阈值。进而，在向接收端传输数据时，先判断需要传输的数据的大小是否大于所述压缩阈值。

相应地，在需要传输的数据的大小，大于所述压缩阈值时，才根据确定的目标压缩格式对所述数据进行压缩，并将压缩后的数据传输给接收端；否则，直接将未经压缩处理的数据传输给接收端。

通过设置压缩阈值，从而可以根据需要传输的数据大小来决定是采用压缩方式传输，还是非压缩方式传输，从而既兼顾了传输效率，又兼顾了设备资源的消耗。

进一步地，为了实现压缩阈值的动态调整，在实际应用中，可以根据发送端与接收端之间的网络通道的网络质量来动态调整压缩阈值。

也就是说，在发送端与接收端的交互过程中，定期检测双方之间的网络通道的网络质量，如果网络质量变差，比如网络时延升高，则降低压缩阈值，反之则提高压缩阈值，从而在不增加网络负载的情况下，使得发送端与接收端之间的数据传输更加灵活高效。

通过上述描述不难发现，本实施例提供的基于NETCONF协议的传输方法，发送端在与接收端建立会话后，通过与接收端进行压缩能力交换来确定适用于两者的目标压缩格式，从而在进行数据传输的过程中，发送端可以根据目标压缩格式对需要传输的数据进行压缩，接收端在接收到发送端根据目标压缩格式压缩后的数据后，可以采用相同的目标压缩格式进行解压缩，进而还原出原数据，通过这种方式可以在大数据量交互的情况下，尽可能减小对网络资源的占用，同时大幅度缩短网络传输时间，降低网络压力。

此外，由于本实施例提供的基于NETCONF协议的传输方法，压缩传输方式所依据的目标压缩格式是直接由发送端和接收端协商确定的，整个传输过程不需要涉及其他第三方设备，因而相较于传输统一资源定位器(Uniform Resource Locator，URL)，即数据的发送端需要将传输的数据上传到单独的第三方文件传输服务器，然后由文件传输服务器或者发送端将该数据在文件传输服务器对应的存储位置的URL发送给接收端，最后接收端根据该URL从文件服务器获取发送端提供的数据的方式，本实施例提供的基于NETCONF协议的传输方法无需构建第三方文件传输服务器，因而大大接收了实现成本，同时也节约了网络链接数开销。并且，由于数据是直接在发送端和接收端传输的，因而也更好的保证了事务的一致性。

本申请的第二实施例涉及一种基于NETCONF协议的传输方法。第二实施例在第一实施例的基础上做了进一步改进，主要改进之处为：在将压缩后的数据传输给接收端时，通过对压缩后的数据进行编码，并在编码获得的编码帧中插入标识当前编码帧对应的数据是压缩数据的压缩标志符，从而使得接收端能够根据编码帧中的开始标志符合结束标志符快速、准确的确定要解析的数据的范围，以及当前要解析的数据是否为压缩数据，是否需要根据目标压缩格式进行解压缩。

如图2所示，第二实施例涉及的基于NETCONF协议的传输方法，包括如下步骤：

步骤201，在与接收端建立会话后，与所述接收端进行压缩能力交换，确定目标压缩格式。

不难发现，本实施例中的步骤201与第一实施例中的步骤101大致相同，在此就不再赘述，以下主要针对不同之处，即构成步骤202的4个子步骤进行说明。

子步骤2021，在向所述接收端传输数据时，根据所述目标压缩格式对所述数据进行压缩。

子步骤2022，根据预设的编码方法，对压缩后的所述数据进行编码，得到编码帧。

具体的说，根据预设的编码方法对压缩后的数据进行编码获得的的编码帧中，除了包括编码后的数据本身，还包括标识数据开始的开始标志符和标识数据结束的结束标志符。

应当理解的是，上述所说的开始标志符是为了告诉接收端从何起开始对接收到的数据进行解析。

相应地，上述所说的结束标志符时为了告诉接收端解析到哪一个位置结束解析。

此外，需要说明的是，上述所说的解析是指接收端将编码帧还原成编码前的数据。

子步骤2023，在所述编码帧中插入压缩标志符。

具体的说，上述所说的压缩标志符，是为了告知接收端当前接收到的编码帧是基于确定目标压缩格式压缩后的数据编码而来的。即，如果编码帧中携带有压缩标志符，接收端在接收到所述编码帧，便会基于确定的目标压缩格式对所述编码帧进行解压缩，以还原出发送端传输的原数据。

子步骤2024，将携带有所述压缩标志符的编码帧传输给所述接收端。

为了便于说明，本实施例以基于超文本传输协议(HyperText TransferProtocol，HTTP)的分块传输编码(chunk编码)为例进行具体说明：

具体的，发送端的传输层在按照确定的目标压缩格式对需要传输的数据进行压缩之后，会按照如下伪代码，将压缩后的数据编码成帧：

chunk-size＝1*DIGIT1 0*DIGIT//一串十进制数字，表示块数据中的八位字节数。禁止前导零，并且允许的最大块大小值为4294967295

chunk-data＝1*OCTET

end-of-chunks＝LF HASH HASH LF

DIGIT1＝％x31-39

DIGIT＝％x30-39

HASH＝％x23

CHASH＝％xE3 //压缩标志符

LF＝％x0A

OCTET＝％x00-F

应当理解的是，上述示例仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

由此，本实施例提供的基于NETCONF协议的传输方法，在将压缩后数据传输给接收端时，通过将压缩后的数据转换为携带有开始标志符、结束标志符和压缩标志符的编码帧，从而可以使得接收端能够获知从何时开始解析，解析到何时，并且解析的数据是否需要根据确定的目标压缩格式进行解压缩，通过这种方式，有效保证了数据传输的正确性，使得数据能够更好更正确的传输到对方。

本申请的第三实施例涉及一种基于NETCONF协议的传输方法。该方法主要应用于交互过程中数据的接收端。

具体的说，在本实施例中，上述所说的接收端可以是服务端，也可以是客户端。

相应地，用于向上述所说的接收端传输数据的发送端可以是客户端，也可以是服务端。

此外，在本实施例中，上述所说的客户端，具体是NETCONF客户端，即遵循NETCONF协议的客户端。

相应地，上述所说的服务端，具体是NETCONF服务端，即遵循NETCONF协议的服务端。

此外，应当理解的是，在实际应用中，进行数据交互的两方，通常是客户端与服务端。因此，在本实施例中，若发送端是NETCONF客户端，则接收端是NETCONF服务端。

下面对本实施例的基于NETCONF协议的传输方法的实现细节进行说明，以下内容仅为方便理解而提供的实现细节，并非实施本方案的必须。

本实施例的具体流程如图3所示，具体包括以下步骤：

步骤301，在与发送端建立会话后，与所述发送端进行压缩能力交换，确定目标压缩格式。

具体的说，本实施例中所说的压缩能力交互，实质就是指接收端与发送端协商确定目标压缩格式的过程。

关于该过程的实现，对于接收端来说，具体是通过以下几个步骤实现：

(1)获取本地支持的压缩格式，即获取接收端支持的压缩格式。

具体的说，由于不同的接收端自身支持的硬件资源的不同，因而不同的接收端所支持的压缩格式可能存在差异。故而，在与发送端协商确定目标压缩格式时，需要先获取自身支持的压缩格式，以保障最终确定的目标压缩格式是双方都支持的压缩格式。

(2)根据预设的压缩格式排序规则，对所述压缩格式进行排序，得到接收端压缩列表。

具体的说，本实施例中所说的压缩格式排序规则，是针对目前常见的压缩格式确定的。该压缩格式排序规则可以是根据压缩速度的快慢确定，也可以是根据压缩后的数据大小来确定，还可以是兼顾着二者，即根据压缩效率的高低来确定。

比如说，若所述压缩格式排序规则要求根据压缩速度的快慢对接收端支持的压缩格式进行排序，则得到的接收端压缩列表中，压缩速度越快的压缩格式所处的位置越靠前，压缩速度越慢的压缩格式所处的位置越靠后，即接收端压缩列表中的压缩格式是按照压缩速度从快到慢的顺序进行降序排列的。

还比如说，若所述压缩格式排序规则要求根据压缩后的数据大小对接收端支持的压缩格式进行排序，则得到的接收端压缩列表中，压缩后数据大小越小的压缩格式所处的位置越靠前，压缩后数据大小越大的压缩格式所处的位置越靠后，即接收端压缩列表中的压缩格式是按照压缩后数据的大小从小到大的顺序进行升序排列的。

还比如说，若所述压缩格式排序规则要求根据压缩效率的高低对接收端支持的压缩格式进行排序，则得到的接收端压缩列表中，压缩效率越高的压缩格式所处的位置越靠前，压缩效率越低的压缩格式所处的位置越靠后，即接收端压缩列表中的压缩格式是按照压缩效率从高到低的顺序进行降序排列的。

应当理解的是，上述示例仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

此外，值得一提的是，在实际应用中，为了保证接收端生成的接收端压缩列表和发送端生成的发送端压缩列表中相同压缩格式之间的位置关系相同，在生成接收端压缩列表和发送端压缩列表之前，需要先与进行数据交互的对端设备，在本实施例中具体是接收端与发送端进行协商，进而确定双方在生成对应的压缩列表(接收端压缩列表或发送端压缩列表)时所依据的压缩格式排序规则。即，数据交互双方所依据的压缩格式排序规则是相同的。

为了便于理解，以下结合实例进行说明：

假设，经接收端与发送端协商确定的压缩格式排序规则，规定的是按照压缩效率从高到低的顺序进行排序。

以现有常用的几种压缩格式zip、7z、gz、bz2为例，基于上述压缩格式排序规则，针对这几种压缩格式排序后得到的压缩格式列表顺序为：7z、bz2、zip、gz。

也就是说，在基于上述压缩格式排序规则，对接收端和发送端的压缩格式进行排序时，上述4中压缩格式的位置关系是确定的。

假设，接收端自身支持的压缩格式为bz2和gz，则基于上述压缩格式排序规则可知，bz2的压缩效率要高于gz，故而得到的接收端压缩格式列表中压缩格式的排列顺序为：bz2、gz。

应当理解的是，上述示例仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

(3)将所述接收端压缩列表传输给所述发送端，并接收所述发送端传输的发送端压缩列表。

(4)按序对所述发送端压缩列表进行遍历，将遍历到的所述发送端支持的压缩格式与所述接收端压缩列表中的压缩格式进行匹配。

相应地，若遍历到的所述发送端支持的压缩格式与所述接收端压缩列表中的压缩格式匹配，则将所述压缩格式确定为所述目标压缩格式。

此外，值得一提的是，由于本实施例中协商确定的压缩格式排列规则是将压缩效率高，或者压缩速度快，或者压缩后的数据大小小的压缩格式排在靠前的位置，因而为了保证确定的目标压缩格式为压缩效率高，或压缩速度快，或压缩后的数据大小小的压缩格式，故而上述所说的按序对所述接收端压缩列表进行遍历的操作，具体是按照从前往后的顺序进行遍历。

为了便于理解，此处以接收到的发送端压缩列表中的压缩格式为：7z、bz2为例，则在生成的接收端压缩列表为：bz2、gz时，通过将遍历到的发送端支持的压缩格式与接收端压缩列表中的压缩格式匹配，最终确定的目标压缩格式为bz2。

此外，应当理解的是，在实际应用中，接收端与发送端建立会话的过程，具体是由发送端先向需要进行数据交互的接收端发起建链请求，即建立会话链接的请求；然后，接收端在接收到发送端发起的建链请求后，作出针对该建链请求的建链响应，进而实现发送端与接收端双方的会话链路或会话通道的建立。

步骤302，在接收到所述发送端传输的数据后，根据所述目标压缩格式对所述数据进行解压缩。

通过上述描述不难发现，本实施例提供的基于NETCONF协议的传输方法，接收端在与发送端建立会话后，通过与发送端进行压缩能力交换来确定适用于两者的目标压缩格式，从而在进行数据传输的过程中，发送端可以根据目标压缩格式对需要传输的数据进行压缩，接收端在接收到发送端根据目标压缩格式压缩后的数据后，可以采用相同的目标压缩格式进行解压缩，进而还原出原数据，通过这种方式可以在大数据量交互的情况下，尽可能减小对网络资源的占用，同时大幅度缩短网络传输时间，降低网络压力。

本申请的第四实施例涉及一种基于NETCONF协议的传输方法。第四实施例在第三实施例的基础上做了进一步改进，主要改进之处为：针对发送端传输的数据为编码后得到的编码帧，且编码帧中至少包括的开始标志符和结束标志符的情况，在对接收到的数据进行解压缩时，通过识别编码帧中的开始标志符和结束标志符，确定何时开始处理接收到的数据，何时结束处理。同时，通过识别编码帧中是否携带有压缩标志符，具体是否对当前处理的数据进行解压缩，从而使得接收端可以快速、准确的还原出采用压缩方式传输的数据和非压缩方式传输的数据。

如图4所示，第四实施例涉及的基于NETCONF协议的传输方法，包括如下步骤：

步骤401，在与发送端建立会话后，与所述发送端进行压缩能力交换，确定目标压缩格式。

不难发现，本实施例中的步骤401与第三实施例中的步骤301大致相同，在此就不再赘述，以下主要针对不同之处，即构成步骤402的2个子步骤进行说明。

子步骤4021，在从所述编码帧中识别到所述开始标志符时，检测所述编码帧中是否携带有压缩标志符。

子步骤4022，在所述编码帧中携带有所述压缩标志符时，根据所述目标压缩格式对所述编码帧进行解压缩至所述结束标志符。

由此，本实施例提供的基于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协议的传输系统，包括发送端和接收端。

为了便于说明，以下结合图5，对发送端和接收端的具体交互流程进行说明。

(1)在进行基于NETCONF协议的传输，即进行数据交互时，发送端会向需要进行数据交互的接收端发起建链请求，即建立会话链接的请求。

(2)接收端根据接收到的来自发送端的建链请求，作出建链响应，从而实现发送端与接收端之间会话通道或链接的建立。

(3)在发送端与接收端之间的会话建立后，双方开始压缩能力交换操作，即协商确定目标压缩格式，在此过程中还可以同时确定各自的压缩阈值。

具体的说，针对发送端向接收端发送的压缩能力交互信息，在本实施例中具体是通过向接收端发送hello消息，并在hello消息中携带压缩传输能力(压缩阈值)和发送端压缩列表，发送的hello消息，具体可以通过如下伪代码实现：

针对接收端向发送端发送的压缩能力交互信息，在本实施例中具体是通过向发送端发送hello消息，并在hello消息中携带压缩传输能力(压缩阈值)和接收端压缩列表，发送的hello消息，具体可以通过如下伪代码实现：

通过上述两个hello消息可知，发送端和接收端预设的压缩阈值均为size＝10，即10M；发送端接收到的接收端压缩列表为：bz2，gz；接收端接收到的发送端压缩列表为：7z，bz2，gz。因此，最终协商确定的目标压缩格式为bz2。

应当理解的是，上述示例仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

(4)当某次用户操作，例如是通过发送端配置一份大小为133M的数据到接收端，此时发送端的传输层通过判断确定需要传输到接收端的数据大小超过了压缩阈值(10M)，需要根据与接收端协商确定的目标压缩格式进行数据压缩，并采用预设的编码方法将压缩后的数据编码成帧，并将编码获得的编码帧通过底层的通信层传输给接收端。

以编码方式采用的是chunk编码为例，则对采用bz2压缩格式压缩后的数据进行编码后，得到的编码帧如下：

C:\n#1400c\n

C:....1400个字节.....

C:\n#1400c\n

C:....1400个字节.....

C:...

C:\n##\n

应当理解的是，上述示例仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。

(5)当接收端通过监控用于标识开始的开始标志符和标识结束的结束标志符后，去掉帧头帧为，并在识别到携带了压缩标志符时，采样协商确定的目标压缩格式，对收到的完整消息进行解压缩，再将解压后的数据投递给消息层进行解析处理。

由此，在本实施例提供的基于NETCONF协议的传输系统中，不论是发送端还是接收端，在与对方建立会话后，通过与建立会话的对端设备进行压缩能力交换来确定适用于两者的目标压缩格式，从而在进行数据传输的过程中，发送端可以根据目标压缩格式对需要传输的数据进行压缩，接收端在接收到发送端根据目标压缩格式压缩后的数据后，可以采用相同的目标压缩格式进行解压缩，进而还原出原数据，通过这种方式可以在大数据量交互的情况下，尽可能减小对网络资源的占用，同时大幅度缩短网络传输时间，降低网络压力。

本申请的第八实施例涉及一种基于NETCONF协议的传输设备，如图6所示，包括：包括至少一个处理器601；以及，与至少一个处理器601通信连接的存储器602；其中，存储器602存储有可被至少一个处理器601执行的指令，指令被至少一个处理器601执行，以使至少一个处理器601能够执行上述任意一种方法实施例所描述的基于NETCONF协议的传输方法。

其中，存储器602和处理器601采用总线方式连接，总线可以包括任意数量的互联的总线和桥，总线将一个或多个处理器601和存储器602的各种电路连接在一起。总线还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路连接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口在总线和收发机之间提供接口。收发机可以是一个元件，也可以是多个元件，比如多个接收器和发送器，提供用于在传输介质上与各种其他装置通信的单元。经处理器601处理的数据通过天线在无线介质上进行传输，进一步，天线还接收数据并将数据传送给处理器601。

处理器601负责管理总线和通常的处理，还可以提供各种功能，包括定时，外围接口，电压调节、电源管理以及其他控制功能。而存储器602可以被用于存储处理器601在执行操作时所使用的数据。

本申请的第九实施例涉及一种计算机可读存储介质，存储有计算机程序。计算机程序被处理器执行时实现上述任意一种方法实施例所描述的基于NETCONF协议的传输方法。

即，本领域技术人员可以理解，实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本申请各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

本领域的普通技术人员可以理解，上述各实施例是实现本申请的具体实施例，而在实际应用中，可以在形式上和细节上对其作各种改变，而不偏离本申请的精神和范围。

Claims (12)

1.一种基于NETCONF协议的传输方法，其特征在于，包括：

在与接收端建立会话后，与所述接收端进行压缩能力交换，确定目标压缩格式；

在向所述接收端传输数据时，根据所述目标压缩格式对所述数据进行压缩，并将压缩后的数据传输给所述接收端。

2.如权利要求1所述的基于NETCONF协议的传输方法，其特征在于，所述与所述接收端进行压缩能力交换，确定目标压缩格式，包括：

获取本地支持的压缩格式；

根据预设的压缩格式排序规则，对所述压缩格式进行排序，得到发送端压缩列表；

将所述发送端压缩列表传输给所述接收端，并接收所述接收端传输的接收端压缩列表；

按序对所述接收端压缩列表进行遍历，将遍历到的所述接收端支持的压缩格式与所述发送端压缩列表中的压缩格式进行匹配；

若遍历到的所述接收端支持的压缩格式与所述发送端压缩列表中的压缩格式匹配，则将所述压缩格式确定为所述目标压缩格式。

3.如权利要求2所述的基于NETCONF协议的传输方法，其特征在于，在所述根据预设的压缩格式排序规则，对所述压缩格式进行排序，得到发送端压缩列表之前，所述方法还包括：

与所述接收端协商所述压缩格式排序规则，并在确定所述压缩格式排序规则后执行所述根据预设的压缩格式排序规则，对所述压缩格式进行排序，得到发送端压缩列表的步骤。

4.如权利要求1至3中任一项所述的基于NETCONF协议的传输方法，其特征在于，所述在向所述接收端传输数据时，根据所述目标压缩格式对所述数据进行压缩，并将压缩后的数据传输给所述接收端，包括：

在向所述接收端传输数据时，判断所述数据的大小是否大于压缩阈值；

若所述数据的大小大于所述压缩阈值，则根据所述目标压缩格式对所述数据进行压缩，并将压缩后的数据传输给所述接收端。

5.如权利要求4所述的基于NETCONF协议的传输方法，其特征在于，在所述判断所述数据的大小是否大于压缩阈值之前，所述方法还包括：

检测与所述接收端之间的网络通道的网络质量；

根据所述网络质量确定所述压缩阈值。

6.如权利要求1至3中任一项所述的基于NETCONF协议的传输方法，其特征在于，所述将压缩后的数据传输给所述接收端，包括：

根据预设的编码方法，对压缩后的所述数据进行编码，得到编码帧，所述编码帧包括开始标志符和结束标志符；

在所述编码帧中插入压缩标志符，所述压缩标志符供所述接收端在接收到所述编码帧后根据所述目标压缩格式对所述编码帧进行解压缩；

将携带有所述压缩标志符的编码帧传输给所述接收端。

7.一种基于NETCONF协议的传输方法，其特征在于，包括：

在与发送端建立会话后，与所述发送端进行压缩能力交换，确定目标压缩格式；

在接收到所述发送端传输的数据后，根据所述目标压缩格式对所述数据进行解压缩。

8.如权利要求7所述的基于NETCONF协议的传输方法，其特征在于，所述与所述发送端进行压缩能力交换，确定目标压缩格式，包括：

获取本地支持的压缩格式；

根据预设的压缩格式排序规则，对所述压缩格式进行排序，得到接收端压缩列表；

将所述接收端压缩列表传输给所述发送端，并接收所述发送端传输的发送端压缩列表；

按序对所述发送端压缩列表进行遍历，将遍历到的所述发送端支持的压缩格式与所述接收端压缩列表中的压缩格式进行匹配；

若遍历到的所述发送端支持的压缩格式与所述接收端压缩列表中的压缩格式匹配，则将所述压缩格式确定为所述目标压缩格式。

9.如权利要求8所述的基于NETCONF协议的传输方法，其特征在于，在所述根据预设的压缩格式排序规则，对所述压缩格式进行排序，得到接收端压缩列表之前，所述方法还包括：

与所述发送端协商所述压缩格式排序规则，并在确定所述压缩格式排序规则后执行所述根据预设的压缩格式排序规则，对所述压缩格式进行排序，得到接收端压缩列表的步骤。

10.如权利要求7至9中任一项所述的基于NETCONF协议的传输方法，其特征在于，所述发送端传输的数据为编码后得到的编码帧，所述编码帧包括开始标志符和结束标志符；

所述根据所述目标压缩格式对所述数据进行解压缩，包括：

在从所述编码帧中识别到所述开始标志符时，检测所述编码帧中是否携带有压缩标志符；

若所述编码帧中携带有所述压缩标志符，则根据所述目标压缩格式对所述编码帧进行解压缩至所述结束标志符。

11.一种基于NETCONF协议的传输设备，其特征在于，包括：

至少一个处理器；以及，

与所述至少一个处理器通信连接的存储器；其中，

所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如权利要求1至6中任一所述的基于NETCONF协议的传输方法；或者，如权利要求7至10中任一项所述的基于NETCONF协议的传输方法。

12.一种计算机可读存储介质，存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至6中任一项所述的基于NETCONF协议的传输方法；或者，如权利要求7至10中任一项所述的基于NETCONF协议的传输方法。

Images