SDN网络中网络编码进行组播传输的方法与流程

本发明涉及计算机网络技术领域，具体涉及一种sdn网络中网络编码组播的传播方法。

背景技术：

sdn是一种新型的网络体系架构，其核心技术openflow协议把网络设备的数、控层相分离，控制层提供业务实现和逻辑控制，数据层执行数据转发，从而实现对网络的灵活控制和智能管理，方便拓展。

网络编码是网络中信息的处理和传输上的重大突破，它允许网络中间节点对所传输的信息进行编码处理，并在接收节点进行解码还原，提高了网络吞吐量、数据传输的可靠性和安全性。

若将网络编码应用于sdn网络中，结合两者的优势，对未来网络发展有着重要的研究价值。但鉴于sdn网络数、控分离的特性，几乎所有的业务逻辑扩展都集中在控制层，而网络编码的基本思想又要求底层的中间节点设备参与数据的编、解码过程，这种矛盾性造成了sdn和网络编码的结合研究很少，几乎找不到一套完整的实现方案。为了解决上述技术问题，目前亟需一种sdn网络中的网络编码进行组播传输的方法。

技术实现要素：

本发明的主要目的在于提供一种sdn网络中网络编码进行组播传输的方法，以解决现有技术中网络编码应用与sdn网络无法有机结合的问题。

为了实现上述目的，本发明提供了一种sdn网络中网络编码进行组播传输的方法：

sdn网络中网络编码进行组播传输的方法，本发明的步骤如下:

a、控制器构建全局拓扑信息；

b、组播接收端成员入组；

c、组播发送端发送组播流；

d、控制器计算路由路径、下发流表项；

e、openvswitch交换机源发送节点初次编码原始组播数据；

f、openvswitch交换机中间编码节点再次编码中间数据；

g、openvswitch交换机目的解码节点解码还原数据；

其中，所述openvswitch交换机具有支持网络编码的openflow协议，所述控制器为支持openflow协议的控制器，所述openvswitch交换机为支持所述openflow协议并且可编码、解码的交换机。sdn网络其核心技术openflow协议把网络设备的数、控层相分离，控制层提供业务实现和逻辑控制，数据层执行数据转发，从而实现对网络的灵活控制和智能管理，方便拓展。网络编码是网络中信息的处理和传输上的重大突破，它允许网络中间节点对所传输的信息进行编码处理，并在接收节点进行解码还原，提高了网络吞吐量、数据传输的可靠性和安全性。本发明有效地将网络编码应用于sdn网络中，克服了现有技术中无法将网络编码应用与sdn网络有机结合的问题，结合上述两者的优势，对未来网络发展有着重要的研究价值。

进一步地，所述openflow协议中设有支持网络编码的ncaction，该ncaction可以和其他action组合成一个行动集，装载到所述流表项中，每次匹配到该流表项时，都执行该行动集。

进一步地，控制器提供可以使用的ncaction对象

进一步地，openvswitch交换机具有ncaction并且具有可编码、解码的模块，所述ncaction由控制器主动发往所述openvswitch交换机，包含在下发流表项的指令集中，当数据包匹配到该流表项时，便执行对应的网络编码、解码动作。

进一步地，所述openvswitch交换机在进行编码、解码过程中，采用统一的数据模型，所述数据模型包括节点名、编码id标号、数据包缓存队列和待处理数据包缓存队列。

进一步地，所述openvswitch交换机在进行编码、解码过程中，采用自定义数据包格式来统一组织数据，自定义数据包格式包括编码id标号、包号、已编码数据长度、随机系数列表和已编码的有效数据。

进一步地，控制器计算路由路径、下发流表项的步骤为：

a、开始；

b、组播源发送组播流；

c、判断packetin消息类型，若消息类型为udp组播，则判断目的组播组是否存在，若目的组播组存在，则根据拓扑、组成员信息计算最大流，获取路由路径，根据路由路径确定每个节点的节点类型，将生成ncaction和流表下发到对应的openvswitch交换机上，之后结束，若目的组播组不存在则直接结束；若消息类型为非udp组播则直接结束。

进一步地，所述ncaction的字段属性包括交换机的中间节点设备类型以及当前网络拓扑下组播源到组播目的节点集的网络最大流。

