CN109218214A - 运营商级通用流量压缩方法及装置 - Google Patents

Abstract

本申请提供一种运营商级通用流量压缩方法及装置，方法包括：根据针对运营商网络的数据传输指令，启动数据接收端的数据解压进程，其中，所述数据传输指令中包含有数据发送端和所述数据接收端；在所述数据发送端根据所述数据传输指令启动目标数据的发送进程时，应用预设的流量牵引方式，将所述目标数据中的待压缩数据进行压缩，使得所述数据发送端将压缩后数据及所述目标数据中的未压缩数据均发送至所述数据接收端。本申请能够有效实现针对运营商级的网络流量压缩，并能够在不改变运营商网络中原设备的基础上，针对运营商网络中的数据传输过程中的热点流量进行快速且有效的压缩，进而有效提高运营商网络中的数据传输效率及可靠性。

Description

运营商级通用流量压缩方法及装置

技术领域

本申请涉及数据处理技术领域，具体涉及一种运营商级通用流量压缩方法及装置。

背景技术

随着高带宽类业务的飞速发展，企业对接入带宽的需求也在日益增长，同时也往往需要付出高昂的带宽升级成本。而通过引入全局的IP流量压缩技术，能够实现广域网加速，进而能够在不升级带宽的基础上，最大化地提高现有的带宽利用效率。针对流量压缩的概念，IP报文本身就考虑了报文压缩的扩展支持。但是流量压缩会带来时延，也没有统一的流量压缩规范，因此没有得到应用。而在带宽高度敏感的移动端，也已有各种各样的流量压缩应用，比如欧朋opera浏览器，但是这些通常仅能够针对特性的应用(如www浏览)进行压缩。另外，在企业级市场，也有专门的加速硬件网关，可以实现两地之间的网络压缩和加速，但是需要采购专门硬件设备，作为网关接入到企业网络，需要重新调整原有的网络结构。以及，由于在数据传输过程中，压缩和解压操作通常成对使用，因此通常仅能用于企业内部的VPN专网。

目前，对于运营商而言，虽然其核心网的主要设计为轻载设计，但是其局部拥塞的情形(尤其是网络出口和IDC出口)也是存在的。另外，由于运营商的组网方式是网状的，通常不存在点对点的成对线路，而且设备出口带宽都已经高达10G甚至100G以上，因此使得针对现有设备的升级成本非常高，而串接新设备的带宽和处理效率也无法运营商网络的运行需求。

因此，如何提供一种专门针对运营商级的网络流量压缩方式，是亟待解决的问题。

发明内容

针对现有技术中的问题，本申请提供一种运营商级通用流量压缩方法及装置，能够有效实现针对运营商级的网络流量压缩，并能够在不改变运营商网络中原设备的基础上，针对运营商网络中的数据传输过程中的热点流量进行快速且有效的压缩，进而有效提高运营商网络中的数据传输效率及可靠性。

为解决上述技术问题，本申请提供以下技术方案：

第一方面，本申请提供一种运营商级通用流量压缩方法，包括：

根据针对运营商网络的数据传输指令，启动数据接收端的数据解压进程，其中，所述数据传输指令中包含有数据发送端和所述数据接收端；

在所述数据发送端根据所述数据传输指令启动目标数据的发送进程时，应用预设的流量牵引方式，将所述目标数据中的待压缩数据进行压缩，使得所述数据发送端将压缩后数据及所述目标数据中的未压缩数据均发送至所述数据接收端。

进一步地，在所述将所述目标数据中的待压缩数据进行压缩之前，还包括：

应用预设的流量牵引方式在所述目标数据中获取所述待压缩数据。

进一步地，所述将所述目标数据中的待压缩数据进行压缩，包括：

基于预设的压缩协议将经所述压缩标记的所述待压缩数据进行并行压缩，得到压缩后数据，以及，将所述压缩后数据进行压缩标记；

以及，将经所述压缩标记的压缩后数据转发至所述数据接收端。

进一步地，还包括：

对所述数据接收端接收到的所述压缩后数据进行解压缩，使得所述数据接收端接收并存储解压缩数据及所述目标数据中的未压缩数据。

进一步地，在所述对所述数据接收端接收到的所述压缩后数据进行解压缩之前，还包括：

应用预设的流量牵引方式在所述数据接收端接收到的数据中获取待解压缩数据。

进一步地，所述对所述数据接收端接收到的所述压缩后数据进行解压缩，包括：

基于预设的压缩协议对所述待解压缩数据进行并行解压缩，得到解压缩数据；

以及，将所述解压缩数据转发至所述数据接收端。

第二方面，本申请提供一种运营商级通用流量压缩装置，包括：

编排器，用于根据针对运营商网络的数据传输指令，启动数据接收端的数据解压进程，其中，所述数据传输指令中包含有数据发送端和所述数据接收端；

第一流量压缩设备，设置在所述数据发送端，用于在所述数据发送端根据所述数据传输指令启动目标数据的发送进程时，应用预设的流量牵引方式，将所述目标数据中的待压缩数据进行压缩，使得所述数据发送端将压缩后数据及所述目标数据中的未压缩数据均发送至所述数据接收端。

