1.本技术实施例涉及通信领域，特别涉及一种网络传输层数据处理方法、设备及存储介质。
背景技术：
：：2.当前，随着日益严峻的网络安全环境，系统间进程的网络传输层通信加密和其他安全保护措施变得越来越重要。linux作为目前业界主流的商用产品运行系统，提供了多种内置的网络传输层加密协议与相关实现。目前较为常见的网络传输层加密处理方法或机制有：互联网安全协议(internetprotocolsecurity，ipsec)和传输层安全协议(transportlayersecurity，tls)。如图1所示，在实际应用中，ipsec是工作在开发式系统互联通信参考模块(opensysteminterconnectionreferencemodel，osi模型)位于第三层的网络层，通过对ip协议包进行加密和认证来保护所有基于ip协议的通信；而tls则是工作在osi模型位于第四层的传输层，一般在一种可靠的传输层协议，如面向连接的传输控制协议(transmissioncontrolprotocol，tcp)、无连接的用户数据报协议(userdatagramprotocol，udp)基础上为上层应用提供数据安全和完整性保护，具体是采用客户端-服务器模型的方式，在两个应用程序之间创建一个安全的传输连接/隧道，以防止交互的数据被窃听或篡改。3.虽然上述加密处理方法或机制可以实现数据在内核的加密或解密处理，但是基于ipsec协议的方式，在实际应用中需要系统管理员修改系统的网络配置或连接拓扑，如创建新的虚拟网络设备、修改全局路由表等，即对系统运行环境有侵入式的配置需求；而基于tls协议的方式，在实际应用中需要应用程序主动发起并参与传输连接/隧道的建立过程，相关配置参数和敏感数据，如数字证书等一般也需要应用程序自身来维护，即对经验程序自身有侵入式配置需求。4.也就是说，对于传统的网络传输层加密处理方法，其对系统环境或上层应用是不透明的。它们需要系统环境或上层应用改变自身的状态，并参与到实际的加解密流程中。这种不透明带来了额外的部署、配置、运维以及开发的负担，同时也带来了额外的风险，如任何一个错误的配置或实现都可能导致数据保护失效，或是对系统环境造成不利影响，进而影响到其他应用。技术实现要素：5.本技术实施例的目的在于提供一种网络传输层数据处理方法、设备及存储介质，旨在解决上述技术问题。6.为解决上述技术问题，本技术的实施例提供了一种网络传输层数据处理方法，应用于运行在内核的扩展伯克利包过滤器ebpf程序，所述网络传输层数据处理方法包括：获取需要分发的网络传输层数据包；对所述网络传输层数据包进行解析，确定需要对所述网络传输层数据包进行的网络传输层数据处理方式；根据所述网络传输层数据处理方式，对所述网络传输层数据包进行处理。7.为实现上述目的，本技术实施例还提供了一种网络传输层数据处理方法，包括：应用于运行在用户面的管理程序，所述网络传输层数据处理方法包括：在所述管理程序启动后，监测是否接收到针对运行在内核的ebpf程序的操作指令和/或所述ebpf程序统计的针对网络传输层数据包处理过程中的统计数据；如果接收到针对所述ebpf程序的操作指令，根据所述操作指令对所述ebpf程序进行处理；如果接收到所述ebpf程序统计的针对网络传输层数据包处理过程中的统计数据，对所述统计数据进行处理。8.为实现上述目的，本技术实施例还提供了一种网络传输层数据处理设备，包括：运行在用户面的管理程序和运行在内核的ebpf程序，至少一个处理器；以及，与所述至少一个处理器通信连接的存储器；其中，所述管理程序用于向所在环境的内核加载所述ebpf程序，以使所述ebpf程序运行在所述内核，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如上所述的任意一种网络传输层数据处理方法。9.为实现上述目的，本技术实施例还提供了一种计算机可读存储介质，存储有计算机程序。所述计算机程序被处理器执行时实现上述所述的任意一种网络传输层数据处理方法。10.本技术实施例提出的网络传输层数据处理方法、设备及存储介质，通过在用户面加载并运行能够管理ebpf程序的管理程序，进而利用管理程序预先将ebpf程序注册到内核中，由ebpf程序去拦截需要内核分发，如发送出去的网络传输层数据包、接收的网络传输层数据包，并确定需要分发的网络传输层数据包的网络传输层数据处理方式，最终由ebpf程序根据确定的网络传输层数据处理方式，对当前拦截的网络传输层数据包进行处理。整个网络传输层数据处理过程在改写后的内核中的ebpf程序便可以完成，无需系统环境或上层应用改变自身的状态，并参与到实际的网络传输层数据处理过程中，做到了对系统环境或上层应用的透明化，从而无需额外的部署、配置、运维以及开发成本，也保证了良好的系统环境与上层应用的兼容性。11.除此之外，本实施例提供的网络传输层数据处理方案，除了单纯的基于加载在内核中的ebpf程序对网络传输层数据包进行加密或解密处理，还可以设置ebpf程序与上层应用，如运行在用户面的应用程序配合，实现联合加密或解密处理，从能够根据实际业务需求，在尽可能减小对上传应用修改的情况下，联合上层应用的加密/解密方式，进一步提升网络传输层数据包在传输过程中的安全性。12.此外，基于ebpf技术自身的安全性和高性能，也保证了本实施例提供的网络传输层数据处理方案的安全性和整体性能。附图说明13.一个或多个实施例通过与之对应的附图中的图片进行示例性说明，这些示例性说明并不构成对实施例的限定。14.图1是传统的ipsec协议、tls协议与osi模型的对应关系示意图；15.图2是本技术实施例提供的应用于管理程序的网络传输层数据处理方法的流程示意图；16.图3是本技术实施例提供的应用于管理程序的网络传输层数据处理方法的又一流程示意图；17.图4针对图2或图3所示的网络传输层数据处理方法中涉及的管理程序与ebpf程序之间的交互示意图；18.图5是本技术实施例提供的应用于ebpf程序的网络传输层数据处理方法的流程示意图；19.图6是本技术实施例提供的应用于ebpf程序的网络传输层数据处理方法的又一流程示意图；20.图7是基于本技术实施例提供的网络传输层数据处理方法在节点a和节点b之间实现全透明传输加密的示意图；21.图8是基于本技术实施例提供的网络传输层数据处理方法在节点a和节点b之间实现与上层应用程序联合加密的示意图；22.图9是本技术实施例提供的网络传输层数据处理设备的结构示意图。具体实施方式23.本技术实施例中术语“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。24.本技术实施例中术语“多个”是指两个或两个以上，其它量词与之类似。25.为使本技术实施例的目的、技术方案和优点更加清楚，下面将结合附图对本技术的各实施例进行详细的阐述。然而，本领域的普通技术人员可以理解，在本技术各实施例中，为了使读者更好地理解本技术而提出了许多技术细节。但是，即使没有这些技术细节和基于以下各实施例的种种变化和修改，也可以实现本技术所要求保护的技术方案。以下各个实施例的划分是为了描述方便，不应对本技术的具体实现方式构成任何限定，各个实施例在不矛盾的前提下可以相互结合相互引用。26.参见图2，图2是本技术实施例提供的网络传输层数据处理方法的流程图，在本实施例中，该方法主要应用于运行在用户面的管理程序。27.如图2所示，本实施例提供的网络传输层数据处理方法，包括以下步骤：28.步骤201，在管理程序启动后，监测是否接收到针对运行在内核的ebpf程序的操作指令和/或ebpf程序统计的针对网络传输层数据包处理过程中的统计数据。29.需要说明的，本实施例中所说的ebpf程序(extendedberkeleypacketfilter，扩展伯克利过滤器)其原本的目标是实现一种全新的包过滤器，以取代iptable(一种网络防火墙)，但是后续的演进对其功能进行了扩展。现在ebpf程序本质上是运行在内核里的特殊代码，用户可以在其规定的限制下编写功能代码，这些代码编译成字节码后将加载到内核里一个特殊的虚拟机内执行。因此，为了能够根据实际的业务需求对ebpf程序进行管理，本实施例提供了运行在用户面的管理程序，从而使得用户能够通过管理程序，实现对运行在内核中的ebpf程序的管理。30.基于上述论述，为了保证本实施例提供的网络传输层数据处理方法的实现，以及对ebpf程序的管理，管理程序不仅要负责向内核中加载，或者说注册ebpf程序，还提供了用户交互接口。31.具体的，上述所说管理程序向内核中加载ebpf程序，具体是将ebpf程序实现相应功能的字节码加载到内核的指定位置，以便当网络传输层数据包需要内核分发，如向外发送，或者接收时，到达内核的网络传输层数据包能够被加载在内核中的ebpf程序拦截，进而由ebpf程序根据对应的功能接口/函数对网络传输层数据包进行相应处理。32.相应地，管理程序提供的用户交互接口，具体用于接收用户作出的针对运行在内核中的ebpf程序的操作指令。33.进一步地，在一个例子中，管理程序还用于通过用户交互接口将ebpf程序反馈的处理网络传输层数据包过程中产生的统计数据，如成功加密的数量/解密的数量等，和/或ebpf程序的运行状态、当前配置参数等信息反馈给用户，供用户根据ebpf程序的当前运行情况进行后续操作。34.通过上述描述可知，管理程序启动后，具体是通过监测用户交互接口来确定当前是否有针对运行在内核的ebpf程序的操作指令，通过监测与内核中运行的ebpf程序交互的接口，如系统调用函数/接口(syscall)来确定是否接收到ebpf程序统计的针对网络传输层数据包处理过程中的统计数据。35.相应地，如果监测到接收到了针对运行在内核的ebpf程序的操作指令，则进入步骤202；如果监测到接收到了运行在内核的ebpf程序输出的网络传输层数据包，则进入步骤203。36.此外，应当理解的，在一个例子中，管理程序如果接收到运行在内核的ebpf程序反馈的当前状态信息，如解密成功的网络传输层数据包的数量、加密成功的网络传输层数据包的数量，以及ebpf程序当前进行加解密时依据的加解密条件、规则等，管理程序可以根据预先配置的业务需求，对接收到的上述信息进行存储和/或以预设形式展示，还或者通过用户交互接口反馈给用户。37.步骤202，根据操作指令对ebpf程序进行处理。38.具体的说，在一个例子中，管理程序通过用户交互接口接收到的针对运行在内核中的ebpf程序的操作指令分为如下3种：操作指令为配置信息更新指令，或者ebpf程序替换指令，或者ebpf程序卸载指令。39.相应地，针对上述3中不同的操作指令，管理程序对已经运行在内核中的ebpf程序进行的处理也有所差异，具体如下：40.(1)在操作指令为配置信息更新指令时，对已经运行在内核中的ebpf程序进行的处理具体为：41.首先，从配置信息更新指令中提取需要更新的配置信息。42.可理解的，本实施例中所说的配置信息包括加解密条件、加密规则、解密规则中的任意一种或几种。43.关于上述所说的加解密条件，具体为预先约定的针对采用哪类网络传输层协议、对应的四元组(源端口号、目的端口号、源ip地址、目的ip地址)的网络传输层数据包需要进行加密处理，或解密处理。44.相应地，上述所说的加密规则，至少包括了对需要进行加密处理的网络传输层数据包进行加密处理所采用的具体加密算法。45.进一步地，如果规定的加密算法需要用到密钥，则加密规则中还需要包括采用规定的加密算法进行加密所需的密钥。46.相应地，上述所述的解密规则，至少包括了对需要进行解密处理的网络传输层数据包进行解密处理所采用的具体解密算法。47.进一步地，如果规定的解密算法需要用到密钥，则解密规则中还需要包括采用规定的解密算法进行解密所需的密钥。48.此外，应当理解的，加密处理和解密处理通常是成对出现的，因而对于网络传输层数据包的发送方，比如节点a中运行在内核中的ebpf程序关于加密处理的相关配置信息需要与网络传输层数据包的接收方，比如b节点中运行在内核中的ebpf程序关于解密处理的相关配置信息是相互配合的。49.然后，根据提取的需要更新的配置信息对已经运行在内核中的ebpf程序对应的配置信息映射表更新。50.具体的说，本实施例中所说的配置信息映射表，即ebpf技术中涉及的bpfmap。在具体应用中，可以针对能够运行在内核中的不同ebpf程序分别设计一个对应的bpfmap，也可以设计一个全局的bpfmap，对于所有能够运行在内核中的ebpf程序都统一共用一个bpfmap。但不论哪种方式，在根据业务需要预先设计bpfmap时，均需将ebpf程序进行加密、解密等出来所需的参数定义到bpfmap中。51.相应地，基于设计好的bpfmap，管理程序在对运行在内核中的ebpf程序进行管理时，如配置信息的修改时，只需将需要修改的配置信息更新到该bpfmap中，ebpf程序被内核激活后，便会主动去bpfmap中查找需要的配置信息，然后根据查找到的配置信息作出相应操作。52.也就是说，bfpmap实质是内核提供的一种交换机制/通信机制，基于bpfmap运行在用户面的管理程序和运行在内核的ebpf程序便可以实现交互。53.(2)在操作指令为ebpf程序替换指令时，对已经运行在内核中的ebpf程序进行的处理具体为：54.首先，从ebpf程序替换指令中提取替换ebpf程序。55.然后，将替换ebpf程序注册到内核中，并在替换ebpf程序注册到内核后，卸载内核中运行的ebpf程序。56.(3)在操作指令为ebpf程序卸载指令时，对已经运行在内核中的ebpf程序进行的处理具体为：卸载内核中运行的ebpf程序。57.步骤203，对统计数据进行处理。58.具体的说，在一个例子中，管理程序在接收到ebpf程序提供的对网络传输层数据包进行加密/解密处理时统计的统计数据，如成功加密的数量或成功解密的数量时，对接收到的统计数据进行的处理可以是将统计数据存储到预设存储区域和/或以预设形式展示。59.此外，值得一提的是，在实际应用中，管理程序除了在接收到的操作指令是ebpf程序卸载指令，并卸载ebpf程序后会退出当前的消息处理操作，停止执行本实施例提供的网络传输层数据处理方法，其他情况下，如根据配置参数修改指令，或ebpf程序替换指令完成对已经运行在内核中的ebpf程序的处理后，以及对统计数据进行处理后，均会自动进入下一次消息处理。60.通过上述描述不难发现，本实施例提供的网络传输层数据处理方法，通过在用户面部署，并启动管理程序，由管理程序向内核中加载能够实现加解密处理的ebpf程序，并监测运行在内核中的ebpf程序的反馈，以及用户作出的操作指令，进而根据监测到的结果，在用户面直接作出相应结果，或者对运行在内核中的ebpf程序进行管理，从而实现对ebpf程序的动态管理。由于整个过程，无需系统环境或上层应用改变自身的状态，并参与到实际的网络传输层数据处理过程中，因此在系统环境、上层应用没有任何变更的情况下，便可以实现网络传输层数据的加解密处理。61.此外，由于管理程序直接对运行在内核中ebpf程序进行管理，因此能够在系统环境、上层应用没有感知的情况下，就可以实现对进行加解密处理的ebpf程序的激活、去激活，配置信息的变更等操作，从而能够动态的调整对需要传输的数据，即网络传输层数据包进行加解密处理，使得网络传输层数据处理能够更加满足实际变动的业务需要。62.基于此，本实施例提供的网络传输层数据处理方法，真正做到了对系统环境或上层应用的透明化，从而无需额外的部署、配置、运维以及开发成本，也保证了良好的系统环境与上层应用的兼容性。63.此外，基于ebpf技术自身的安全性和高性能，也保证了本实施例提供的网络传输层数据处理方案的安全性和整体性能。64.此外，在一个例子中，如果不追求绝对的透明，或者是有特殊的数据保护需求，ebpf程序也可以和上层应用配合起来完成对数据的加密或保护。例如，上层应用可以有意发送内容不合法的数据包，如果接收方的环境部署了对应的ebpf程序(同时参数配置正确)，那么在接收方内核看到数据前，ebpf程序可以将不合法的数据修复，然后再交由内核处理，从而让接收方应用能正确读取信息；如果接收方环境没有部署对应的ebpf程序(或者参数配置不正确)，那么接收方内核(以及可能正在监听传输线路的恶意中间人)会认为数据包非法而将其丢弃，从而保护了数据的安全。65.对于这种联合加密方式，如果节点，比如节点a是通过上层应用进行加密，则对于仅作为向外发送网络传输层数据包的节点a，在用户面可以不部署管理程序，内核中不加载ebpf程序。66.相应地，对于接收节点a通过上层应用加密的网络传输层数据包的节点b，则需要在用户面部署管理程序，在内核中记载ebpf程序，从而配合实现对网络传输层数据包的处理。67.参见图3，图3是本技术实施例提供的网络传输层数据处理方法的又一流程图，在本实施例中，该方法主要应用于运行在用户面的管理程序。68.在本实施例中，引入了管理程序向内核加载ebpf程序的具体操作，如图3所示，本实施例提供的网络传输层数据处理方法，包括以下步骤：69.步骤301，从预设地址读取配置信息。70.具体的说，为了保证内核有需要分发的网络传输层数据时，不管是向内，即内核从其他节点接收到的网络传输层数据包，还是向外，即内核需要发送给其他节点的网络传输层数据包，能够在到达内核时，被内核中运行的ebpf程序拦截，并由ebpf程序对拦截的网络传输层数据包进行相应的网络传输层数据处理，如加密处理或解密处理，需要保证内核中已经运行了ebpf程序。因此，在初次执行本实施例提供的网络传输层数据处理方法时，当管理程序被部署到用户面，并启动后，管理程序需要先从预设地址读取配置信息，比如从存储在用户面的某一配置信息文件中读取。71.此外，在本实施例中，管理程序从预设地址读取的配置信息同样包括加解密条件、加密规则、解密规则中的任意一种或几种。72.步骤302，检查需要注册到内核的ebpf程序和配置信息的完整性。73.具体的说，为了保证基于被注册到内核的ebpf程序处理网络传输层数据包的性能、安全性，管理程序在将预先设计好的ebpf程序注册到内核，将读取的配置信息配置到ebpf程序对应的配置信息映射表前，需要先检查ebpf程序和配置信息的完整性。74.步骤303，如果ebpf程序和配置信息均完整，将ebpf程序注册到内核中，以使ebpf程序运行在内核。75.具体为管理程序向所在环境的内核加载ebpf程序的字节码，并在将ebpf程序加载到内核中，后续通过系统调用函数/接口(syscall)与ebpf程序进行数据交换。76.此外，管理程序也向外提供管理和查询接口，如用户交互接口，以便根据外部输入的操作指令，对运行在内核中的ebpf程序进行相应处理。77.步骤304，将配置信息配置到ebpf程序对应的配置信息映射表中。78.具体的说，本实施例中所说的配置信息映射表，即ebpf技术中涉及到的bpfmap。在实际应用中，本实施例中提供的ebpf程序与管理程序之间可以通过一个或多个bpfmap进行配置数据或运行时统计的统计数据的交互。79.应当理解的是，上述示例仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。80.步骤305，进入消息处理循环操作。81.具体的说，上述所说的进入消息处理循环操作是指预先构建消息队列，在每次监测到有需要处理的消息，如针对ebpf程序的操作指令和/或ebpf程序在bpfmap中写入针对网络传输层数据包处理过程中统计的统计数据时，先将接收到的需要处理的消息添加到消息队列，然后依次从消息队列读取需要处理信息，根据当前读取的需要处理的信息的具体类型，进入步骤306至步骤309任一步骤，并执行对应的操作。82.步骤306，如果接收到针对ebpf程序的配置信息更新指令，从配置信息更新指令中提取需要更新的配置信息，根据提取的需要更新的配置信息对ebpf程序对应的配置信息映射表更新。83.步骤307，如果接收到针对ebpf程序的ebpf程序替换指令，从ebpf程序替换指令中提取替换ebpf程序，将替换ebpf程序注册到内核中，并在替换ebpf程序注册到内核后，卸载内核中运行的所述ebpf程序。84.步骤308，如果接收到针对ebpf程序的ebpf程序卸载指令，卸载内核中运行的所述ebpf程序。85.步骤309，如果ebpf程序统计的针对网络传输层数据包处理过程中的统计数据，将将统计数据存储到预设存储区域和/或以预设形式展示。86.不难发现，本实施例中的步骤306至步骤307与图2所示的实施例中步骤202和步骤203给出的几种具体处理方式大致相同，在此就不再赘述。87.此外，关于本实施例中所涉及的管理程序、需要读取的配置信息、ebpf程序以及外部输入之间的交互，具体如图4所示，此处不再赘述。88.由此，本实施例提供的网络传输层数据处理方法，在进行网络传输层数据处理之前，利用运行在用户面的管理程序向内核加载ebpf程序，并对ebpf程序进行配置管理，如将ebpf程序进行加解密处理时用到的配置信息配置到配置信息映射表，从而在有需要内核分发的网络传输层数据包时，能够由ebpf程序进行相应的加密处理、解密处理。89.参见图5，图5是本技术实施例提供的网络传输层数据处理方法的流程图，在本实施例中，该方法主要应用于运行在内核的ebpf程序。90.需要说明的，本实施例所说的网络传输层数据处理方法，具体是指运行在内核的ebpf程序对内核需要分发的网络传输层数据包的加密处理或解密处理。91.如图5所示，本实施例提供的网络传输层数据处理方法，包括以下步骤：92.步骤501，获取需要分发的网络传输层数据包。93.可理解的，本实施例中所说的需要分发的网络传输层数据包具体是指需要内核向本节点的上层应用，如运行在用户面上的应用程序分发接收到的网络传输层数据包，即需要分发的网络传输层数据包来自其他节点。94.此外，在一个例子中，需要分发的网络传输层数据包还可以是由内核向其他节点分发，即需要分发的网络传输层数据包是需要内核向其他节点发送的。95.此外，值得一提的是，在实际应用中，加载到内核中的ebpf程序，并非一直处于运行状态，或者说激活状态，只有在有需要分发的网络传输层数据包到达内核时，才会由内核触发，进而去执行本实施例中提供的网络传输层数据处理方法。96.相应地，上述获取到的需要分发的网络传输层数据包，实质是在内核触发ebpf程序后，传输给ebpf程序的。97.步骤502，对网络传输层数据包进行解析，确定需要对网络传输层数据包进行的网络传输层数据处理方式。98.具体的说，通常情况下网络传输层数据包的协议头中会携带传输该网络传输层数据包所采用的的协议、四元组等信息，因此在确定需要对网络传输层数据包进行的网络传输层数据处理方式时，通过对网络传输层数据包进行解析，进而提取网络传输层数据包的协议头，然后根据协议头和预先配置的加解密条件，判断该网络传输层数据包是否需要加密或解密。99.相应地，如果通过判断确定网络传输层数据包需要进行加密，则确定需要对网络传输层数据进行的网络传输层数据处理方式为加密处理方式；如果通过判断确定网络传输层数据包需要进行解密，则确定需要对网络传输层数据进行的网络传输层数据处理方式为解密处理。100.需要说明的是，本实施例中所说的加解密条件具体是由运行在用户面的管理程序提供的。在实际应用中，加解密条件可以是预先规定的好的针对哪些协议传输的网络传输层数据包进行加密或解密。101.进一步，加解密条件还可以是规定针对某一具体端口号(源端口号和/或目的端口号)、某一具体ip地址(源ip地址和/或目的ip地址)。102.应当理解的是，上述示例仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。103.此外，需要说明的，在实际应用中，在确定需要对网络传输层数据包进行的网络传输层数据处理方式之前，可以先确定网络传输层数据包是否需要进行网络传输层数据处理，如果不需要则直接交由内核进行后续分发操作，如果需要再确定需要进行的网络传输层数据处理方式。104.此外，在本实施例中，对需要分发的网络传输层数据包进行的网络传输层数据处理方式大致分为加密处理和解密处理。而在实际应用中，通常是对需要发送给其他节点的网络传输层数据包才进行加密处理，对从其他节点接收到的网络传输层数据包要进行的是解密处理。基于此，在确定需要对网络传输层数据包进行的网络传输层数据处理方式时，具体可以先确定当前的网络数据是需要发送出去的，还是接收到的。105.相应地，如果是接收到的，具体是判断网络传输层数据包是否需要解密；如果是需要发送出的，具体是判断网络传输层数据包是否需要加密。106.步骤503，根据网络传输层数据处理方式，对网络传输层数据包进行处理。107.具体的说，在确定的网络传输层数据处理方式为加密处理方式时，对网络传输层数据包进行的处理具体为：108.首先，从预先配置的加密规则中选取目标加密规则。109.具体的说，上述预先配置的加密规则同样是由运行在用户面的管理程序提供的。具体是由管理程序从预设地址读取包括了加密规则的配置信息，然后将读取到的配置信息配置到ebpf程序对应的配置信息映射表中。故而，上述选取目标加密规则的操作，具体是从配置信息映射表中选取适合当前需要进行加密处理的网络传输层数据包的加密规则。110.需要说明的是，在实际应用中，加密规则至少需要包括具体的加密算法。111.进一步地，对于需要涉及密钥的，加密规则还需要包括加密密钥，可以理解为加密参数。112.此外，关于如何选取适合当前需要进行加密处理的网络传输层数据包的目标加密规则，在实际应用中可以根据当前需要进行加密处理的网络传输层数据包的协议头的内容确定。113.比如，预先规定采用某一协议，或者某一特定端口号，或者某一ip地址对应的具体加密方法和密钥，进而在选取目标加密规则时，更加需要进行加密处理的网络传输层数据包的协议头便可以快速、准确的选取一个适合该网络传输层数据包的加密规则。114.此外，值得一提的是，在一个例子中，也可以是所有需要进行加密的网络传输层数据包均采用同一加密规则。115.然后，根据目标加密规则，对网络传输层数据包的载荷部分进行加密处理。116.接着，根据加密后的载荷部分，更新协议头，得到加密后的网络传输层数据包。117.由于进行加密处理之后，加密后的载荷部分的长度通常会与加密前的载荷部分的长度存在差异，因而为了保证加密处理后的网络传输层数据包在传输到其他节点后，不会因为协议头中记录的长度信息和实际接收到的网络传输层数据包的载荷部分的长度不一致，而将加密后的网络传输层数据包误认为非法数据。因此，在根据目标加密规则对网络传输层数据包的载荷部分进行加密处理之后，需要根据加密后的载荷部分更新协议头，进而保证最终得到加密后的网络传输层数据包的协议头记录的信息与加密后的载荷部份的长度一致。118.最后，将加密后的网络传输层数据包交由内核，由内核对加密后的网络传输层数据包进行分发。119.由此，实现了对需要分发网络传输层数据的加密处理。120.相应地，在确定的网络传输层数据处理方式为解密处理方式时，对网络传输层数据包进行的处理方式具体为：首先，从预先配置的解密规则中选取目标解密规则；然后，根据目标解密规则，对网络传输层数据包的载荷部分进行解密处理；接着，根据解密后的载荷部分，更新协议头，得到解密后的网络传输层数据包；最后，将解密后的网络传输层数据包交由内核，由内核对解密后的网络传输层数据包进行分发。121.可理解的，为了保证经ebpf程序加密处理后的网络传输层数据包在到达对端节点的内核中，能够运行在对端节点内核中的ebpf程序解密，解密规则需要与加密规则相对应，以保证加密后的网络传输层数据包能够被解密，进而还原出原始的网络传输层数据包。122.由此，本实施例提供的网络传输层数据处理方法，通过在用户面加载并运行能够管理ebpf程序的管理程序，进而利用管理程序预先将ebpf程序注册到内核中，由ebpf程序去拦截需要内核分发，如发送出去的网络传输层数据包、接收的网络传输层数据包，并确定需要分发的网络传输层数据包的网络传输层数据处理方式，最终由ebpf程序根据确定的网络传输层数据处理方式，对当前拦截的网络传输层数据包进行处理。整个网络传输层数据处理过程在改写后的内核中的ebpf程序便可以完成，无需系统环境或上层应用改变自身的状态，并参与到实际的网络传输层数据处理过程中，做到了对系统环境或上层应用的透明化，从而无需额外的部署、配置、运维以及开发成本，也保证了良好的系统环境与上层应用的兼容性。123.此外，在一个例子中，如果不追求绝对的透明，或者是有特殊的数据保护需求，ebpf程序也可以和上层应用配合起来完成对数据的加密或保护。例如，上层应用可以有意发送内容不合法的数据包，如果接收方的环境部署了对应的ebpf程序(同时参数配置正确)，那么在接收方内核看到数据前，ebpf程序可以将不合法的数据修复，然后再交由内核处理，从而让接收方应用能正确读取信息；如果接收方环境没有部署对应的ebpf程序(或者参数配置不正确)，那么接收方内核(以及可能正在监听传输线路的恶意中间人)会认为数据包非法而将其丢弃，从而保护了数据的安全。124.对于这种联合加密方式，如果节点，比如节点a是通过上层应用进行加密，则对于仅作为向外发送网络传输层数据包的节点a，在用户面可以不部署管理程序，内核中不加载ebpf程序。125.相应地，对于接收节点a通过上层应用加密的网络传输层数据包的节点b，则需要在用户面部署管理程序，在内核中记载ebpf程序，从而配合实现对网络传输层数据包的处理。126.此外，基于ebpf技术自身的安全性和高性能，也保证了本实施例提供的网络传输层数据处理方案的安全性和整体性能。127.此外，值得一提的是，由于ebpf程序是由运行在用户面的管理程序加载到内核中的，并且管理程序能够管理ebpf程序。因此，在实际应用中，如果运行在内核中的ebpf程序接收到了用户面的管理程序下发的配置信息更新指令，则根据配置信息更新指令，更新预先配置的配置信息，即配置在配置信息映射表中的配置信息，具体可以是加解密条件、加密规则、解密规则中的任意一种或几种。由此，实现了对运行在内核中的ebpf程序的动态更新，使得运行在内核中的ebpf程序能够更好的适应于实际的网络传输层数据处理需求。128.参见图6，图6是本技术实施例提供的网络传输层数据处理方法的流程图，在本实施例中，该方法主要应用于运行在内核的ebpf程序。129.如图6所示，本实施例提供的网络传输层数据处理方法，包括以下步骤：130.步骤601，获取需要分发的网络传输层数据包。131.不难发现，本实施例中的步骤601与图5所示的实施例中的步骤501大致相同，在此就不再赘述。132.步骤602，对网络传输层数据包进行解析，确定网络传输层数据包是否需要处理。133.具体的说，在实际应用中，需要内核分发的网络传输层数据包并非每一个都需要进行加密或解密处理，比如对于仅仅是相对端节点作出的收到其发送的信息或请求的响应。因此，在确定需要分发的网络传输层数据包的网络传输层数据处理方式前，可以先根据解析出的网络传输层数据包的协议头中携带的标识信息确定当前需要分发的网络传输层数据包是否需要进行加密处理或解密处理。134.相应地，如果确定网络传输层数据包需要进行处理，则进入步骤603，确定网络传输层数据包具体需要进行的网络传输层数据处理方式。反之，如果确定网络传输层数据包不需要处理，则直接进入步骤610，即直接将拦截的网络传输层数据包交由内核，由内核对其进行分发即可。135.步骤603，确定网络传输层数据包是需要发送的网络传输层数据包，还是接收到的网络传输层数据包。136.根据上述论述可知，对于需要进行网络传输层数据处理的网络传输层数据包，在网络传输层数据包是需要由内核发送至其他节点的网络传输层数据包时，需要进行的网络传输层数据处理方式为加密处理方式。137.相应地，对于需要进行网络传输层数据处理的网络传输层数据包是需要由内核反馈给上层应用，即位于用户面应用程序，或者说网络传输层数据包是内核从其他节点接收到的网络传输层数据包时，需要进行的网络传输层数据处理方式为解密处理方式。138.基于此，只需确定网络传输层数据包是需要发送的网络传输层数据包，还是接收到的网络传输层数据包便可以快速确定需要进行处理的网络传输层数据包的具体处理方式。139.相应地，如果确定网络传输层数据包是需要发送的网络传输层数据包，则进入步骤603。反之，如果确定网络传输层数据包是接收到的网络传输层数据包，则进入步骤607。140.步骤604，对网络传输层数据包的载荷部分进行加密。141.步骤605，更新网络传输层数据包的协议头。142.步骤606，将加密后的网络传输层数据包交由内核，由内核对加密后的网络传输层数据包进行分发。143.步骤607，对网络传输层数据包的载荷部分进行解密。144.步骤608，更新网络传输层数据包的协议头。145.步骤609，将解密后的网络传输层数据包交由内核，由内核对解密后的网络传输层数据包进行分发。146.步骤610，将网络传输层数据包交由内核，由内核对网络传输层数据包进行分发。147.由此，本实施例提供的网络传输层数据处理方法，通过利用ebpf程序，很好地解决了传统网络传输层数据传输加密协议在使用中对系统环境和上层应用带来的侵入影响，提供了更灵活、更强大的数据传输加密与保护功能，同时在安全性上有更好的隔离与保证。148.此外，需要说明的是，ebpf技术支持多种程序类型，不同类型的程序适用于不同的用途，而当前比较适合实现传输加密功能的类型是流量控制(trafficcontrol，tc)。因此，本实施例中所说的对网络传输层数据包进行加密处理或加密处理的ebpf程序，具体为tc类型的ebpf程序。通过在内核中加载tc类型的ebpf程序能够直接拦截linux内核对于网络传输层数据包的处理入口和出口，在内核对网络传输层数据包进行接收或发送前，tc程序就可以直接访问到缓存原始的网络传输层数据包的内存缓存区，然后根据原始的网络传输层数据包对应的内存缓存区地址，从内存缓存区获取需要处理的网络传输层数据包，接着对获取到网络传输层数据包进行相应的网络传输层数据处理操作，并在完成相应的网络传输层数据处理操作后，再交由内核，由内核对其进行分发处理。149.显然，通过利用tc类型的ebpf程序，就可以将数据加解密的具体实现和配置逻辑集成到一个软硬件单元中，从而在系统环境和上层应用都不了解任何细节的情况下完成网络传输层数据的加解密。再加上ebpf程序和内核一样，都是可以在运行时动态加载/卸载的，因此本实施例提供的网络传输层数据处理方法可以实现运行时的加解密功能激活/去激活，或动态替换加密算法和配置数据，而与此同时操作系统和上层应用对这些行为变更可以一无所知。150.此外，需要说明的是，本实施例中采用tc类型的ebpf程序是基于目前ebpf技术的现状而确定的，如果在后续ebpf技术的快速演进中，出现了其他适合的类型，依旧可以实现本实施例实现的方法。即，本实施例中采用tc类型的ebpf程序实现网络传输数据处理，只是一种具体的实现方式，对本实施例提供的技术方案本身并不构成任何限定。151.此外，在一个例子中，如果不追求绝对的透明，或者是有特殊的数据保护需求，ebpf程序也可以和上层应用配合起来完成对数据的加密或保护。例如，上层应用可以有意发送内容不合法的数据包，如果接收方的环境部署了对应的ebpf程序(同时参数配置正确)，那么在接收方内核看到数据前，ebpf程序可以将不合法的数据修复，然后再交由内核处理，从而让接收方应用能正确读取信息；如果接收方环境没有部署对应的ebpf程序(或者参数配置不正确)，那么接收方内核(以及可能正在监听传输线路的恶意中间人)会认为数据包非法而将其丢弃，从而保护了数据的安全。152.此外，为了更好的理解基于本实施例提供的应用于运行在用户面的管理程序的网络传输层数据处理方法和应用于运行在内核的ebpf程序的网络传输层数据处理，以下结合图7和图8，对基于管理程序和ebpf程序的配合实现的网络传输层数据处理，具体为加密和解密过程进行具体说明。153.首先，需要说明的是，在实际应用中，网络传输层数据包的接收方(以下称为数据接收方)和网络传输层数据包的发送方(以下称为数据发送方)必须是都使用linux系统的，同时内核版本需要大于4.3，且开启了ebpf相关功能。154.进一步地，数据通信双方，即数据发送方和数据接收方需要使用标准的网络传输层协议栈，如ip、tcp/udp通信。155.此外，可以理解的，在实际应用中，运行在用户面的管理程序和运行在内核的ebpf程序可以是封装在一个软件包sdk中，以软件形态进行分发与部署的，也可以是封装到一个便携式硬件内，以硬件单元的形态分发与部署的。156.此外，当前市面上一些主流厂商的网卡已经支持直接加载并运行ebpf程序。这意味着具体的网络传输层数据处理工作不再依赖操作系统内核完成，而是由网卡内的专用芯片来完成。因此，对于此类设备，ebpf程序可以直接加载到该设备内运行，只需要单独管理需要运行在用户面的管理程序，并建立二者通信即可。157.参见图7，图7为节点a和节点b之间实现全透明传输加密的示意图，即位于用户面的应用程序(上层应用)不参与加密、解密，整个传送加密过程，对于节点a和节点b的系统环境、上层应用均是没有感知的。158.为了便于后续描述，首先假定上层应用，即应用程序与加密系统(管理程序 ebpf程序)符合如下设定：159.上层应用以tcp协议在1080端口与另一个远端的相同应用通信，如图7中的节点a和节点b；节点a和节点b的网络设备均为eth0；ebpf程序的文件名称为ebpf.elf；ebpf程序中负责加密的函数名为encrypt；ebpf程序中负责解密的函数名为decrypt。160.对于管理程序，其需要在节点a和节点b上运行，并通过如下命令加载ebpf程序(具体是加载ebpf程序中的加密函数和解密函数)：161.加载ebpf程序中的加密函数：tcfilteradddeveth0egressbpfdaobjebpf.elfsecencrypt162.加载ebpf程序中的解密函数：tcfilteradddeveth0inressbpfdaobjebpf.elfsecdecrypt163.执行完上述两条加载命令后，不论是节点a的内核，还是节点b的内核在向eth0发送网络传输层数据包时(egress)，均会调用之前挂载的ebpf程序中的encrypt函数，并将原始的内核数据缓存(socketkernelbuffer，简称skb)指针传递给函数。164.对于encrypt函数的处理流程，具体如下：165.(1)对skb进行以太网协议分析(解析并剥离ethernet头)。166.(2)确定网络传输层数据包的载荷部分是否为ip协议，如果不是，则直接结束处理，即进入步骤(10)。167.(3)对载荷部分进行ip协议分析(解析并剥离ip头)，如果ip头的载荷协议指示不为tcp，则直接结束处理，即进入步骤(10)。168.(4)对载荷部分进行tcp协议分析(解析并剥离tcp头)，确定目的端口是否为1080，如果不是，则直接结束处理，即进入步骤(10)。169.(5)计算ip协议的数据载荷范围(起始指针与结束指针)。170.(6)使用流加密算法(rivestcipher4，rc4)对ip协议载荷进行加密。171.可理解的，上述给出的仅为一种具体的加密算法，在实际应用中，本领域技术人员可以根据需要选择加密算法，并将选择的加密算法发送至管理程序，由管理程序进行配置。172.(7)将加密后的数据写回(可利用内核中的bpfhelper函数中的bpf_skb_store_bytes)，并更新ip头(主要是长度与校验码，可以利用bpfhelper函数中的bpf_l3_csum_replace)。173.(8)调用内核中的bpfhelper函数：bpf_skb_adjust_room，更新skb。174.(9)结束处理(内核会继续完成更新后数据的发送工作)。175.由此，完成了ebpf程序对网络传输层数据包的加密处理。176.相应地，在执行加载命令后，不论是节点a的内核，还是节点b的内核从eth0接收到网络传输层数据包时(ingress)，均会调用之前挂载的ebpf程序中的decrypt函数，并将原始数据缓存(sk_buff，简称skb)指针传递给函数。177.对于decrypt函数的处理流程，具体如下：178.(1)对skb进行以太网协议分析(解析并剥离ethernet头)。179.(2)确定载荷部分是否为ip协议，如果不是，则直接结束处理，即进入步骤(9)。180.(3)进行ip协议分析(解析并剥离ip头)，如果ip头的载荷协议指示不为tcp，则直接结束处理，即进入步骤(9)。181.(4)对载荷部分进行tcp协议分析(解析并剥离tcp头)，如果格式正确，说明数据未加密，直接结束处理，即进入步骤(9)。182.(5)使用rc4算法对ip载荷部分进行解密处理。183.可理解的，由于上述加密过程是采用的rc4算法，因此解密过程中同样需要采用rc4算法。184.(6)对解密后的数据进行tcp协议头检查，如果数据是非法的，比如某个字段的取值不再合法范围内，或目的端口不为1080，则直接结束处理，即进入步骤(9)。185.(7)将解密后的数据写回(可利用bpfhelper函数:bpf_skb_store_bytes)，并更新ip头(主要是长度与校验码，可以利用bpfhelper函数：bpf_l3_csum_replace)。186.(8)调用内核中的bpfhelper函数：bpf_skb_adjust_room，更新skb。187.(9)结束处理(内核会继续完成更新后数据的接收工作)。188.由此，完成了ebpf程序对网络传输层数据包的解密处理。189.此外，值得一提的是，在实际应用中encrypt函数和decrypt函数还需要执行如下操作：190.从指定的配置信息映射表(bpfmap)中获取管理程序传递的必要参数，如rc4加密算法相关参数、tcp端口号等；将一些运行统计数据记录到指定的bpfmap中，如加/解密包总数、成功/失败次数等。191.此外，值得一提的是，管理程序除了在初始化阶段加载ebpf程序外，还要负责如下工作：通过bpfmap向encrypt函数和decrypt函数传递必要的参数，如rc4加密算法相关参数、tcp端口号等；通过bpfmap读取汇总encrypt函数和decrypt函数在运行时记录的统计数据，如加/解密包总数、成功/失败次数等；通过命令行(或其他形式，如restful等)接口，让用户可以管理查询ebpf程序的运行参数，如四元组信息(端口号、地址等)和运行状态，如成功加密/解密的数量，检测到多少非法或合法的数据等。192.通过上述描述可以发现，在全透明传输加密方式下，上层应用并不参与到网络传输层的加解密流程中，因此其完全不知晓底层传输加密系统采用的算法、参数、时机等细节，在发送和接收网络数据时也不考虑加解密，全部以明文格式处理。这样上层应用无需作任何操作或配置修改即可实现网络传输层数据的加解密，而且上层应用对加密流程细节一无所知，即使被攻击者攻陷，其也无法了解实际的加解密流程细节，也无法获取关键的加解bpfdaobjebpf.elfsecdecrypt。206.相应地，在执行完上述加载命令后，如节点b的内核从eth0接收到来自节点a发送的网络传输层数据包时(ingress)，会调用之前挂载的ebpf程序中的decrypt函数，并将skb指针传递给函数。207.关于decrypt函数的处理流程，具体如下：208.(1)对skb进行以太网协议分析(解析并剥离ethernet头)。209.(2)确定载荷部分是否为ip协议，如果不是，则直接结束处理，即进入步骤(8)。210.(3)进行ip协议分析(解析并剥离ip头)，如果ip头的载荷协议指示不为tcp，则直接结束处理，即进入步骤(8)。211.(4)对载荷部分进行tcp协议分析(解析并剥离tcp头)，如果格式非法或目的端口号不等于1080，则直接结束处理，即进入步骤(8)。212.(5)使用x25519算法和私钥对tcp载荷部分进行解密处理。213.可理解的，上述给出的仅为一种具体的解密算法，在实际应用中，本领域技术人员可以根据需要选择加密算法，并将选择的解密算法发送至管理程序，由管理程序进行配置。214.此外，可理解的，ebpf程序进行解密时所依据解密方法，需要与节点a中应用程序采用的加密方法相对应。215.(6)将解密后的数据写回(可利用bpfhelper函数中的bpf_skb_store_bytes)，并更新tcp与ip头(主要是长度与校验码，可以利用bpfhelper函数中的bpf_l3_csum_replace以及bpf_l4_csum_replace)。216.(7)调用内核中的bpfhelper函数中的bpf_skb_adjust_room，更新skb。217.(8)结束处理(内核会继续完成更新后数据的接收工作)。218.由此，在节点b中利用内核中的ebpf程序完成了对网络传输层数据包的解密。219.此外，值得一提的是，decrypt函数还需要执行以下操作：从指定的bpfmap中获取管理程序传递的必要参数，如x25519加密算法相关参数、私钥、tcp端口号等；将一些运行统计数据记录到指定的bpfmap中，如加/解密包总数、成功/失败次数等。220.此外，值得一提的是，在实际应用中，运行在节点b的用户面中的管理程序除了在初始化阶段加载ebpf程序外，还要负责如下工作：通过bpfmap向decrypt函数传递必要的参数，如x25519加密算法相关参数、私钥、tcp端口号等；通过bpfmap读取汇总decrypt函数在运行时记录的统计数据，如解密包总数、成功/失败次数等；通过命令行(或其他形式，如restful等)接口，让用户可以管理查询ebpf程序的运行参数和运行状态。221.由此，实现了上层应用与ebpf程序的联合加密，在尽可能保证透明化的情况下，进一步提升了传输的数据的安全性。222.通过上述描述可知，本实施例提供的网络传输层数据处理方法，能够在系统环境配置与上层应用没有感知的情况下实现网络传输层通信加密，因此具备较低的部署成本和良好的环境与应用兼容性。同时，能够在运行时随时变更加密的算法、参数以及激活开关，上层应用也可以选择与该系统配合以实现自定义的联合加密保护机制，因此具备良好的灵活性和扩展能力。最后，由于基于ebpf技术，该方法在安全性和性能上也有保证。223.此外，应当理解的是，上面各种方法的步骤划分，只是为了描述清楚，实现时可以合并为一个步骤或者对某些步骤进行拆分，分解为多个步骤，只要包括相同的逻辑关系，都在本专利的保护范围内；对算法中或者流程中添加无关紧要的修改或者引入无关紧要的设计，但不改变其算法和流程的核心设计都在该专利的保护范围内。224.参见图9，图9是本技术实施例提供的网络传输层数据处理设备的结构示意图。225.如图9所示，本实施例提供的网络传输层数据处理设备包括：包括至少一个处理器901；以及，与至少一个处理器通信连接的存储器902。226.此外，为了能够实现全透明传输加密，或者根据业务需求与上层应用程序联合实现传输加密，网络传输层数据处理设备还包括运行在用户面的管理程序和运行在内核的ebpf程序。227.其中，管理程序用于向所在环境的内核加载，或者说注册ebpf程序，以使ebpf程序能够运行在内核中，存储器902存储有可被至少一个处理器901执行的指令，指令被至少一个处理器901执行，以使至少一个处理器901能够执行上述应用于管理程序的方法实施例所描述的网络传输层数据处理方法，或者应用于ebpf程序的方法实施例所描述的网络传输层数据处理方法。228.其中，存储器902和处理器901采用总线方式连接，总线可以包括任意数量的互联的总线和桥，总线将一个或多个处理器901和存储器902的各种电路连接在一起。总线还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路连接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口在总线和收发机之间提供接口。收发机可以是一个元件，也可以是多个元件，比如多个接收器和发送器，提供用于在传输介质上与各种其他装置通信的单元。经处理器901处理的数据通过天线在无线介质上进行传输，进一步，天线还接收数据并将数据传送给处理器901。229.处理器901负责管理总线和通常的处理，还可以提供各种功能，包括定时，外围接口，电压调节、电源管理以及其他控制功能。而存储器902可以被用于存储处理器901在执行操作时所使用的数据。230.本技术实施例还涉及一种计算机可读存储介质，存储有计算机程序。计算机程序被处理器执行时实现上述方法实施例所描述的网络传输层数据处理方法。231.即，本领域技术人员可以理解，实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本技术各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。232.本领域的普通技术人员可以理解，上述各实施例是实现本技术的具体实施例，而在实际应用中，可以在形式上和细节上对其作各种改变，而不偏离本技术的精神和范围。当前第1页12当前第1页12
背景技术：
：：2.当前，随着日益严峻的网络安全环境，系统间进程的网络传输层通信加密和其他安全保护措施变得越来越重要。linux作为目前业界主流的商用产品运行系统，提供了多种内置的网络传输层加密协议与相关实现。目前较为常见的网络传输层加密处理方法或机制有：互联网安全协议(internetprotocolsecurity，ipsec)和传输层安全协议(transportlayersecurity，tls)。如图1所示，在实际应用中，ipsec是工作在开发式系统互联通信参考模块(opensysteminterconnectionreferencemodel，osi模型)位于第三层的网络层，通过对ip协议包进行加密和认证来保护所有基于ip协议的通信；而tls则是工作在osi模型位于第四层的传输层，一般在一种可靠的传输层协议，如面向连接的传输控制协议(transmissioncontrolprotocol，tcp)、无连接的用户数据报协议(userdatagramprotocol，udp)基础上为上层应用提供数据安全和完整性保护，具体是采用客户端-服务器模型的方式，在两个应用程序之间创建一个安全的传输连接/隧道，以防止交互的数据被窃听或篡改。3.虽然上述加密处理方法或机制可以实现数据在内核的加密或解密处理，但是基于ipsec协议的方式，在实际应用中需要系统管理员修改系统的网络配置或连接拓扑，如创建新的虚拟网络设备、修改全局路由表等，即对系统运行环境有侵入式的配置需求；而基于tls协议的方式，在实际应用中需要应用程序主动发起并参与传输连接/隧道的建立过程，相关配置参数和敏感数据，如数字证书等一般也需要应用程序自身来维护，即对经验程序自身有侵入式配置需求。4.也就是说，对于传统的网络传输层加密处理方法，其对系统环境或上层应用是不透明的。它们需要系统环境或上层应用改变自身的状态，并参与到实际的加解密流程中。这种不透明带来了额外的部署、配置、运维以及开发的负担，同时也带来了额外的风险，如任何一个错误的配置或实现都可能导致数据保护失效，或是对系统环境造成不利影响，进而影响到其他应用。技术实现要素：5.本技术实施例的目的在于提供一种网络传输层数据处理方法、设备及存储介质，旨在解决上述技术问题。6.为解决上述技术问题，本技术的实施例提供了一种网络传输层数据处理方法，应用于运行在内核的扩展伯克利包过滤器ebpf程序，所述网络传输层数据处理方法包括：获取需要分发的网络传输层数据包；对所述网络传输层数据包进行解析，确定需要对所述网络传输层数据包进行的网络传输层数据处理方式；根据所述网络传输层数据处理方式，对所述网络传输层数据包进行处理。7.为实现上述目的，本技术实施例还提供了一种网络传输层数据处理方法，包括：应用于运行在用户面的管理程序，所述网络传输层数据处理方法包括：在所述管理程序启动后，监测是否接收到针对运行在内核的ebpf程序的操作指令和/或所述ebpf程序统计的针对网络传输层数据包处理过程中的统计数据；如果接收到针对所述ebpf程序的操作指令，根据所述操作指令对所述ebpf程序进行处理；如果接收到所述ebpf程序统计的针对网络传输层数据包处理过程中的统计数据，对所述统计数据进行处理。8.为实现上述目的，本技术实施例还提供了一种网络传输层数据处理设备，包括：运行在用户面的管理程序和运行在内核的ebpf程序，至少一个处理器；以及，与所述至少一个处理器通信连接的存储器；其中，所述管理程序用于向所在环境的内核加载所述ebpf程序，以使所述ebpf程序运行在所述内核，所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行如上所述的任意一种网络传输层数据处理方法。9.为实现上述目的，本技术实施例还提供了一种计算机可读存储介质，存储有计算机程序。所述计算机程序被处理器执行时实现上述所述的任意一种网络传输层数据处理方法。10.本技术实施例提出的网络传输层数据处理方法、设备及存储介质，通过在用户面加载并运行能够管理ebpf程序的管理程序，进而利用管理程序预先将ebpf程序注册到内核中，由ebpf程序去拦截需要内核分发，如发送出去的网络传输层数据包、接收的网络传输层数据包，并确定需要分发的网络传输层数据包的网络传输层数据处理方式，最终由ebpf程序根据确定的网络传输层数据处理方式，对当前拦截的网络传输层数据包进行处理。整个网络传输层数据处理过程在改写后的内核中的ebpf程序便可以完成，无需系统环境或上层应用改变自身的状态，并参与到实际的网络传输层数据处理过程中，做到了对系统环境或上层应用的透明化，从而无需额外的部署、配置、运维以及开发成本，也保证了良好的系统环境与上层应用的兼容性。11.除此之外，本实施例提供的网络传输层数据处理方案，除了单纯的基于加载在内核中的ebpf程序对网络传输层数据包进行加密或解密处理，还可以设置ebpf程序与上层应用，如运行在用户面的应用程序配合，实现联合加密或解密处理，从能够根据实际业务需求，在尽可能减小对上传应用修改的情况下，联合上层应用的加密/解密方式，进一步提升网络传输层数据包在传输过程中的安全性。12.此外，基于ebpf技术自身的安全性和高性能，也保证了本实施例提供的网络传输层数据处理方案的安全性和整体性能。附图说明13.一个或多个实施例通过与之对应的附图中的图片进行示例性说明，这些示例性说明并不构成对实施例的限定。14.图1是传统的ipsec协议、tls协议与osi模型的对应关系示意图；15.图2是本技术实施例提供的应用于管理程序的网络传输层数据处理方法的流程示意图；16.图3是本技术实施例提供的应用于管理程序的网络传输层数据处理方法的又一流程示意图；17.图4针对图2或图3所示的网络传输层数据处理方法中涉及的管理程序与ebpf程序之间的交互示意图；18.图5是本技术实施例提供的应用于ebpf程序的网络传输层数据处理方法的流程示意图；19.图6是本技术实施例提供的应用于ebpf程序的网络传输层数据处理方法的又一流程示意图；20.图7是基于本技术实施例提供的网络传输层数据处理方法在节点a和节点b之间实现全透明传输加密的示意图；21.图8是基于本技术实施例提供的网络传输层数据处理方法在节点a和节点b之间实现与上层应用程序联合加密的示意图；22.图9是本技术实施例提供的网络传输层数据处理设备的结构示意图。具体实施方式23.本技术实施例中术语“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。24.本技术实施例中术语“多个”是指两个或两个以上，其它量词与之类似。25.为使本技术实施例的目的、技术方案和优点更加清楚，下面将结合附图对本技术的各实施例进行详细的阐述。然而，本领域的普通技术人员可以理解，在本技术各实施例中，为了使读者更好地理解本技术而提出了许多技术细节。但是，即使没有这些技术细节和基于以下各实施例的种种变化和修改，也可以实现本技术所要求保护的技术方案。以下各个实施例的划分是为了描述方便，不应对本技术的具体实现方式构成任何限定，各个实施例在不矛盾的前提下可以相互结合相互引用。26.参见图2，图2是本技术实施例提供的网络传输层数据处理方法的流程图，在本实施例中，该方法主要应用于运行在用户面的管理程序。27.如图2所示，本实施例提供的网络传输层数据处理方法，包括以下步骤：28.步骤201，在管理程序启动后，监测是否接收到针对运行在内核的ebpf程序的操作指令和/或ebpf程序统计的针对网络传输层数据包处理过程中的统计数据。29.需要说明的，本实施例中所说的ebpf程序(extendedberkeleypacketfilter，扩展伯克利过滤器)其原本的目标是实现一种全新的包过滤器，以取代iptable(一种网络防火墙)，但是后续的演进对其功能进行了扩展。现在ebpf程序本质上是运行在内核里的特殊代码，用户可以在其规定的限制下编写功能代码，这些代码编译成字节码后将加载到内核里一个特殊的虚拟机内执行。因此，为了能够根据实际的业务需求对ebpf程序进行管理，本实施例提供了运行在用户面的管理程序，从而使得用户能够通过管理程序，实现对运行在内核中的ebpf程序的管理。30.基于上述论述，为了保证本实施例提供的网络传输层数据处理方法的实现，以及对ebpf程序的管理，管理程序不仅要负责向内核中加载，或者说注册ebpf程序，还提供了用户交互接口。31.具体的，上述所说管理程序向内核中加载ebpf程序，具体是将ebpf程序实现相应功能的字节码加载到内核的指定位置，以便当网络传输层数据包需要内核分发，如向外发送，或者接收时，到达内核的网络传输层数据包能够被加载在内核中的ebpf程序拦截，进而由ebpf程序根据对应的功能接口/函数对网络传输层数据包进行相应处理。32.相应地，管理程序提供的用户交互接口，具体用于接收用户作出的针对运行在内核中的ebpf程序的操作指令。33.进一步地，在一个例子中，管理程序还用于通过用户交互接口将ebpf程序反馈的处理网络传输层数据包过程中产生的统计数据，如成功加密的数量/解密的数量等，和/或ebpf程序的运行状态、当前配置参数等信息反馈给用户，供用户根据ebpf程序的当前运行情况进行后续操作。34.通过上述描述可知，管理程序启动后，具体是通过监测用户交互接口来确定当前是否有针对运行在内核的ebpf程序的操作指令，通过监测与内核中运行的ebpf程序交互的接口，如系统调用函数/接口(syscall)来确定是否接收到ebpf程序统计的针对网络传输层数据包处理过程中的统计数据。35.相应地，如果监测到接收到了针对运行在内核的ebpf程序的操作指令，则进入步骤202；如果监测到接收到了运行在内核的ebpf程序输出的网络传输层数据包，则进入步骤203。36.此外，应当理解的，在一个例子中，管理程序如果接收到运行在内核的ebpf程序反馈的当前状态信息，如解密成功的网络传输层数据包的数量、加密成功的网络传输层数据包的数量，以及ebpf程序当前进行加解密时依据的加解密条件、规则等，管理程序可以根据预先配置的业务需求，对接收到的上述信息进行存储和/或以预设形式展示，还或者通过用户交互接口反馈给用户。37.步骤202，根据操作指令对ebpf程序进行处理。38.具体的说，在一个例子中，管理程序通过用户交互接口接收到的针对运行在内核中的ebpf程序的操作指令分为如下3种：操作指令为配置信息更新指令，或者ebpf程序替换指令，或者ebpf程序卸载指令。39.相应地，针对上述3中不同的操作指令，管理程序对已经运行在内核中的ebpf程序进行的处理也有所差异，具体如下：40.(1)在操作指令为配置信息更新指令时，对已经运行在内核中的ebpf程序进行的处理具体为：41.首先，从配置信息更新指令中提取需要更新的配置信息。42.可理解的，本实施例中所说的配置信息包括加解密条件、加密规则、解密规则中的任意一种或几种。43.关于上述所说的加解密条件，具体为预先约定的针对采用哪类网络传输层协议、对应的四元组(源端口号、目的端口号、源ip地址、目的ip地址)的网络传输层数据包需要进行加密处理，或解密处理。44.相应地，上述所说的加密规则，至少包括了对需要进行加密处理的网络传输层数据包进行加密处理所采用的具体加密算法。45.进一步地，如果规定的加密算法需要用到密钥，则加密规则中还需要包括采用规定的加密算法进行加密所需的密钥。46.相应地，上述所述的解密规则，至少包括了对需要进行解密处理的网络传输层数据包进行解密处理所采用的具体解密算法。47.进一步地，如果规定的解密算法需要用到密钥，则解密规则中还需要包括采用规定的解密算法进行解密所需的密钥。48.此外，应当理解的，加密处理和解密处理通常是成对出现的，因而对于网络传输层数据包的发送方，比如节点a中运行在内核中的ebpf程序关于加密处理的相关配置信息需要与网络传输层数据包的接收方，比如b节点中运行在内核中的ebpf程序关于解密处理的相关配置信息是相互配合的。49.然后，根据提取的需要更新的配置信息对已经运行在内核中的ebpf程序对应的配置信息映射表更新。50.具体的说，本实施例中所说的配置信息映射表，即ebpf技术中涉及的bpfmap。在具体应用中，可以针对能够运行在内核中的不同ebpf程序分别设计一个对应的bpfmap，也可以设计一个全局的bpfmap，对于所有能够运行在内核中的ebpf程序都统一共用一个bpfmap。但不论哪种方式，在根据业务需要预先设计bpfmap时，均需将ebpf程序进行加密、解密等出来所需的参数定义到bpfmap中。51.相应地，基于设计好的bpfmap，管理程序在对运行在内核中的ebpf程序进行管理时，如配置信息的修改时，只需将需要修改的配置信息更新到该bpfmap中，ebpf程序被内核激活后，便会主动去bpfmap中查找需要的配置信息，然后根据查找到的配置信息作出相应操作。52.也就是说，bfpmap实质是内核提供的一种交换机制/通信机制，基于bpfmap运行在用户面的管理程序和运行在内核的ebpf程序便可以实现交互。53.(2)在操作指令为ebpf程序替换指令时，对已经运行在内核中的ebpf程序进行的处理具体为：54.首先，从ebpf程序替换指令中提取替换ebpf程序。55.然后，将替换ebpf程序注册到内核中，并在替换ebpf程序注册到内核后，卸载内核中运行的ebpf程序。56.(3)在操作指令为ebpf程序卸载指令时，对已经运行在内核中的ebpf程序进行的处理具体为：卸载内核中运行的ebpf程序。57.步骤203，对统计数据进行处理。58.具体的说，在一个例子中，管理程序在接收到ebpf程序提供的对网络传输层数据包进行加密/解密处理时统计的统计数据，如成功加密的数量或成功解密的数量时，对接收到的统计数据进行的处理可以是将统计数据存储到预设存储区域和/或以预设形式展示。59.此外，值得一提的是，在实际应用中，管理程序除了在接收到的操作指令是ebpf程序卸载指令，并卸载ebpf程序后会退出当前的消息处理操作，停止执行本实施例提供的网络传输层数据处理方法，其他情况下，如根据配置参数修改指令，或ebpf程序替换指令完成对已经运行在内核中的ebpf程序的处理后，以及对统计数据进行处理后，均会自动进入下一次消息处理。60.通过上述描述不难发现，本实施例提供的网络传输层数据处理方法，通过在用户面部署，并启动管理程序，由管理程序向内核中加载能够实现加解密处理的ebpf程序，并监测运行在内核中的ebpf程序的反馈，以及用户作出的操作指令，进而根据监测到的结果，在用户面直接作出相应结果，或者对运行在内核中的ebpf程序进行管理，从而实现对ebpf程序的动态管理。由于整个过程，无需系统环境或上层应用改变自身的状态，并参与到实际的网络传输层数据处理过程中，因此在系统环境、上层应用没有任何变更的情况下，便可以实现网络传输层数据的加解密处理。61.此外，由于管理程序直接对运行在内核中ebpf程序进行管理，因此能够在系统环境、上层应用没有感知的情况下，就可以实现对进行加解密处理的ebpf程序的激活、去激活，配置信息的变更等操作，从而能够动态的调整对需要传输的数据，即网络传输层数据包进行加解密处理，使得网络传输层数据处理能够更加满足实际变动的业务需要。62.基于此，本实施例提供的网络传输层数据处理方法，真正做到了对系统环境或上层应用的透明化，从而无需额外的部署、配置、运维以及开发成本，也保证了良好的系统环境与上层应用的兼容性。63.此外，基于ebpf技术自身的安全性和高性能，也保证了本实施例提供的网络传输层数据处理方案的安全性和整体性能。64.此外，在一个例子中，如果不追求绝对的透明，或者是有特殊的数据保护需求，ebpf程序也可以和上层应用配合起来完成对数据的加密或保护。例如，上层应用可以有意发送内容不合法的数据包，如果接收方的环境部署了对应的ebpf程序(同时参数配置正确)，那么在接收方内核看到数据前，ebpf程序可以将不合法的数据修复，然后再交由内核处理，从而让接收方应用能正确读取信息；如果接收方环境没有部署对应的ebpf程序(或者参数配置不正确)，那么接收方内核(以及可能正在监听传输线路的恶意中间人)会认为数据包非法而将其丢弃，从而保护了数据的安全。65.对于这种联合加密方式，如果节点，比如节点a是通过上层应用进行加密，则对于仅作为向外发送网络传输层数据包的节点a，在用户面可以不部署管理程序，内核中不加载ebpf程序。66.相应地，对于接收节点a通过上层应用加密的网络传输层数据包的节点b，则需要在用户面部署管理程序，在内核中记载ebpf程序，从而配合实现对网络传输层数据包的处理。67.参见图3，图3是本技术实施例提供的网络传输层数据处理方法的又一流程图，在本实施例中，该方法主要应用于运行在用户面的管理程序。68.在本实施例中，引入了管理程序向内核加载ebpf程序的具体操作，如图3所示，本实施例提供的网络传输层数据处理方法，包括以下步骤：69.步骤301，从预设地址读取配置信息。70.具体的说，为了保证内核有需要分发的网络传输层数据时，不管是向内，即内核从其他节点接收到的网络传输层数据包，还是向外，即内核需要发送给其他节点的网络传输层数据包，能够在到达内核时，被内核中运行的ebpf程序拦截，并由ebpf程序对拦截的网络传输层数据包进行相应的网络传输层数据处理，如加密处理或解密处理，需要保证内核中已经运行了ebpf程序。因此，在初次执行本实施例提供的网络传输层数据处理方法时，当管理程序被部署到用户面，并启动后，管理程序需要先从预设地址读取配置信息，比如从存储在用户面的某一配置信息文件中读取。71.此外，在本实施例中，管理程序从预设地址读取的配置信息同样包括加解密条件、加密规则、解密规则中的任意一种或几种。72.步骤302，检查需要注册到内核的ebpf程序和配置信息的完整性。73.具体的说，为了保证基于被注册到内核的ebpf程序处理网络传输层数据包的性能、安全性，管理程序在将预先设计好的ebpf程序注册到内核，将读取的配置信息配置到ebpf程序对应的配置信息映射表前，需要先检查ebpf程序和配置信息的完整性。74.步骤303，如果ebpf程序和配置信息均完整，将ebpf程序注册到内核中，以使ebpf程序运行在内核。75.具体为管理程序向所在环境的内核加载ebpf程序的字节码，并在将ebpf程序加载到内核中，后续通过系统调用函数/接口(syscall)与ebpf程序进行数据交换。76.此外，管理程序也向外提供管理和查询接口，如用户交互接口，以便根据外部输入的操作指令，对运行在内核中的ebpf程序进行相应处理。77.步骤304，将配置信息配置到ebpf程序对应的配置信息映射表中。78.具体的说，本实施例中所说的配置信息映射表，即ebpf技术中涉及到的bpfmap。在实际应用中，本实施例中提供的ebpf程序与管理程序之间可以通过一个或多个bpfmap进行配置数据或运行时统计的统计数据的交互。79.应当理解的是，上述示例仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。80.步骤305，进入消息处理循环操作。81.具体的说，上述所说的进入消息处理循环操作是指预先构建消息队列，在每次监测到有需要处理的消息，如针对ebpf程序的操作指令和/或ebpf程序在bpfmap中写入针对网络传输层数据包处理过程中统计的统计数据时，先将接收到的需要处理的消息添加到消息队列，然后依次从消息队列读取需要处理信息，根据当前读取的需要处理的信息的具体类型，进入步骤306至步骤309任一步骤，并执行对应的操作。82.步骤306，如果接收到针对ebpf程序的配置信息更新指令，从配置信息更新指令中提取需要更新的配置信息，根据提取的需要更新的配置信息对ebpf程序对应的配置信息映射表更新。83.步骤307，如果接收到针对ebpf程序的ebpf程序替换指令，从ebpf程序替换指令中提取替换ebpf程序，将替换ebpf程序注册到内核中，并在替换ebpf程序注册到内核后，卸载内核中运行的所述ebpf程序。84.步骤308，如果接收到针对ebpf程序的ebpf程序卸载指令，卸载内核中运行的所述ebpf程序。85.步骤309，如果ebpf程序统计的针对网络传输层数据包处理过程中的统计数据，将将统计数据存储到预设存储区域和/或以预设形式展示。86.不难发现，本实施例中的步骤306至步骤307与图2所示的实施例中步骤202和步骤203给出的几种具体处理方式大致相同，在此就不再赘述。87.此外，关于本实施例中所涉及的管理程序、需要读取的配置信息、ebpf程序以及外部输入之间的交互，具体如图4所示，此处不再赘述。88.由此，本实施例提供的网络传输层数据处理方法，在进行网络传输层数据处理之前，利用运行在用户面的管理程序向内核加载ebpf程序，并对ebpf程序进行配置管理，如将ebpf程序进行加解密处理时用到的配置信息配置到配置信息映射表，从而在有需要内核分发的网络传输层数据包时，能够由ebpf程序进行相应的加密处理、解密处理。89.参见图5，图5是本技术实施例提供的网络传输层数据处理方法的流程图，在本实施例中，该方法主要应用于运行在内核的ebpf程序。90.需要说明的，本实施例所说的网络传输层数据处理方法，具体是指运行在内核的ebpf程序对内核需要分发的网络传输层数据包的加密处理或解密处理。91.如图5所示，本实施例提供的网络传输层数据处理方法，包括以下步骤：92.步骤501，获取需要分发的网络传输层数据包。93.可理解的，本实施例中所说的需要分发的网络传输层数据包具体是指需要内核向本节点的上层应用，如运行在用户面上的应用程序分发接收到的网络传输层数据包，即需要分发的网络传输层数据包来自其他节点。94.此外，在一个例子中，需要分发的网络传输层数据包还可以是由内核向其他节点分发，即需要分发的网络传输层数据包是需要内核向其他节点发送的。95.此外，值得一提的是，在实际应用中，加载到内核中的ebpf程序，并非一直处于运行状态，或者说激活状态，只有在有需要分发的网络传输层数据包到达内核时，才会由内核触发，进而去执行本实施例中提供的网络传输层数据处理方法。96.相应地，上述获取到的需要分发的网络传输层数据包，实质是在内核触发ebpf程序后，传输给ebpf程序的。97.步骤502，对网络传输层数据包进行解析，确定需要对网络传输层数据包进行的网络传输层数据处理方式。98.具体的说，通常情况下网络传输层数据包的协议头中会携带传输该网络传输层数据包所采用的的协议、四元组等信息，因此在确定需要对网络传输层数据包进行的网络传输层数据处理方式时，通过对网络传输层数据包进行解析，进而提取网络传输层数据包的协议头，然后根据协议头和预先配置的加解密条件，判断该网络传输层数据包是否需要加密或解密。99.相应地，如果通过判断确定网络传输层数据包需要进行加密，则确定需要对网络传输层数据进行的网络传输层数据处理方式为加密处理方式；如果通过判断确定网络传输层数据包需要进行解密，则确定需要对网络传输层数据进行的网络传输层数据处理方式为解密处理。100.需要说明的是，本实施例中所说的加解密条件具体是由运行在用户面的管理程序提供的。在实际应用中，加解密条件可以是预先规定的好的针对哪些协议传输的网络传输层数据包进行加密或解密。101.进一步，加解密条件还可以是规定针对某一具体端口号(源端口号和/或目的端口号)、某一具体ip地址(源ip地址和/或目的ip地址)。102.应当理解的是，上述示例仅是为了更好的理解本实施例的技术方案而列举的示例，不作为对本实施例的唯一限制。103.此外，需要说明的，在实际应用中，在确定需要对网络传输层数据包进行的网络传输层数据处理方式之前，可以先确定网络传输层数据包是否需要进行网络传输层数据处理，如果不需要则直接交由内核进行后续分发操作，如果需要再确定需要进行的网络传输层数据处理方式。104.此外，在本实施例中，对需要分发的网络传输层数据包进行的网络传输层数据处理方式大致分为加密处理和解密处理。而在实际应用中，通常是对需要发送给其他节点的网络传输层数据包才进行加密处理，对从其他节点接收到的网络传输层数据包要进行的是解密处理。基于此，在确定需要对网络传输层数据包进行的网络传输层数据处理方式时，具体可以先确定当前的网络数据是需要发送出去的，还是接收到的。105.相应地，如果是接收到的，具体是判断网络传输层数据包是否需要解密；如果是需要发送出的，具体是判断网络传输层数据包是否需要加密。106.步骤503，根据网络传输层数据处理方式，对网络传输层数据包进行处理。107.具体的说，在确定的网络传输层数据处理方式为加密处理方式时，对网络传输层数据包进行的处理具体为：108.首先，从预先配置的加密规则中选取目标加密规则。109.具体的说，上述预先配置的加密规则同样是由运行在用户面的管理程序提供的。具体是由管理程序从预设地址读取包括了加密规则的配置信息，然后将读取到的配置信息配置到ebpf程序对应的配置信息映射表中。故而，上述选取目标加密规则的操作，具体是从配置信息映射表中选取适合当前需要进行加密处理的网络传输层数据包的加密规则。110.需要说明的是，在实际应用中，加密规则至少需要包括具体的加密算法。111.进一步地，对于需要涉及密钥的，加密规则还需要包括加密密钥，可以理解为加密参数。112.此外，关于如何选取适合当前需要进行加密处理的网络传输层数据包的目标加密规则，在实际应用中可以根据当前需要进行加密处理的网络传输层数据包的协议头的内容确定。113.比如，预先规定采用某一协议，或者某一特定端口号，或者某一ip地址对应的具体加密方法和密钥，进而在选取目标加密规则时，更加需要进行加密处理的网络传输层数据包的协议头便可以快速、准确的选取一个适合该网络传输层数据包的加密规则。114.此外，值得一提的是，在一个例子中，也可以是所有需要进行加密的网络传输层数据包均采用同一加密规则。115.然后，根据目标加密规则，对网络传输层数据包的载荷部分进行加密处理。116.接着，根据加密后的载荷部分，更新协议头，得到加密后的网络传输层数据包。117.由于进行加密处理之后，加密后的载荷部分的长度通常会与加密前的载荷部分的长度存在差异，因而为了保证加密处理后的网络传输层数据包在传输到其他节点后，不会因为协议头中记录的长度信息和实际接收到的网络传输层数据包的载荷部分的长度不一致，而将加密后的网络传输层数据包误认为非法数据。因此，在根据目标加密规则对网络传输层数据包的载荷部分进行加密处理之后，需要根据加密后的载荷部分更新协议头，进而保证最终得到加密后的网络传输层数据包的协议头记录的信息与加密后的载荷部份的长度一致。118.最后，将加密后的网络传输层数据包交由内核，由内核对加密后的网络传输层数据包进行分发。119.由此，实现了对需要分发网络传输层数据的加密处理。120.相应地，在确定的网络传输层数据处理方式为解密处理方式时，对网络传输层数据包进行的处理方式具体为：首先，从预先配置的解密规则中选取目标解密规则；然后，根据目标解密规则，对网络传输层数据包的载荷部分进行解密处理；接着，根据解密后的载荷部分，更新协议头，得到解密后的网络传输层数据包；最后，将解密后的网络传输层数据包交由内核，由内核对解密后的网络传输层数据包进行分发。121.可理解的，为了保证经ebpf程序加密处理后的网络传输层数据包在到达对端节点的内核中，能够运行在对端节点内核中的ebpf程序解密，解密规则需要与加密规则相对应，以保证加密后的网络传输层数据包能够被解密，进而还原出原始的网络传输层数据包。122.由此，本实施例提供的网络传输层数据处理方法，通过在用户面加载并运行能够管理ebpf程序的管理程序，进而利用管理程序预先将ebpf程序注册到内核中，由ebpf程序去拦截需要内核分发，如发送出去的网络传输层数据包、接收的网络传输层数据包，并确定需要分发的网络传输层数据包的网络传输层数据处理方式，最终由ebpf程序根据确定的网络传输层数据处理方式，对当前拦截的网络传输层数据包进行处理。整个网络传输层数据处理过程在改写后的内核中的ebpf程序便可以完成，无需系统环境或上层应用改变自身的状态，并参与到实际的网络传输层数据处理过程中，做到了对系统环境或上层应用的透明化，从而无需额外的部署、配置、运维以及开发成本，也保证了良好的系统环境与上层应用的兼容性。123.此外，在一个例子中，如果不追求绝对的透明，或者是有特殊的数据保护需求，ebpf程序也可以和上层应用配合起来完成对数据的加密或保护。例如，上层应用可以有意发送内容不合法的数据包，如果接收方的环境部署了对应的ebpf程序(同时参数配置正确)，那么在接收方内核看到数据前，ebpf程序可以将不合法的数据修复，然后再交由内核处理，从而让接收方应用能正确读取信息；如果接收方环境没有部署对应的ebpf程序(或者参数配置不正确)，那么接收方内核(以及可能正在监听传输线路的恶意中间人)会认为数据包非法而将其丢弃，从而保护了数据的安全。124.对于这种联合加密方式，如果节点，比如节点a是通过上层应用进行加密，则对于仅作为向外发送网络传输层数据包的节点a，在用户面可以不部署管理程序，内核中不加载ebpf程序。125.相应地，对于接收节点a通过上层应用加密的网络传输层数据包的节点b，则需要在用户面部署管理程序，在内核中记载ebpf程序，从而配合实现对网络传输层数据包的处理。126.此外，基于ebpf技术自身的安全性和高性能，也保证了本实施例提供的网络传输层数据处理方案的安全性和整体性能。127.此外，值得一提的是，由于ebpf程序是由运行在用户面的管理程序加载到内核中的，并且管理程序能够管理ebpf程序。因此，在实际应用中，如果运行在内核中的ebpf程序接收到了用户面的管理程序下发的配置信息更新指令，则根据配置信息更新指令，更新预先配置的配置信息，即配置在配置信息映射表中的配置信息，具体可以是加解密条件、加密规则、解密规则中的任意一种或几种。由此，实现了对运行在内核中的ebpf程序的动态更新，使得运行在内核中的ebpf程序能够更好的适应于实际的网络传输层数据处理需求。128.参见图6，图6是本技术实施例提供的网络传输层数据处理方法的流程图，在本实施例中，该方法主要应用于运行在内核的ebpf程序。129.如图6所示，本实施例提供的网络传输层数据处理方法，包括以下步骤：130.步骤601，获取需要分发的网络传输层数据包。131.不难发现，本实施例中的步骤601与图5所示的实施例中的步骤501大致相同，在此就不再赘述。132.步骤602，对网络传输层数据包进行解析，确定网络传输层数据包是否需要处理。133.具体的说，在实际应用中，需要内核分发的网络传输层数据包并非每一个都需要进行加密或解密处理，比如对于仅仅是相对端节点作出的收到其发送的信息或请求的响应。因此，在确定需要分发的网络传输层数据包的网络传输层数据处理方式前，可以先根据解析出的网络传输层数据包的协议头中携带的标识信息确定当前需要分发的网络传输层数据包是否需要进行加密处理或解密处理。134.相应地，如果确定网络传输层数据包需要进行处理，则进入步骤603，确定网络传输层数据包具体需要进行的网络传输层数据处理方式。反之，如果确定网络传输层数据包不需要处理，则直接进入步骤610，即直接将拦截的网络传输层数据包交由内核，由内核对其进行分发即可。135.步骤603，确定网络传输层数据包是需要发送的网络传输层数据包，还是接收到的网络传输层数据包。136.根据上述论述可知，对于需要进行网络传输层数据处理的网络传输层数据包，在网络传输层数据包是需要由内核发送至其他节点的网络传输层数据包时，需要进行的网络传输层数据处理方式为加密处理方式。137.相应地，对于需要进行网络传输层数据处理的网络传输层数据包是需要由内核反馈给上层应用，即位于用户面应用程序，或者说网络传输层数据包是内核从其他节点接收到的网络传输层数据包时，需要进行的网络传输层数据处理方式为解密处理方式。138.基于此，只需确定网络传输层数据包是需要发送的网络传输层数据包，还是接收到的网络传输层数据包便可以快速确定需要进行处理的网络传输层数据包的具体处理方式。139.相应地，如果确定网络传输层数据包是需要发送的网络传输层数据包，则进入步骤603。反之，如果确定网络传输层数据包是接收到的网络传输层数据包，则进入步骤607。140.步骤604，对网络传输层数据包的载荷部分进行加密。141.步骤605，更新网络传输层数据包的协议头。142.步骤606，将加密后的网络传输层数据包交由内核，由内核对加密后的网络传输层数据包进行分发。143.步骤607，对网络传输层数据包的载荷部分进行解密。144.步骤608，更新网络传输层数据包的协议头。145.步骤609，将解密后的网络传输层数据包交由内核，由内核对解密后的网络传输层数据包进行分发。146.步骤610，将网络传输层数据包交由内核，由内核对网络传输层数据包进行分发。147.由此，本实施例提供的网络传输层数据处理方法，通过利用ebpf程序，很好地解决了传统网络传输层数据传输加密协议在使用中对系统环境和上层应用带来的侵入影响，提供了更灵活、更强大的数据传输加密与保护功能，同时在安全性上有更好的隔离与保证。148.此外，需要说明的是，ebpf技术支持多种程序类型，不同类型的程序适用于不同的用途，而当前比较适合实现传输加密功能的类型是流量控制(trafficcontrol，tc)。因此，本实施例中所说的对网络传输层数据包进行加密处理或加密处理的ebpf程序，具体为tc类型的ebpf程序。通过在内核中加载tc类型的ebpf程序能够直接拦截linux内核对于网络传输层数据包的处理入口和出口，在内核对网络传输层数据包进行接收或发送前，tc程序就可以直接访问到缓存原始的网络传输层数据包的内存缓存区，然后根据原始的网络传输层数据包对应的内存缓存区地址，从内存缓存区获取需要处理的网络传输层数据包，接着对获取到网络传输层数据包进行相应的网络传输层数据处理操作，并在完成相应的网络传输层数据处理操作后，再交由内核，由内核对其进行分发处理。149.显然，通过利用tc类型的ebpf程序，就可以将数据加解密的具体实现和配置逻辑集成到一个软硬件单元中，从而在系统环境和上层应用都不了解任何细节的情况下完成网络传输层数据的加解密。再加上ebpf程序和内核一样，都是可以在运行时动态加载/卸载的，因此本实施例提供的网络传输层数据处理方法可以实现运行时的加解密功能激活/去激活，或动态替换加密算法和配置数据，而与此同时操作系统和上层应用对这些行为变更可以一无所知。150.此外，需要说明的是，本实施例中采用tc类型的ebpf程序是基于目前ebpf技术的现状而确定的，如果在后续ebpf技术的快速演进中，出现了其他适合的类型，依旧可以实现本实施例实现的方法。即，本实施例中采用tc类型的ebpf程序实现网络传输数据处理，只是一种具体的实现方式，对本实施例提供的技术方案本身并不构成任何限定。151.此外，在一个例子中，如果不追求绝对的透明，或者是有特殊的数据保护需求，ebpf程序也可以和上层应用配合起来完成对数据的加密或保护。例如，上层应用可以有意发送内容不合法的数据包，如果接收方的环境部署了对应的ebpf程序(同时参数配置正确)，那么在接收方内核看到数据前，ebpf程序可以将不合法的数据修复，然后再交由内核处理，从而让接收方应用能正确读取信息；如果接收方环境没有部署对应的ebpf程序(或者参数配置不正确)，那么接收方内核(以及可能正在监听传输线路的恶意中间人)会认为数据包非法而将其丢弃，从而保护了数据的安全。152.此外，为了更好的理解基于本实施例提供的应用于运行在用户面的管理程序的网络传输层数据处理方法和应用于运行在内核的ebpf程序的网络传输层数据处理，以下结合图7和图8，对基于管理程序和ebpf程序的配合实现的网络传输层数据处理，具体为加密和解密过程进行具体说明。153.首先，需要说明的是，在实际应用中，网络传输层数据包的接收方(以下称为数据接收方)和网络传输层数据包的发送方(以下称为数据发送方)必须是都使用linux系统的，同时内核版本需要大于4.3，且开启了ebpf相关功能。154.进一步地，数据通信双方，即数据发送方和数据接收方需要使用标准的网络传输层协议栈，如ip、tcp/udp通信。155.此外，可以理解的，在实际应用中，运行在用户面的管理程序和运行在内核的ebpf程序可以是封装在一个软件包sdk中，以软件形态进行分发与部署的，也可以是封装到一个便携式硬件内，以硬件单元的形态分发与部署的。156.此外，当前市面上一些主流厂商的网卡已经支持直接加载并运行ebpf程序。这意味着具体的网络传输层数据处理工作不再依赖操作系统内核完成，而是由网卡内的专用芯片来完成。因此，对于此类设备，ebpf程序可以直接加载到该设备内运行，只需要单独管理需要运行在用户面的管理程序，并建立二者通信即可。157.参见图7，图7为节点a和节点b之间实现全透明传输加密的示意图，即位于用户面的应用程序(上层应用)不参与加密、解密，整个传送加密过程，对于节点a和节点b的系统环境、上层应用均是没有感知的。158.为了便于后续描述，首先假定上层应用，即应用程序与加密系统(管理程序 ebpf程序)符合如下设定：159.上层应用以tcp协议在1080端口与另一个远端的相同应用通信，如图7中的节点a和节点b；节点a和节点b的网络设备均为eth0；ebpf程序的文件名称为ebpf.elf；ebpf程序中负责加密的函数名为encrypt；ebpf程序中负责解密的函数名为decrypt。160.对于管理程序，其需要在节点a和节点b上运行，并通过如下命令加载ebpf程序(具体是加载ebpf程序中的加密函数和解密函数)：161.加载ebpf程序中的加密函数：tcfilteradddeveth0egressbpfdaobjebpf.elfsecencrypt162.加载ebpf程序中的解密函数：tcfilteradddeveth0inressbpfdaobjebpf.elfsecdecrypt163.执行完上述两条加载命令后，不论是节点a的内核，还是节点b的内核在向eth0发送网络传输层数据包时(egress)，均会调用之前挂载的ebpf程序中的encrypt函数，并将原始的内核数据缓存(socketkernelbuffer，简称skb)指针传递给函数。164.对于encrypt函数的处理流程，具体如下：165.(1)对skb进行以太网协议分析(解析并剥离ethernet头)。166.(2)确定网络传输层数据包的载荷部分是否为ip协议，如果不是，则直接结束处理，即进入步骤(10)。167.(3)对载荷部分进行ip协议分析(解析并剥离ip头)，如果ip头的载荷协议指示不为tcp，则直接结束处理，即进入步骤(10)。168.(4)对载荷部分进行tcp协议分析(解析并剥离tcp头)，确定目的端口是否为1080，如果不是，则直接结束处理，即进入步骤(10)。169.(5)计算ip协议的数据载荷范围(起始指针与结束指针)。170.(6)使用流加密算法(rivestcipher4，rc4)对ip协议载荷进行加密。171.可理解的，上述给出的仅为一种具体的加密算法，在实际应用中，本领域技术人员可以根据需要选择加密算法，并将选择的加密算法发送至管理程序，由管理程序进行配置。172.(7)将加密后的数据写回(可利用内核中的bpfhelper函数中的bpf_skb_store_bytes)，并更新ip头(主要是长度与校验码，可以利用bpfhelper函数中的bpf_l3_csum_replace)。173.(8)调用内核中的bpfhelper函数：bpf_skb_adjust_room，更新skb。174.(9)结束处理(内核会继续完成更新后数据的发送工作)。175.由此，完成了ebpf程序对网络传输层数据包的加密处理。176.相应地，在执行加载命令后，不论是节点a的内核，还是节点b的内核从eth0接收到网络传输层数据包时(ingress)，均会调用之前挂载的ebpf程序中的decrypt函数，并将原始数据缓存(sk_buff，简称skb)指针传递给函数。177.对于decrypt函数的处理流程，具体如下：178.(1)对skb进行以太网协议分析(解析并剥离ethernet头)。179.(2)确定载荷部分是否为ip协议，如果不是，则直接结束处理，即进入步骤(9)。180.(3)进行ip协议分析(解析并剥离ip头)，如果ip头的载荷协议指示不为tcp，则直接结束处理，即进入步骤(9)。181.(4)对载荷部分进行tcp协议分析(解析并剥离tcp头)，如果格式正确，说明数据未加密，直接结束处理，即进入步骤(9)。182.(5)使用rc4算法对ip载荷部分进行解密处理。183.可理解的，由于上述加密过程是采用的rc4算法，因此解密过程中同样需要采用rc4算法。184.(6)对解密后的数据进行tcp协议头检查，如果数据是非法的，比如某个字段的取值不再合法范围内，或目的端口不为1080，则直接结束处理，即进入步骤(9)。185.(7)将解密后的数据写回(可利用bpfhelper函数:bpf_skb_store_bytes)，并更新ip头(主要是长度与校验码，可以利用bpfhelper函数：bpf_l3_csum_replace)。186.(8)调用内核中的bpfhelper函数：bpf_skb_adjust_room，更新skb。187.(9)结束处理(内核会继续完成更新后数据的接收工作)。188.由此，完成了ebpf程序对网络传输层数据包的解密处理。189.此外，值得一提的是，在实际应用中encrypt函数和decrypt函数还需要执行如下操作：190.从指定的配置信息映射表(bpfmap)中获取管理程序传递的必要参数，如rc4加密算法相关参数、tcp端口号等；将一些运行统计数据记录到指定的bpfmap中，如加/解密包总数、成功/失败次数等。191.此外，值得一提的是，管理程序除了在初始化阶段加载ebpf程序外，还要负责如下工作：通过bpfmap向encrypt函数和decrypt函数传递必要的参数，如rc4加密算法相关参数、tcp端口号等；通过bpfmap读取汇总encrypt函数和decrypt函数在运行时记录的统计数据，如加/解密包总数、成功/失败次数等；通过命令行(或其他形式，如restful等)接口，让用户可以管理查询ebpf程序的运行参数，如四元组信息(端口号、地址等)和运行状态，如成功加密/解密的数量，检测到多少非法或合法的数据等。192.通过上述描述可以发现，在全透明传输加密方式下，上层应用并不参与到网络传输层的加解密流程中，因此其完全不知晓底层传输加密系统采用的算法、参数、时机等细节，在发送和接收网络数据时也不考虑加解密，全部以明文格式处理。这样上层应用无需作任何操作或配置修改即可实现网络传输层数据的加解密，而且上层应用对加密流程细节一无所知，即使被攻击者攻陷，其也无法了解实际的加解密流程细节，也无法获取关键的加解bpfdaobjebpf.elfsecdecrypt。206.相应地，在执行完上述加载命令后，如节点b的内核从eth0接收到来自节点a发送的网络传输层数据包时(ingress)，会调用之前挂载的ebpf程序中的decrypt函数，并将skb指针传递给函数。207.关于decrypt函数的处理流程，具体如下：208.(1)对skb进行以太网协议分析(解析并剥离ethernet头)。209.(2)确定载荷部分是否为ip协议，如果不是，则直接结束处理，即进入步骤(8)。210.(3)进行ip协议分析(解析并剥离ip头)，如果ip头的载荷协议指示不为tcp，则直接结束处理，即进入步骤(8)。211.(4)对载荷部分进行tcp协议分析(解析并剥离tcp头)，如果格式非法或目的端口号不等于1080，则直接结束处理，即进入步骤(8)。212.(5)使用x25519算法和私钥对tcp载荷部分进行解密处理。213.可理解的，上述给出的仅为一种具体的解密算法，在实际应用中，本领域技术人员可以根据需要选择加密算法，并将选择的解密算法发送至管理程序，由管理程序进行配置。214.此外，可理解的，ebpf程序进行解密时所依据解密方法，需要与节点a中应用程序采用的加密方法相对应。215.(6)将解密后的数据写回(可利用bpfhelper函数中的bpf_skb_store_bytes)，并更新tcp与ip头(主要是长度与校验码，可以利用bpfhelper函数中的bpf_l3_csum_replace以及bpf_l4_csum_replace)。216.(7)调用内核中的bpfhelper函数中的bpf_skb_adjust_room，更新skb。217.(8)结束处理(内核会继续完成更新后数据的接收工作)。218.由此，在节点b中利用内核中的ebpf程序完成了对网络传输层数据包的解密。219.此外，值得一提的是，decrypt函数还需要执行以下操作：从指定的bpfmap中获取管理程序传递的必要参数，如x25519加密算法相关参数、私钥、tcp端口号等；将一些运行统计数据记录到指定的bpfmap中，如加/解密包总数、成功/失败次数等。220.此外，值得一提的是，在实际应用中，运行在节点b的用户面中的管理程序除了在初始化阶段加载ebpf程序外，还要负责如下工作：通过bpfmap向decrypt函数传递必要的参数，如x25519加密算法相关参数、私钥、tcp端口号等；通过bpfmap读取汇总decrypt函数在运行时记录的统计数据，如解密包总数、成功/失败次数等；通过命令行(或其他形式，如restful等)接口，让用户可以管理查询ebpf程序的运行参数和运行状态。221.由此，实现了上层应用与ebpf程序的联合加密，在尽可能保证透明化的情况下，进一步提升了传输的数据的安全性。222.通过上述描述可知，本实施例提供的网络传输层数据处理方法，能够在系统环境配置与上层应用没有感知的情况下实现网络传输层通信加密，因此具备较低的部署成本和良好的环境与应用兼容性。同时，能够在运行时随时变更加密的算法、参数以及激活开关，上层应用也可以选择与该系统配合以实现自定义的联合加密保护机制，因此具备良好的灵活性和扩展能力。最后，由于基于ebpf技术，该方法在安全性和性能上也有保证。223.此外，应当理解的是，上面各种方法的步骤划分，只是为了描述清楚，实现时可以合并为一个步骤或者对某些步骤进行拆分，分解为多个步骤，只要包括相同的逻辑关系，都在本专利的保护范围内；对算法中或者流程中添加无关紧要的修改或者引入无关紧要的设计，但不改变其算法和流程的核心设计都在该专利的保护范围内。224.参见图9，图9是本技术实施例提供的网络传输层数据处理设备的结构示意图。225.如图9所示，本实施例提供的网络传输层数据处理设备包括：包括至少一个处理器901；以及，与至少一个处理器通信连接的存储器902。226.此外，为了能够实现全透明传输加密，或者根据业务需求与上层应用程序联合实现传输加密，网络传输层数据处理设备还包括运行在用户面的管理程序和运行在内核的ebpf程序。227.其中，管理程序用于向所在环境的内核加载，或者说注册ebpf程序，以使ebpf程序能够运行在内核中，存储器902存储有可被至少一个处理器901执行的指令，指令被至少一个处理器901执行，以使至少一个处理器901能够执行上述应用于管理程序的方法实施例所描述的网络传输层数据处理方法，或者应用于ebpf程序的方法实施例所描述的网络传输层数据处理方法。228.其中，存储器902和处理器901采用总线方式连接，总线可以包括任意数量的互联的总线和桥，总线将一个或多个处理器901和存储器902的各种电路连接在一起。总线还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路连接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口在总线和收发机之间提供接口。收发机可以是一个元件，也可以是多个元件，比如多个接收器和发送器，提供用于在传输介质上与各种其他装置通信的单元。经处理器901处理的数据通过天线在无线介质上进行传输，进一步，天线还接收数据并将数据传送给处理器901。229.处理器901负责管理总线和通常的处理，还可以提供各种功能，包括定时，外围接口，电压调节、电源管理以及其他控制功能。而存储器902可以被用于存储处理器901在执行操作时所使用的数据。230.本技术实施例还涉及一种计算机可读存储介质，存储有计算机程序。计算机程序被处理器执行时实现上述方法实施例所描述的网络传输层数据处理方法。231.即，本领域技术人员可以理解，实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，该程序存储在一个存储介质中，包括若干指令用以使得一个设备(可以是单片机，芯片等)或处理器(processor)执行本技术各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(rom，read-onlymemory)、随机存取存储器(ram，randomaccessmemory)、磁碟或者光盘等各种可以存储程序代码的介质。232.本领域的普通技术人员可以理解，上述各实施例是实现本技术的具体实施例，而在实际应用中，可以在形式上和细节上对其作各种改变，而不偏离本技术的精神和范围。当前第1页12当前第1页12
再多了解一些
本文用于创业者技术爱好者查询，仅供学习研究，如用于商业用途，请联系技术所有人。