进一步地，中间节点设备的类型包括源发送端编码节点、中间发送端编码节点、普通的中间转发节点、接收端解码节点、不在组播路由路径中且不参与数据传输的节点。

进一步地，有两个前置条件，第一前置条件为测试用组播均为单源多目的组播，第二前置条件为拓扑中的每条链路其流量均相等，都设为1个单位。

其中在所述openflow协议中设定action时，在控制器中定义常量，在控制器中定义action的实现类。所述控制器包括主机管理模块、拓扑管理模块、组播管理模块、路由管理模块，上述各模块的工作模式为消息驱动模式。

所述控制器构建全局拓扑信息的步骤如下：

a、开始；

b、创建交换机表、链路表；

c、判断接收消息的类型；

d、若接收到的消息为eventswitchenter消息，则将该交换机信息保存入交换机表；

e、若接收到的消息为eventlinkadd消息，则记录链路两端的交换机id、端口号，之后构件链路信息至链路表；由此将表构建完毕；

f、读取外部配置文件，更新上述构件完毕的表中的配置信息；

g、发送拓扑初始化完成消息，附加拓扑数据。

进一步地，所述组播接收端成员入组步骤如下：

a、开始；

b、组播接收端请求入组；

c、收到packetin消息；

d、调用组播管理的处理接口；

e、判断请求的组播组是否存在，若组播组不存在则创建组播组之后组成员入组；若组播组存在则直接组成员入组；

f、生成请求入组应答并回复；

g、发送组成员更改消息，更新组成员信息。

可见，本发明与现有技术相比，本发明有效地将网络编码应用于sdn网络中，克服了现有技术中无法将网络编码应用与sdn网络有机结合的问题，结合上述两者的优势，对未来网络发展有着重要的研究价值。

附图说明

构成本发明的一部分的附图用来辅助对本发明的理解，附图中所提供的内容及其在本发明中有关的说明可用于解释本发明，但不构成对本发明的不当限定。在附图中：

图1为ryu控制器构建全局拓扑信息的流程图。

图2为所述组播接收端成员入组的流程图。

图3为ryu控制器计算路由路径、下发流表项的流程图。

图4为数据包在openvswitch的用户态进程中的处理流程图。

图5为数据包格式示意图。

图6为交换机节点的结构模型示意图。

图7为源发送节点编码流程图。

图8为中间编码节点编码流程图。

具体实施方式

下面结合附图对本发明进行清楚、完整的说明。本领域普通技术人员在基于这些说明的情况下将能够实现本发明。在结合附图对本发明进行说明前，需要特别指出的是：

(1)本发明中在包括下述说明在内的各部分中所提供的技术方案和技术特征，在不冲突的情况下，这些技术方案和技术特征可以相互组合。

(2)下述说明中涉及到的本发明的实施例通常仅是本发明一分部的实施例，而不是全部的实施例。因此，基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都应当属于本发明保护的范围。

(3)关于对本发明中术语的说明。本发明的说明书和权利要求书及有关的部分中的术语“第一”、“第二”等是用于区别容易引起混同的对象，而不必用于描述特定的顺序或先后次序。此外，术语“包括”和“具有”以及它们的任何变形，意图在于覆盖不排他的包含。其中术语“sdn”是指软件定义网络；术语“openvswitch交换机”是指开放虚拟交换标准交换机；术语openflow协议是指用来描述控制器和交换机之间交互所用信息的标准，以及控制器和交换机的接口标准，协议的核心部分是用于openflow协议信息结构的集合；术语“igmp”是指internet组管理协议,提供internet网际多点传送的功能,即将一个ip包拷贝给多个host,windows系列采用了这个协议；术语“udp”是指用户数据报协议；术语“ryu控制器”是日本ntt公司研发的一款开源sdn控制器。

本发明sdn网络中网络编码进行组播传输的方法，其步骤如下:

a、控制器构建全局网络拓扑信息；

b、组播接收端成员入组；

c、组播发送端发送组播流；

d、控制器计算路由路径、下发流表项；

e、openvswitch交换机源发送节点初次编码原始组播数据；

f、openvswitch交换机中间编码节点再次编码中间数据；

g、openvswitch交换机目的解码节点解码还原数据；

其中，所述openvswitch交换机具有支持网络编码的openflow协议，所述控制器为支持openflow协议的控制器，所述openvswitch交换机为支持所述openflow协议并且可编码、解码的交换机。