进一步地，所述第一流量压缩设备中包括：

第一控制器，用于应用预设的流量牵引方式在所述目标数据中获取所述待压缩数据。

进一步地，所述第一流量压缩设备中还包括：

第一压缩集群，用于基于预设的压缩协议将经所述压缩标记的所述待压缩数据进行并行压缩，得到压缩后数据，以及，将所述压缩后数据进行压缩标记；

第一转发器，用于将经所述压缩标记的压缩后数据转发至所述数据接收端。

进一步地，还包括：

第二流量压缩设备，设置在所述数据接收端，用于对所述数据接收端接收到的所述压缩后数据进行解压缩，使得所述数据接收端接收并存储解压缩数据及所述目标数据中的未压缩数据。

进一步地，所述第二流量压缩设备中包括：

第二控制器，用于应用预设的流量牵引方式在所述数据接收端接收到的数据中获取待解压缩数据。

进一步地，所述第二流量压缩设备中还包括：

第二压缩集群，用于基于预设的压缩协议对所述待解压缩数据进行并行解压缩，得到解压缩数据；

第二转发器，用于将所述解压缩数据转发至所述数据接收端。

第三方面，本申请提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现所述的运营商级通用流量压缩方法的步骤。

第四方面，本申请提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现所述的运营商级通用流量压缩方法的步骤。

由上述技术方案可知，本申请提供一种运营商级通用流量压缩方法，通过根据针对运营商网络的数据传输指令，启动数据接收端的数据解压进程，其中，所述数据传输指令中包含有数据发送端和所述数据接收端；在所述数据发送端根据所述数据传输指令启动目标数据的发送进程时，应用预设的流量牵引方式，将所述目标数据中的待压缩数据进行压缩，使得所述数据发送端将压缩后数据及所述目标数据中的未压缩数据均发送至所述数据接收端，能够有效实现针对运营商级的网络流量压缩，并能够在不改变运营商网络中原设备的基础上，针对运营商网络中的数据传输过程中的热点流量进行快速且有效的压缩，实现运营商网络加速，提升业务接入能力，从而提升运营商网络的带宽利用效率。并能够针对不同类型的流量进行不同的处理，结合网络编排，有效推进运营商的SD-WAN建设。

附图说明

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

图1为本申请实施例中的运营商级通用流量压缩装置的总体框架的结构示意图。

图2为本申请实施例中的流量压缩设备的具体结构示意图。

图3为本申请实施例中的数据发送端和数据接收端的总体框架的结构示意图。

图4为本申请实施例中的数据发送端和数据接收端的具体结构示意图。

图5为本申请实施例中的包含有业务路由器和转发路由器的节点的结构示意图。

图6为本申请实施例中的运营商级通用流量压缩装置的具体结构示意图。

图7为本申请实施例中的运营商级通用流量压缩方法的流程示意图。

图8为本申请实施例中的包含有步骤A00的运营商级通用流量压缩方法的流程示意图。

图9为本申请实施例中的运营商级通用流量压缩方法中步骤200的流程示意图。

图10为本申请实施例中的包含有步骤300的运营商级通用流量压缩方法的流程示意图。

图11为本申请实施例中的包含有步骤B00的运营商级通用流量压缩方法的流程示意图。

图12为本申请实施例中的运营商级通用流量压缩方法中步骤300的流程示意图。

图13为本申请应用实例中的各类型压缩机压缩速率比较示意图。

图14为本申请实施例中的电子设备的结构示意图。

具体实施方式

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

针对现有的运营商网络中现有设备的升级成本非常高，而串接新设备的带宽和处理效率也无法运营商网络的运行需求的问题，本申请提供一种运营商级通用流量压缩方法、运营商级通用流量压缩装置、电子设备和计算机存储介质。参见图1，其中的运营商级通用流量压缩装置包括：分别部署在运营商网络中的各个特定节点中的各个流量压缩设备2，以及部署在各个流量压缩设备2之间的编排器1，利用流量牵引的原理，可以在不改变原有网络设备的情况下，通过合理调度，将特定的业务流量牵引到流量压缩设备进行压缩/解压，实现广域网加速，从而提升带宽的利用效率。其中，所述编排器也可以被称为中心协调器，通过中心协调器，对处于不同节点中的各个流量压缩设备进行统一协调，可以下发不同的策略，实现压缩的开启\停止\参数调整。

可以理解的是，上述流量压缩设备2可以为一种能够实现应用预设的流量牵引方式，将所述目标数据中的待压缩数据进行压缩和/或解压的集成设备。而在另一种具体实施方式中，参见图2，所述流量压缩设备2也可以为根据功能不同，被具体划分为控制器3、转发器4以及至少一个压缩集群5。且控制器3、转发器4以及至少一个压缩集群5可以设置在一台主机中，也可以分别设置在不同的主机中，形成一种分布式系统。其中，所述控制器3分别与所述编排器1和其所在的节点通信连接，所述转发器4分别与其所在的节点和所述压缩集群5通信连接。