所述openflow协议中设有支持网络编码的ncaction，该ncaction可以和其他action组合成一个行动集，装载到所述流表项中，每次匹配到该流表项时，都执行该行动集。

控制器提供可以使用的ncaction对象。

openvswitch交换机具有ncaction并且具有可编码、解码的模块，所述ncaction由控制器主动发往所述openvswitch交换机，包含在下发流表项的指令集中，当数据包匹配到该流表项时，便执行对应的网络编码、解码动作。

所述openvswitch交换机在进行编码、解码过程中，采用统一的数据模型，所述数据模型包括节点名、编码id标号、数据包缓存队列和待处理数据包缓存队列。

所述openvswitch交换机在进行编码、解码过程中，采用自定义数据包格式来统一组织数据，自定义数据包格式包括编码id标号、包号、已编码数据长度、随机系数列表和已编码的有效数据。

控制器计算路由路径、下发流表项的步骤为：

a、开始；

b、组播源发送组播流；

c、判断packetin消息类型，若消息类型为udp组播，则判断目的组播组是否存在，若目的组播组存在，则根据拓扑、组成员信息计算最大流，获取路由路径，根据路由路径确定每个节点的节点类型，将生成ncaction和流表下发到对应的openvswitch交换机上，之后结束，若目的组播组不存在则直接结束；若消息类型为非udp组播则直接结束。

所述ncaction的字段属性包括交换机的中间节点设备类型以及当前网络拓扑下组播源到组播目的节点集的网络最大流。

中间节点设备的类型包括源发送端编码节点、中间发送端编码节点、普通的中间转发节点、接收端解码节点、不在组播路由路径中且不参与数据传输的节点。

测试用所述组播均为单源多目的组播，拓扑中的每条链路其流量均相等，都设为1个单位。

在本实施例中openflow协议中的ncaction”即为networkcodingaction，从属于controller-to-switch消息类型，由控制器主动发往交换机，包含在下发流表项的指令集中，当数据包匹配到该流表项时，便执行对应的网络编码、解码动作。本实施例中的控制器采用ryu控制器，所述ryu控制器为日本ntt公司研发的一款开源sdn控制器。

上述ncaction中带有2个字段属性：nc_type和nc_max_flow，具体如下：

(1)nc_type：表明接收该ncaction的交换机在整个组播路由路径中是哪种类型的中间节点设备，该路径不是传统的组播树路由路径，而是使用网络编码传输的路由路径。共有5种类型：

1)nc_src_encode：源发送端编码节点，即与组播源直接相连的交换机，对组播流原始数据进行编码操作，将编码后的数据打包发送到指定出口。

2)nc_middle_encode：中间发送端编码节点，按一定的策略对接收的数据包再次进行编码操作，将编码后的数据发送到指定出口。

3)nc_middle_dispatch：普通的中间转发节点，既不编码、也不解码，仅按照流表规则转发数据包。

4)nc_end_decode：接收端解码节点，即与组播接收端直接相连的交换机，按一定策略对接收到的编码后数据包进行联合解码，还原出组播流原始数据，再发送给指定的接收端。

5)nc_useless：不在组播路由路径中且不参与数据传输的节点，表明该交换机不在组播路由路径中，不参与数据传输。

(2)nc_max_flow：表示当前网络拓扑下，组播源到组播目的节点集的网络最大流。为了简化实现，有两个前置条件，一是测试用组播均为单源多目的组播，二是拓扑中的每条链路其流量均相等，都设为1个单位。通过edmonds-karp算法来计算最大流，同时得到组播信源到信宿集的增广路径集，该增广路径集即为整个组播的路由路径。最大流涉及到网络编码、解码的方方面面，如解码时，最大流的值即为一次解码过程所需的数据包个数。关于nc_max_flow，后面有相应的说明。

上述ncaction可以和其他action组合成一个行动集，装载到一个流表项中，每次匹配到该流表项时，都执行该行动集。行动集中ncaction的执行顺序为：outputaction之前，其他所有action之后。

图3为ryu控制器计算路由路径、下发流表项的流程图。如图3所示，ryu控制器计算路由路径、下发流表项的步骤为：

a、开始；

b、组播源发送组播流；

c、判断packetin消息类型，若消息类型为udp组播，则判断目的组播组是否存在，若目的组播组存在，则根据拓扑、组成员信息计算最大流，获取路由路径，根据路由路径确定每个节点的节点类型，生成action和流表，下发到对应的交换机上，之后结束，若目的组播组不存在则直接结束；若消息类型为非udp组播则直接结束。

在所述openflow协议中设定action时，在ryu控制器中定义常量，在ryu控制器中定义action的实现类。

所述ryu控制器包括主机管理模块、拓扑管理模块、组播管理模块、路由管理模块，上述各模块的工作模式为消息驱动模式。

本实例中采用了python编写的ryu控制器，为了实现网络编码组播传输，在控制层的管理调度上拓展了多个业务模块：

主机管理模块：管理、监控网络中的主机，记录下各主机的ip、mac等信息，对其他模块提供数据。

拓扑管理模块：管理、监控网络中的交换机、链路、端口等，记录下各交换机id、链路、邻接端口号等信息，组成一张全局拓扑图，给其他模块提供数据。

组播管理模块：基于igmp协议，管理网络中的组播组，包括添加组播组、添加组成员、删除组成员、轮询组成员等，维护一张组成员表，记录与组成员直连交换机的id、端口号等信息。

路由管理模块：根据全局拓扑信息和组成员信息，计算组播信源到信宿集的路由路径、网络最大流，生成含有ncaction的流表项，下发流表到各交换机上。

上述各模块的工作模式为消息驱动，是一个异步过程，即接收到交换机发来的消息、或接收到ryu控制器内部其他模块发来的消息才进行相应的业务处理。

挑选其中最主要的3个业务过程做详细说明：初始化时全局拓扑信息的构建、组播组成员的添加、路由路径的计算及流表的生成和下发。

图1为ryu控制器构建全局拓扑信息的流程图。如图1所示，所述ryu控制器构建全局拓扑信息的步骤如下：

a、开始；

b、创建交换机表、链路表；

c、判断接收消息的类型；

d、若接收到的消息为eventswitchenter消息，则将该交换机信息保存入交换机表；

e、若接收到的消息为eventlinkadd消息，则记录链路两端的交换机id、端口号，之后构件链路信息至链路表；由此将表构建完毕；

f、读取外部配置文件，更新上述构件完毕的表中的配置信息；

g、发送拓扑初始化完成消息，附加拓扑数据。

图2为所述组播接收端成员入组的流程图。如图2所示，所述组播接收端成员入组步骤如下：

a、开始；

b、组播接收端请求入组；

c、收到packetin消息；

d、调用组播管理的处理接口；

e、判断请求的组播组是否存在，若组播组不存在则创建组播组之后组成员入组；若组播组存在则直接组成员入组；

f、生成请求入组应答并回复；

g、发送组成员更改消息，更新组成员信息。

现有技术中的openflow原始协议中没有ncaction，ryu系统组件中不存在该action类，本发明通过自行扩张实现了在openflow原始协议设置ncaction，想要实现，必须自行扩展。自行扩展方法如下：

(1)在ryu目录中的ofproto/ofproto_v1_3.py文件中定义2个常量：

1)ofpat_nc＝28，该常量代表ncaction的枚举标识，必须与openvswitch中定义的ncaction标识相等。

2)ofp_action_nc_size＝16，该常量表示ncaction的数据长度(字节为单位)。

(2)在ryu目录中的ofproto/ofproto_v1_3_parser.py文件中定义ncaction的实现类：

1)该类必须继承自ryu提供的openflow中所有action的基类”ofpaction”，示例如下：

classofpactionnc(ofpaction)

2)该类必须用ryu指定的装饰器结合步骤1中定义的常量进行修饰，示例如下：

@ofpaction.register_action_type(ofpat_nc,ofp_action_nc_size)

classofpactionnc(ofpaction)

3)该类必须实现3个接口：

__init__()：用于初始化

parser()：用于从数据流中解析出ncaction

serialize()：用于把ncaction打包到数据流中

以下对openvswitch交换机作进一步说明：

本实例中所使用的不仅在openvswitch源码上扩展了新的ncaction，还扩展了网络编码的编码、解码功能。网络编码采用随机网络编码，随机系数的取值范围为8位有限域(0～255)，其解码成功率在97％左右。在openvswitch中扩展新的action比较繁琐，以下是主要步骤：