由于在数据传输中，数据需要在发送端节点进行压缩，并在接收端节点进行解压，因此，为了方便说明，参见图3，本申请中将节点按在当前的数据传输中的角色，区分为数据发送端6和数据接收端7。可以理解的是，随着数据流向方向的改变，之前为数据发送端6的节点当前也可以变更为数据接收端7。

基于上述对运营商网络中节点的区分，在本申请的一个或多个实施例中，参见图4，还可以将流量压缩设备区分为第一流量牵引设备21和第二流量牵引设备22，其中，所述第一流量牵引设备21设置在所述数据发送端6中，所述第二流量牵引设备22设置在所述数据接收端7。相对应的，所述控制器、转发器和压缩集群也均可以进行区分，具体为：所述控制器可以区分为第一控制器31和第二控制器32，所述转发器可以区分为第一转发器41和第二转发器42，所述压缩集群可以区分为第一压缩集群51和第二压缩集群52。其中，所述第一控制器31、第一转发器41和第一压缩集群51均设置在所述第一流量牵引设备21中，所述第二控制器32、第二转发器42和第二压缩集群52均设置在所述第二流量牵引设备22中。

可以理解的是，参见图5，所述运营商网络中的节点中至少包含有业务路由器8和转发路由器9；所述转发器4和控制器3均与所述转发路由器9通信连接，所述业务路由器8与转发路由器9之间通信连接，当前节点的所述转发路由器9用于与其他节点的所述转发路由器9通信连接，即，各个节点经由其内的转发路由器9实现数据的接收与发送。

基于上述内容，根据节点当前所处的数据传输角色，参见图6，若该节点为数据发送端6，则所述转发路由器9为出口路由器91。若该节点为数据接收端7，则所述转发路由器9为入口路由器92。

另外，所述运营商网络中还可以设有深度报文检测DPI(Deep PacketInspection)设备或流量清洗设备，且该DPI设备或流量清洗设备通过旁路接入所述转发路由器，其中，所述DPI设备是具备业务数据流识别、业务数据流控制能力，工作在OSI模型传输层到应用层，具有高数据处理能力，能够对网络所承载的业务进行识别和流量管理，可部署在网络骨干层、城域网和企业内部的网络设备。其中，所述流量清洗设备为用于提供流量清洗(Flow Cleaning)服务的设备，所述流量清洗服务是提供给租用IDC服务的政企客户，该服务对进入客户IDC的数据流量进行实时监控，及时发现包括DOS攻击在内的异常流量。在不影响正常业务的前提下，清洗掉异常流量。有效满足客户对IDC运作连续性的要求。同时该服务通过时间通告、分析报表等服务内容提升客户网络流量的可见性和安全状况的清晰性。

为了有效实现针对运营商级的网络流量压缩，并能够在不改变运营商网络中原设备的基础上，针对运营商网络中的数据传输过程中的热点流量进行快速且有效的压缩，本申请实施例提供一种运营商级通用流量压缩方法的具体实施方式，参见图7，所述运营商级通用流量压缩方法具体包括如下内容：

步骤100：根据针对运营商网络的数据传输指令，启动数据接收端的数据解压进程，其中，所述数据传输指令中包含有数据发送端和所述数据接收端。

在步骤100中，所述运营商级通用流量压缩装置中的编排器根据接收自外部设备、数据接收端或者其自身生成的数据传输指令，启动所述数据传输指令中指定的数据接收端的数据解压进程。

可以理解的是，为了避免由于没有启动数据接收端的解压缩进程，而引起的压缩后的流量无法被所述数据接收端处理而丢弃的情况发生，在所述数据发送端对待发送数据进行压缩之前，需要先启动数据接收端的解压缩进程，以避免业务压缩包的丢失。也就是说，本申请的步骤100能够有效提高数据压缩后传输过程的可靠性。

步骤200：在所述数据发送端根据所述数据传输指令启动目标数据的发送进程时，应用预设的流量牵引方式，将所述目标数据中的待压缩数据进行压缩，使得所述数据发送端将压缩后数据及所述目标数据中的未压缩数据均发送至所述数据接收端。

在步骤200中，所述数据发送端根据所述数据传输指令启动目标数据的发送进程，即为所述数据发送端准备将所述目标数据进行发送，但数据尚处于所述数据发送端内部，并未发送至所述数据接收端时的时间点，所述运营商级通用流量压缩装置中的流量压缩设备应用预设的流量牵引方式，将所述目标数据中的待压缩数据进行压缩，得到压缩后数据，使得所述数据发送端将压缩后数据及所述目标数据中的未压缩数据均发送至所述数据接收端。

可以理解的是，若经判断获知所述目标数据中包含有待压缩数据和无需进行压缩处理的未压缩数据，那么可以在将待压缩数据进行压缩处理，得到压缩后数据的过程中、之前和之后，将所述目标数据中的无需进行压缩处理的未压缩数据独立发送至所述数据接收端，也可以同时将所述压缩后数据及所述目标数据中的未压缩数据一起发送至所述数据接收端。