在openvswitch目录中的include/openflow/openflow-1.3.h文件中，找到openflow-1.3

协议的action枚举定义，添加ncaction的枚举定义值，注，该值必须与ryu控制器中定义的ncaction枚举标识一致

在include/openflow/openflow-1.3.h文件中，添加ncaction对应的结构体定义，说明ncaction包含的字段属性。

在lib/ofp-util.def文件中，在”#ifndefofpat11_action”区域中，添加ncaction对应的宏定义。

在lib/ofp-actions.c文件中，在”unionofp_action”定义中，声明ncaction对应的结构体变量(即2中定义的结构体)。

在lib/ofp-actions.h文件中，添加ncaction对应的抽象action宏定义。

在lib/ofp-actions.h文件中，添加ncaction对应的抽象action结构体定义。

在lib/ofp-actions.c文件中，在接口”ofpact_from_openflow11()”中，添加ncaction对应的case分支，生成其对应的抽象action。

在lib/ofp-actions.c文件中，在接口”ovs_instruction_type_from_ofpact_type()”和接口”ofpact_check__()”中，添加ncaction对应的case分支，返回检测结果为真。

在lib/ofp-actions.c文件中，在接口”ofpact_is_allowed_in_actions_set()”中，添加ncaction对应的case分支，表明ncaction支持填充到行动集中。

在lib/ofp-actions.c文件中，在接口”ofpacts_execute_action_set()”中，添加ncaction对应的语句，指定ncaction在行动集中的执行顺序。

在ofproto/ofproto-dpif-xlate.c文件中，在接口”do_xlate_actions()”中，添加ncaction对应的case分支，执行相应的操作。

本实施例中数据包格式如下：

在目的节点对数据进行解码还原前，数据在各节点间的中转均按照一定格式打包、解包，以保证编、解码的一致性。由于组播数据流均为udp数据包，这里所说的数据包格式指的是udp层上的数据格式，并不包含udp的底4层。图5是数据包格式示意图，如图5所示所述数据包包括：

encode_id：编、解码过程id标识，4字节长，只有相同encode_id的数据包才能执行对应的编码、解码操作，从信源至所有信宿节点，原始组播数据完成1次整体性的编码、解码操作，encode_id自增1。所有中间节点上的encode_id初始均为0。

pkt_id：数据包唯一id标识，4个字节长，每生成1个数据包，pkt_id自增1，pkt_id初始值为0。

encoded_data_len：已编码数据的长度，2个字节长，表示后面”encodeddata”的大小。

coeffs_list：随机系数列表，表示当前节点编码时选取的随机系数，每个随机系数均是1字节无符号数，取值范围为0～255，网络最大流为多少单位，就有多少个随机系数，所以该字段的长度为最大流的值。

encodeddata：已编码的有效数据，长度为”encoded_data_len”。

本发明编码、解码过程的实现过程如下：

openvswitch分为用户态和内核态程序，通过两部分的协作实现高效虚拟交换功能。用户态程序是一个进程，运行在user-space；内核态程序是一个内核模块，运行在kernel-space。为了简化实现和保证稳定性，编、解码功能添加到用户态源码中。

编、解码带来的问题和解决方法如下：

在openvswitch用户态源码中添加编、解码功能时，有3个问题：

1)openflow原始协议中的action几乎不会对数据包中的有效数据(网络层或传输层上的负载数据)做更改，一般仅更新流表或转发数据包，这造成了openvswitch在执行action时并不把原始数据包传递过去，而是仅作状态的更新。

2)若数据包被传递到openvswitch的用户态进程处理，在执行完相应的action后，它会把缺失的流表项安装到内核态模块中，下次再匹配到相似流表项的数据包便会在openvswitch的内核模块中被处理，不会上传到用户态进程中。

3)若某个流表项的行动集中含有多个outputaction，即匹配到该流表项的数据包会从交换机的多个端口转发出去，但随机网络编码的源发送端编码节点在对原始数据进行编码后，需要把不同编码层次的数据包从不同端口转发出去，而不是行动集中的每个端口都转发一次。

图4为数据包在openvswitch的用户态进程中的处理流程图。如图4所示，下面对数据包在openvswitch的用户态进程中的处理过程做一个简要说明：

开始；

读取内核模块发来的数据包；

如果读取不成功重新读取；