从上述描述可知，本申请实施例提供的运营商级通用流量压缩方法，能够有效实现针对运营商级的网络流量压缩，并能够在不改变运营商网络中原设备的基础上，针对运营商网络中的数据传输过程中的热点流量进行快速且有效的压缩，实现运营商网络加速，提升业务接入能力，从而提升运营商网络的带宽利用效率。并能够针对不同类型的流量进行不同的处理，结合网络编排，有效推进运营商的SD-WAN建设。

为了进一步区分出不同类型的流量，实现对局部区域热点流量进行压缩，在一种具体实施方式中，本申请实施例的运营商级通用流量压缩方法中的步骤100之前还具体包含有步骤A00，参见图8，所述步骤A00具体包含有如下内容：

步骤A00：应用预设的流量牵引方式在所述目标数据中获取所述待压缩数据。

在步骤A00中，所述编排器向第一流量压缩设备中的第一控制器发送待压缩数据获取指令，所述第一控制器应用预设的流量牵引方式在所述目标数据中获取所述待压缩数据。

可以理解的是，所述第一控制器向所述数据发送端的出口路由器下发策略路由，将符合策略(可以灵活地根据acl规则进行配置)的流量牵引到第一转发器。其中，acl规则是Cisco IOS所提供的一种访问控制技术。所述acl规则使用包过滤技术，在路由器上读取第三层及第四层包头中的信息如源地址、目的地址、源端口、目的端口等，根据预先定义好的规则对包进行过滤，从而达到访问控制的目的。

为了进一步提高运营商网络的数据传输过程中压缩的可靠性，在一种具体实施方式中，本申请实施例的运营商级通用流量压缩方法中的步骤200还具体包含有如下内容，参见图9，所述步骤200具体包含有如下内容：

步骤201：基于预设的压缩协议将经所述压缩标记的所述待压缩数据进行并行压缩，得到压缩后数据，以及，将所述压缩后数据进行压缩标记。

在步骤201中，所述第一流量压缩设备中的多个第一压缩集群基于预设的压缩协议将经所述压缩标记的所述待压缩数据进行并行压缩，得到压缩后数据，以及，将所述压缩后数据进行压缩标记。

可以理解的是，所述预设的压缩协议可以为IP报文压缩协议或快速压缩协议，常用的快速无损压缩协议有snappy，LZO，LZ4等。

步骤202：将经所述压缩标记的压缩后数据转发至所述数据接收端。

在步骤202中，所述第一流量压缩设备中的第一转发器将经所述压缩标记的压缩后数据转发至所述数据接收端中的出口路由器。

为了进一步提高运营商网络的数据传输过程的完整性，在一种具体实施方式中，本申请实施例的运营商级通用流量压缩方法中的步骤200之后还具体包含有步骤300，参见图10，所述步骤300具体包含有如下内容：

步骤300：对所述数据接收端接收到的所述压缩后数据进行解压缩，使得所述数据接收端接收并存储解压缩数据及所述目标数据中的未压缩数据。

在步骤300中，设置在所述数据接收端内的第二流量压缩设备对所述数据接收端接收到的所述压缩后数据进行解压缩，使得所述数据接收端接收并存储解压缩数据及所述目标数据中的未压缩数据。

可以理解的是，所述步骤100中的启动数据接收端的数据解压进程可以与所述步骤300的执行过程相同。

为了进一步区分出不同类型的流量，实现对局部区域热点流量进行解压缩，在一种具体实施方式中，本申请实施例的运营商级通用流量压缩方法中的步骤300之前还具体包含有步骤B00，参见图11，所述步骤B00具体包含有如下内容：

步骤B00：应用预设的流量牵引方式在所述数据接收端接收到的数据中获取待解压缩数据。

在步骤B00中，所述编排器向第二流量压缩设备中的第二控制器发送待解压缩数据获取指令，所述第二控制器应用预设的流量牵引方式在所述数据接收端接收到的数据中获取所述待解压缩数据。

可以理解的是，所述第二控制器向所述数据发送端的入口路由器下发策略路由，将符合策略(可以灵活地根据acl规则进行配置)的流量牵引到第一转发器。

为了进一步提高运营商网络的数据传输过程中解压缩的可靠性，在一种具体实施方式中，本申请实施例的运营商级通用流量压缩方法中的步骤300还具体包含有如下内容，参见图12，所述步骤300具体包含有如下内容：

步骤301：基于预设的压缩协议对所述待解压缩数据进行并行解压缩，得到解压缩数据。

在步骤301中，所述第二流量压缩设备中的多个第二压缩集群基于预设的压缩协议将有所述压缩标记的所述待解压缩数据进行并行解压缩，得到解压缩数据，以及，将所述解压缩数据进行压缩标记。

可以理解的是，所述预设的压缩协议可以为IP报文压缩协议或快速压缩协议，常用的快速无损压缩协议有snappy，LZO，LZ4等。

步骤302：将所述解压缩数据转发至所述数据接收端。

在步骤302中，所述第二流量压缩设备中的第二转发器将所述解压缩数据转发至所述数据发送端中的入口路由器。

为进一步地说明本方案，本申请还提供一种运营商级通用流量压缩方法的具体应用实例，所述运营商级通用流量压缩方法可以针对局部区域热点流量进行压缩，实现网络加速，提升业务接入能力，可以区分出不同类型的流量，例如带宽敏感性和时延敏感性，分别进行不同的处理，结合网络编排，推进运营商的SD-WAN建设。另一方面，运营商之前已经部分部署了DPI设备和流量清洗设备，这些设备通过旁路接入，采用分光或者流量牵引的方式实现引流。借鉴这个思路，我们也可以将特定方向的流量导入到流量压缩设备，进行压缩或还原后导回到原来的目标。参见图6，所述运营商级通用流量压缩方法具体包含有如下内容：

S1：启用压缩的时候，先启用解压侧，避免丢包。

S2：编排器1首先向数据接收端7的第二控制器32下发策略，启用数据接收端7的第二流量牵引设备22进行流量牵引和解压缩。

S3：数据接收端7的第二控制器32向数据接收端7的入口路由器92下发策略路由，将符合策略(可以灵活地根据acl规则进行配置)的流量牵引到第二转发器42。第二转发器42调用第二压缩集群52的解压缩服务，对于标记为压缩的报文，应用预设的压缩协议进行并行解压计算。解压完毕的报文回送到入口路由器92，正常转发到数据接收端7的业务路由器8。没有标记为压缩的报文则直接透传。

S4：编排器1向数据发送端6的第一控制器31下发策略，启用数据发送端6的第一流量牵引设备21进行流量牵引和压缩

S5：数据发送端6的第一控制器31向数据发送端6的出口路由器91下发策略路由，将符合策略(可以灵活地根据acl规则进行配置)的流量牵引到转发器。第一转发器41调用第一压缩集群51的压缩服务，应用预设的压缩协议对报文进行并行压缩计算，设置IP包头的压缩标记。经过压缩的报文回送到出口路由器91，正常转发到下一跳(数据接收端7端的入口路由器92)。不符合策略的报文则直接转发。

S7：停止压缩的时候，顺序相反，先停止数据发送端6的流量牵引和压缩，再停止数据接收端7的流量牵引和压缩。

其中，所述预设的压缩协议的具体实施方式包括如下内容：

(1)IP报文压缩协议

流量压缩的核心是对IP报文进行压缩，同时压缩后的流量要可以在原有的网络上传输。在internet网络中，底层使用的是IP协议，需要在不改动IP协议的前提下，对单个IP报文的载荷进行压缩。为了区分出压缩报文和非压缩报文，需要在IP包头中进行标记。

好在IP协议在定义时，已经考虑到了压缩的需求。在RFC2393(IP PayloadCompression Protocol(IPComp)IP载荷压缩协议)中，规定了用于在INTERNET环境中为ip层提供无损耗压缩的协议。

1-1.协议规定了压缩/解压缩过程如下：

“IP数据报压缩处理过程包含两个阶段：出站IP数据报压缩和入站数据报解压。压缩处理必须是无损耗的，确保IP数据报在压缩和解压缩之后，与原始的IP数据报一致。

每个IP数据报单独地被压缩和解压，与其他数据报没有任何关联(无状态压缩)。因为IP数据报可能无序地到达或者丢失。每个压缩的IP数据报封装单个IP有效载荷。

入站IP数据报的处理必须支持压缩和未压缩IP数据报，以便满足非扩展策略要求，出站IP数据报压缩必须在任何IP安全处理之前进行，例如加密和验证，必须在IP数据报分片之前进行。另外，IPv6中，出站IP数据报压缩必须在Hop-by-Hop选项头或者Routing头添加之前进行。因为它们被数据报传递路径上的各个节点检查和处理，所以必须以原始形式发送。

类似地，入站IP数据报的解压必须在IP数据报重组之后，在所有IP安全处理完成之后进行，例如验证和解密。”

1-2.协议也规定了支持IPCOMP协议的IP包头格式：

“IPv4头字段在传输已压缩的IP数据报之前设置：

TotalLength总长度

整个被封装的IP数据报长度，包括IP头、IPComp头和已压缩的有效载荷。

Protocol协议

设置为108，表示IPComp数据报。[RFC-1700]

HeaderChecksum首部校验和

IP头的内部头校验和。[RFC-0791]

所有其它IPv4头字段保持不变，包括所有头中的选项。”

1-3.IPCOMP部分需要添加特殊的IPCOMP头，用于指示所用的压缩协议等必要信息包括：

“IPComp头结构

4字节的头结构如下：

0123

01234567890123456789012345678901

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

NextHeaderFlagsCompressionParameterIndex

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

NextHeader下一个头

8位选择子。存储原始IP头中的IPv4协议字段或者IPv6NextHeader字段。

Flags标志

8位字段，保留给将来使用。必须设置为0，接收节点必须忽略它。

CompressionParameterIndex(CPI)压缩参数索引

16位索引。按网络字节序存储。0-63定义了有名的压缩算法，这些算法不要求额外信息，用于手工设置。这些值本身与[SECDOI]定义的OMP转换标识符相同。参考[SECDOI]获取一组初始已定义的值，得到如何分配新值的指示。64-255保留给将来使用。256-61439在两个节点之间定义一个IPCA时协商。注重：当协商有名的算法之一时，节点可能选择预定义的0-63之间的值作为CPI。61440-65535主要是互相同意的各方私下使用。两个参与的节点可以选择一个CPI值，彼此独立，两个选择的CPI之间没有关系。出站IPComp头必须使用由解压缩节点选择的CPI值。CPI和目的IP地址一起，唯一地标识数据报压缩算法的特征。”