如果读取成功从数据包中依次提取未知流表项；

与用户态中已经存在的流表进行对比；

判断是否匹配，如果匹配执行对应的action；如果不匹配，将不匹配的流表项添加到用户态流表中，执行新增流表项对应的action更新流表，把新增流表项安装到内核模块中；

判断是否有outputaction，若有，则数据包再同一转发回内核模块中，之后结束；如果没有，直接结束。

根据上述的数据包处理过程和3个问题，提出了以下解决方法：

1)匹配流表项时，有一个“structxlate_out”类型的传出参数，叫作“xout”，在该参数中添加ncaction的2个字段：nc_type和nc_max_flow。在匹配到或检查到含有ncaction的流表项时，再执行该action时，把ncaction的nc_type和nc_max_flow通过”xout”传出去，在数据包统一转发回内核模块前进行编码、或解码操作即可。

2)在上述的”xout”传出参数中设置一个标志，名为”boolhas_nc”，表示该条流表项是否含有ncaction。执行action时，若匹配到含有ncaction的流表项，该标志”has_nc”置true。新增流表项安装到内核模块前，先检查该标志”has_nc”，为true则不用安装，否则要安装。

3)对源发送端编码节点的outputaction做特殊处理，一个outputaction只能转发一种编码层次的数据包，即一个端口转发一种编码层次的数据包，下一种不同编码层次的数据包需要从另一个不同的端口转发出去。所谓源编码节点的编码层次，与随机网络编码的理论含义挂钩，等于网络最大流。假如最大流为2个单位，则编码层次为2，表示源编码节点需要对同一份原始数据进行2次编码，这2次编码中采用的随机系数不一样，编码后的数据包也需要从2个不同的端口转发出去。但2次编码使用的”encode_id”相同，同属于一次大的、完整性的编、解码操作。

编、解码交换机节点的内部模型

对于要执行编、解码操作的交换机节点，根据外部ncaction传来的”nc_type”决定是何种编码、解码操作类型，但其内部有一个统一的结构模型，如图6所示：

bridge_name：该交换机节点的名称。

encode_id：每个交换机节点都配有一个encode_id计数器，初始为0，每完成一次整体

性的编码、解码操作，该encode_id自增1。换句话说，该交换机节点内部的数据包，只有与该encode_id相匹配者，才能被编码、或者解码。

pkt_list：该交换机内部的数据包缓存队列，缓存接收到的所有符合条件的数据包。

todo_pkt_list：在一次完整性的编码或解码操作中，缓存将要被编码、或将要被解码的数据包。编、解码完成后，立刻清空该队列，为下一次编、解码做准备。

队列中的数据包模型：

encode_id和pkt_id：

data：有效数据。

data_len：有效数据长度。

如图7为源发送节点编码流程图。其步骤如下：

开始

初始化交换机节点

判断编码层次是否大于最大流，若大于，则更新encode_id，之后结束；若不大于则继续往下进行；

生成编码随机系数；

提取原始数据包udp层上的有效数据；

利用有限域加法、乘法进行编码；

编码后数据重新打包；

新数据包的ip报头、udp报头更新；

执行对应的outputaction；

编码层次+1后返回再次判断编码层次是否大于最大流。

如图8为中间编码节点编码流程图。步骤如下：

开始；

初始化交换机节点；

在pkt_list中搜索与encode_id相等的数据包，将其提取到todo_pkt_list；

判断本次传递来的数据包是否与encode_id等价；

若相等，则新的数据包入队todo_pkt_list，判断todo_pkt_list中数据包的个数；若个数等于最大流，则对todo_pkt_list中数据包联合编码，之后清空todo_pkt_list，执行对应的outputaction，更新encode_id；若个数不等于最大流，则直接结束。

若不相等，则判断本次传来的数据包encode_id是偏大还是偏小，若偏大，则新数据包入队pkt_list，若偏小，则直接结束。

目的解码节点解码流程，与中间编码节点编码过程几乎相同，区别在于，中间编码节点编码过程中对”todo_pkt_list”中的数据包进行联合编码，而此处需要对”todo_pkt_list”中的数据包进行联合解码，通过构造多项式矩阵，采用高斯消元法来解出原始数据对应的多项式值，再还原成原始二进制数据并按顺序组装好即可，在此不过多赘述。