采用IPCOMP协议，就可以保证压缩后的流量可以正常传输。但是IPCOMP协议并没有规定具体的压缩和解压缩协议。

(2)快速压缩协议

对报文进行压缩必然引入cpu消耗和计算时延，所以在压缩哦算法的选择也并不是压缩率越大越好，而是需要在压缩速度和压缩率之间取一个平衡。

常用的快速无损压缩协议有snappy，LZO，LZ4等。其中LZO的优点是压缩和解压缩比较迅速占用内存小等。Snappy是在谷歌内部生产环境中被许多项目使用的压缩库，Snappy针对64位x86处理器进行了优化，在Intel酷睿i7处理器上，其单核处理数据流的能力达到250M/s-500M/s。LZ4基本是最快的压缩算法，缺点是需要相对较大的内存。参见图13，可以看到，LZ4的解压速度是最快的，几乎可以达到线速的一半，压缩速率也是最快的。由于相对而言，内存的获取较为便宜，而速度是首要因素。因此我们选择LZ4协议作为压缩和解压缩的首要算法，并且可以通过策略控制压缩比。使用默认模式，在多核+万兆网卡环境下可以获得超过3gbps的压缩速率，配合多机集群，基本可以满足线速压缩的需求。解压性能更不成问题。

根据性能需求，压缩器和解压缩器可以部署为单机，也可以部署为转发器+压缩服务集群的模式，以提升并行处理能力。同时，也可以根据编排器下发的策略，使用不同的压缩算法和压缩比，以适应不同的业务场景。

其中，所述流量牵引的具体实施方式包括如下内容：

可以理解的是，流量牵引主要基于路由器的策略路由，最初是为了防御大规模分布式拒绝服务DDOS(Distributed Denial of Service)攻击和避免单点故障问题而提出的，主要思想是将攻击流量和正常流量进行分离，主要用于抵抗DDOS攻击和流量清洗等安全领域。

因此，本申请借用了流量牵引的思路，将需要压缩的流量牵引到流量压缩设备，进行压缩后再回送到原路由器。压缩的过程和流量清洗基本是一样的。

不同的是，由于压缩和解压缩必须是对应的，所以在数据接收端，也需要部署流量牵引，将压缩后的流量牵引到解压缩设备(解压缩的速率比压缩快，所以需要的主机数可以较少，避免单点故障即可)，解压缩后再导回原路由器。在实际的IP网络中，由于流量是双向的，所以压缩集群需要同时支持压缩和解压缩的能力。

为了实现流量牵引，路由器必须支持比较灵活的策略路由和流量标记。在入端，可以根据流量的来源\目的\服务质量QOS(Quality of Service)等级等标记出需要牵引的流量，在出端，由于网络拓扑的复杂，最好是能根据标记识别出需要牵引的流量。如果是虚拟宽带接入服务器vBAS(Virtual Band Access Serve)等网络功能虚拟化NFV(NetworkFunction Virtualization)设备，直接根据IP包头的协议protocol进行识别就可以了，如果是普通的路由器，则可能需要通过特殊的TOS等级进行标记。

其中，所述编排和控制的具体实施方式包括如下内容：

SDN架构SDN是一种数据控制分离、软件可编程的新型网络体系架构，SDN(Software Defined Network)的主要思路就是转发和控制分离。

控制器的主要作用是接受编排器下发的策略，并且触发路由器执行相应的流量牵引的动作。控制器的北向接口以REST服务的形式提供，南向接口可以支持命令行\netconf\RestAPI等形式。

编排器是SDN的大脑和核心。在流量压缩过程中，编排器的角色也是很重要的，它需要协调控制器的动作顺序，根据统统的业务场景，下发不同的流量识别策略，下发不同的压缩策略等。

对于时延敏感类业务，例如视频会议等，可以不进行压缩，对于网页浏览等带宽敏感类业务，可以采用较高的压缩比，对于一般的流量，可以使用默认的快速压缩模式。总体的带宽压缩比可以达到60～70％。

从上述描述可知，本申请应用实例提供的运营商级通用流量压缩方法，可以实现通用的IP流量压缩，不依赖具体应用。节约带宽资源。利用流量牵引原理，不需要专门的企业网关等硬件设备，也不改变用户原有的组网方式，不需要串接到网络中，对原有网络影响最小。一旦流量压缩控制设备发生故障，相当于旁路，原有网络通信不受影响。使用NFV通用硬件，硬件成本和部署成本低，符合SDN演进思路。可以利用原有的流量清洗设备，通过软件升级的方式支持流量压缩功能。可以针对特定流量进行压缩，从而可以提供不同等级的SLA。使用可定义的高速流压缩算法，实现高性能的线速压缩和解压。对流量的压缩策略可以通过编排器统一控制，推动SD-WAN业务建设。根据设备的处理性能，可以针对部分流量进行压缩处理，其余部分不做牵引或者牵引后透传，灵活适应不同的处理规模。

为了有效实现针对运营商级的网络流量压缩，并能够在不改变运营商网络中原设备的基础上，针对运营商网络中的数据传输过程中的热点流量进行快速且有效的压缩，本申请实施例提供一种能够实现所述运营商级通用流量压缩方法中全部内容的运营商级通用流量压缩装置的具体实施方式，参见图6，所述运营商级通用流量压缩装置具体包括如下内容：

编排器1，用于根据针对运营商网络的数据传输指令，启动数据接收端7的数据解压进程，其中，所述数据传输指令中包含有数据发送端6和所述数据接收端7；

第一流量压缩设备21，设置在所述数据发送端6，用于在所述数据发送端6根据所述数据传输指令启动目标数据的发送进程时，应用预设的流量牵引方式，将所述目标数据中的待压缩数据进行压缩，使得所述数据发送端6将压缩后数据及所述目标数据中的未压缩数据均发送至所述数据接收端7。

第二流量压缩设备22，设置在所述数据接收端7，用于对所述数据接收端7接收到的所述压缩后数据进行解压缩，使得所述数据接收端7接收并存储解压缩数据及所述目标数据中的未压缩数据。

其中，所述第一流量压缩设备21中包括：

第一控制器31，用于应用预设的流量牵引方式在所述目标数据中获取所述待压缩数据。

第一压缩集群51，用于基于预设的压缩协议将经所述压缩标记的所述待压缩数据进行并行压缩，得到压缩后数据，以及，将所述压缩后数据进行压缩标记；

第一转发器41，用于将经所述压缩标记的压缩后数据转发至所述数据接收端7。

其中，所述第二流量压缩设备22中包括：

第二控制器32，用于应用预设的流量牵引方式在所述数据接收端7接收到的数据中获取待解压缩数据。

第二压缩集群52，用于基于预设的压缩协议对所述待解压缩数据进行并行解压缩，得到解压缩数据；

第二转发器42，用于将所述解压缩数据转发至所述数据接收端7。

本申请提供的运营商级通用流量压缩装置的实施例具体可以用于执行上述实施例中的运营商级通用流量压缩方法的实施例的处理流程，其功能在此不再赘述，可以参照上述方法实施例的详细描述。

从上述描述可知，本申请实施例提供的运营商级通用流量压缩装置，能够有效实现针对运营商级的网络流量压缩，并能够在不改变运营商网络中原设备的基础上，针对运营商网络中的数据传输过程中的热点流量进行快速且有效的压缩，实现运营商网络加速，提升业务接入能力，从而提升运营商网络的带宽利用效率。并能够针对不同类型的流量进行不同的处理，结合网络编排，有效推进运营商的SD-WAN建设。

本申请的实施例还提供能够实现上述实施例中的运营商级通用流量压缩方法中全部步骤的一种电子设备的具体实施方式，参见图14，所述电子设备具体包括如下内容：

处理器(processor)601、存储器(memory)602、通信接口(CommunicationsInterface)603和总线604；

其中，所述处理器601、存储器602、通信接口603通过所述总线604完成相互间的通信；所述通信接口603用于实现运营商级通用流量压缩装置及所述运营商网络中各个节点(即数据接收端和数据发送端)之间的信息传输；

所述处理器601用于调用所述存储器602中的计算机程序，所述处理器执行所述计算机程序时实现上述实施例中的运营商级通用流量压缩方法中的全部步骤，例如，所述处理器执行所述计算机程序时实现下述步骤：

步骤100：根据针对运营商网络的数据传输指令，启动数据接收端的数据解压进程，其中，所述数据传输指令中包含有数据发送端和所述数据接收端。

步骤200：在所述数据发送端根据所述数据传输指令启动目标数据的发送进程时，应用预设的流量牵引方式，将所述目标数据中的待压缩数据进行压缩，使得所述数据发送端将压缩后数据及所述目标数据中的未压缩数据均发送至所述数据接收端。

从上述描述可知，本申请实施例提供的电子设备，能够有效实现针对运营商级的网络流量压缩，并能够在不改变运营商网络中原设备的基础上，针对运营商网络中的数据传输过程中的热点流量进行快速且有效的压缩，实现运营商网络加速，提升业务接入能力，从而提升运营商网络的带宽利用效率。并能够针对不同类型的流量进行不同的处理，结合网络编排，有效推进运营商的SD-WAN建设。

本申请的实施例还提供能够实现上述实施例中的运营商级通用流量压缩方法中全部步骤的一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述实施例中的运营商级通用流量压缩方法的全部步骤，例如，所述处理器执行所述计算机程序时实现下述步骤：

步骤100：根据针对运营商网络的数据传输指令，启动数据接收端的数据解压进程，其中，所述数据传输指令中包含有数据发送端和所述数据接收端。

步骤200：在所述数据发送端根据所述数据传输指令启动目标数据的发送进程时，应用预设的流量牵引方式，将所述目标数据中的待压缩数据进行压缩，使得所述数据发送端将压缩后数据及所述目标数据中的未压缩数据均发送至所述数据接收端。

从上述描述可知，本申请实施例提供的计算机可读存储介质，能够有效实现针对运营商级的网络流量压缩，并能够在不改变运营商网络中原设备的基础上，针对运营商网络中的数据传输过程中的热点流量进行快速且有效的压缩，实现运营商网络加速，提升业务接入能力，从而提升运营商网络的带宽利用效率。并能够针对不同类型的流量进行不同的处理，结合网络编排，有效推进运营商的SD-WAN建设。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于硬件+程序类实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

上述对本说明书特定实施例进行了描述。其它实施例在所附权利要求书的范围内。在一些情况下，在权利要求书中记载的动作或步骤可以按照不同于实施例中的顺序来执行并且仍然可以实现期望的结果。另外，在附图中描绘的过程不一定要求示出的特定顺序或者连续顺序才能实现期望的结果。在某些实施方式中，多任务处理和并行处理也是可以的或者可能是有利的。

虽然本申请提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的装置或客户端产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。

上述实施例阐明的系统、装置、模块或单元，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。一种典型的实现设备为计算机。具体的，计算机例如可以为个人计算机、膝上型计算机、车载人机交互设备、蜂窝电话、相机电话、智能电话、个人数字助理、媒体播放器、导航设备、电子邮件设备、游戏控制台、平板计算机、可穿戴设备或者这些设备中的任何设备的组合。

虽然本说明书实施例提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的手段可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的装置或终端产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境，甚至为分布式数据处理环境)。术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、产品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、产品或者设备所固有的要素。在没有更多限制的情况下，并不排除在包括所述要素的过程、方法、产品或者设备中还存在另外的相同或等同要素。

为了描述的方便，描述以上装置时以功能分为各种模块分别描述。当然，在实施本说明书实施例时可以把各模块的功能在同一个或多个软件和/或硬件中实现，也可以将实现同一功能的模块由多个子模块或子单元的组合实现等。以上所描述的装置实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。

本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内部包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

本申请是参照根据本申请实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

本领域技术人员应明白，本说明书的实施例可提供为方法、系统或计算机程序产品。因此，本说明书实施例可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本说明书实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本说明书实施例可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本说明书实施例，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本说明书实施例的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

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

Claims (10)

1.一种运营商级通用流量压缩方法，其特征在于，包括：

根据针对运营商网络的数据传输指令，启动数据接收端的数据解压进程，其中，所述数据传输指令中包含有数据发送端和所述数据接收端；

在所述数据发送端根据所述数据传输指令启动目标数据的发送进程时，应用预设的流量牵引方式，将所述目标数据中的待压缩数据进行压缩，使得所述数据发送端将压缩后数据及所述目标数据中的未压缩数据均发送至所述数据接收端。

2.根据权利要求1所述的运营商级通用流量压缩方法，其特征在于，在所述将所述目标数据中的待压缩数据进行压缩之前，还包括：

应用预设的流量牵引方式在所述目标数据中获取所述待压缩数据。

3.根据权利要求1所述的运营商级通用流量压缩方法，其特征在于，所述将所述目标数据中的待压缩数据进行压缩，包括：

基于预设的压缩协议将经所述压缩标记的所述待压缩数据进行并行压缩，得到压缩后数据，以及，将所述压缩后数据进行压缩标记；

以及，将经所述压缩标记的压缩后数据转发至所述数据接收端。

4.根据权利要求1所述的运营商级通用流量压缩方法，其特征在于，还包括：

对所述数据接收端接收到的所述压缩后数据进行解压缩，使得所述数据接收端接收并存储解压缩数据及所述目标数据中的未压缩数据。

5.根据权利要求4所述的运营商级通用流量压缩方法，其特征在于，在所述对所述数据接收端接收到的所述压缩后数据进行解压缩之前，还包括：

应用预设的流量牵引方式在所述数据接收端接收到的数据中获取待解压缩数据。

6.根据权利要求5所述的运营商级通用流量压缩方法，其特征在于，所述对所述数据接收端接收到的所述压缩后数据进行解压缩，包括：

基于预设的压缩协议对所述待解压缩数据进行并行解压缩，得到解压缩数据；

以及，将所述解压缩数据转发至所述数据接收端。

7.一种运营商级通用流量压缩装置，其特征在于，包括：

编排器，用于根据针对运营商网络的数据传输指令，启动数据接收端的数据解压进程，其中，所述数据传输指令中包含有数据发送端和所述数据接收端；

第一流量压缩设备，设置在所述数据发送端，用于在所述数据发送端根据所述数据传输指令启动目标数据的发送进程时，应用预设的流量牵引方式，将所述目标数据中的待压缩数据进行压缩，使得所述数据发送端将压缩后数据及所述目标数据中的未压缩数据均发送至所述数据接收端。

8.根据权利要求7所述的运营商级通用流量压缩装置，其特征在于，所述第一流量压缩设备中包括：

第一控制器，用于应用预设的流量牵引方式在所述目标数据中获取所述待压缩数据。

9.一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现权利要求1至6任一项所述的运营商级通用流量压缩方法的步骤。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该计算机程序被处理器执行时实现权利要求1至6任一项所述的运营商级通用流量压缩方法的步骤。