CN117082142A - 数据包缓存方法、装置、电子设备及存储介质 - Google Patents

Abstract

本申请实施例公开了一种数据包缓存方法、装置、电子设备及存储介质，涉及数据处理技术领域。其中，数据包缓存方法通过根据预配置的匹配条件和处理逻辑对请求数据包进行处理，在缓存中快速响应并根据预设的构造逻辑构造响应数据包，可以根据实际需求对不同的应用程序的匹配条件、处理逻辑和构造逻辑进行配置，有效提高了内核缓存机制的可扩展性和响应速度，并在缓存表没有对应的响应数据时及时在应用程序响应后更新缓存，有效提高了缓存命中率。

Description

数据包缓存方法、装置、电子设备及存储介质

技术领域

本申请涉及数据处理技术领域，特别是涉及一种数据包缓存方法、装置、电子设备及存储介质。

背景技术

随着网络技术仿真验证平台应用的成熟与推广，越来越多的试验任务集中在几个超大规模的仿真平台上，这将会导致仿真平台需要处理的并发请求急剧增加。为了减少响应时长，目前很多应用程序都会采用缓存技术将已处理好的结果进行缓存，但是目前的缓存技术一般存在于用户态，请求数据包从进入到确定返回的结果，需要经过内核态中复杂的网络协议栈，甚至出现多次用户态与内核态之间的数据拷贝，从而导致占用很多机器资源，最终应用程序在大数据流的场景下，性能急剧下降。

然而内核态的缓存机制可以使得请求数据包无需经过网络协议栈和用户态，从而减少了用户态与内核态之间数据拷贝带来的开销，因此应用程序可以利用内核缓存进一步提高系统的性能和响应速度。但是相关技术中内核态的缓存机制扩展性差，不支持多种应用程序同时使用缓存框架，而且存在不同的应用程序缓存设置不灵活、缓存命中率低和处理流程冗余等问题。

发明内容

本申请旨在至少解决现有技术中存在的技术问题之一。为此，本申请实施例提供了一种数据包缓存方法、装置、电子设备及存储介质，能够根据预配置的逻辑对请求数据包进行处理，在内核缓存中快速响应并更新缓存，有效提高了缓存命中率和内核缓存的可扩展性。

第一方面，本申请实施例提供了一种数据包缓存方法，包括：

响应于用户的请求指令，获取请求数据包；

对所述请求数据包进行第一解析，得到匹配参数，并将所述匹配参数与预设的匹配条件进行匹配，得到匹配结果；

若所述匹配结果表征所述请求数据包与目标应用程序匹配，利用预配置的所述目标应用程序的处理逻辑对所述请求数据包进行第二解析，得到解析数据；

基于所述解析数据，查询缓存表是否缓存所述请求数据包的数据哈希值，得到缓存标识；

若所述缓存标识表征所述缓存表已缓存所述请求数据包的数据哈希值，根据所述缓存表和预配置的所述目标应用程序的构造逻辑构造所述请求数据包的响应数据包；

若所述缓存标识表征所述缓存表未缓存所述请求数据包的数据哈希值，基于所述解析数据初始化所述缓存表，将所述请求数据包发送至所述目标应用程序进行响应，得到响应数据包，并基于所述响应数据包更新所述缓存表。

在本申请的一些实施例中，所述对所述请求数据包进行第一解析，得到匹配参数，并将所述匹配参数与预设的匹配条件进行匹配，得到匹配结果，包括：

对所述请求数据包的头部信息进行网络协议解析，得到所述匹配参数；所述匹配参数包括以下至少一种：源端口、源地址、目的端口、目的地址和协议信息；

依次将所述源地址、所述目的地址、所述源端口、所述目的端口、所述协议信息与所述匹配条件进行匹配，根据最长匹配原则得到应用程序标识；

判断所述应用程序标识与所述目标应用程序是否匹配，得到匹配结果。

在本申请的一些实施例中，所述若所述匹配结果表征所述请求数据包与目标应用程序匹配，利用预配置的所述目标应用程序的处理逻辑对所述请求数据包进行第二解析，得到解析数据，包括：

若所述匹配结果为所述应用程序标识与所述目标应用程序匹配，根据所述应用程序标识获取处理逻辑名称；所述应用程序标识与所述处理逻辑名称满足第一映射关系；

基于所述处理逻辑名称，调用预配置的所述目标应用程序的处理逻辑对所述请求数据包进行第二解析，得到所述解析数据；所述解析数据包括以下至少一种：请求信息、所述协议信息、所述源端口、所述源地址、所述目的端口和所述目的地址，所述请求信息包括URL信息。

在本申请的一些实施例中，所述缓存表包括第一哈希表，所述第一哈希表的键属性包括以下至少一种：请求源端口、请求源地址、请求目的端口、请求协议信息和请求URL信息，所述第一哈希表的值属性包括：请求数据哈希值；所述基于所述解析数据，查询缓存表是否缓存所述请求数据包的数据哈希值，得到缓存标识，包括：

将所述解析数据中的源端口作为请求源端口，源地址作为请求源地址，目的端口作为请求目的端口，协议信息作为请求协议信息，URL信息作为请求URL信息；

组合所述请求源端口、所述请求源地址、所述请求目的端口、所述请求协议信息和所述请求URL信息，得到待匹配键；

基于所述待匹配键，查询所述第一哈希表是否缓存对应的请求数据哈希值，得到缓存标识；所述请求数据哈希值与所述请求数据包的数据哈希值对应。

在本申请的一些实施例中，所述第一哈希表的值属性还包括：响应缓存；所述若所述缓存标识表征所述缓存表已缓存所述请求数据包的数据哈希值，根据所述缓存表和预配置的所述目标应用程序的构造逻辑构造所述请求数据包的响应数据包，包括：

若所述缓存标识表征所述第一哈希表已缓存所述请求数据包的数据哈希值，基于所述待匹配键获取所述第一哈希表中的所述请求数据包对应的所述响应缓存；

根据所述应用程序标识获取构造逻辑名称；所述应用程序标识与所述构造逻辑名称满足第二映射关系；

基于所述构造逻辑名称，调用预配置的所述目标应用程序的构造逻辑对所述响应缓存进行构造，得到初始响应数据包；

将所述解析数据中的源端口和目的端口、源地址和目的地址进行交换，并计算校验信息，得到重定向信息；

根据所述初始响应数据包和所述重定向信息，得到所述响应数据包。

在本申请的一些实施例中，所述第一哈希表的值属性还包括：缓存状态和响应缓存；所述缓存表还包括第二哈希表，所述第二哈希表的键属性为请求数据哈希值，所述第二哈希表的值属性包括以下至少一种：请求源端口、请求源地址、请求目的端口、请求协议信息和请求URL信息；所述若所述缓存标识表征所述缓存表未缓存所述请求数据包的数据哈希值，基于所述解析数据初始化所述缓存表，将所述请求数据包发送至所述目标应用程序进行响应，得到响应数据包，并基于所述响应数据包更新所述缓存表，包括：

若所述缓存标识表征所述第一哈希表未缓存所述请求数据包的数据哈希值，计算所述请求数据包的数据哈希值；

将所述解析数据中的源端口作为请求源端口，源地址作为请求源地址，目的端口作为请求目的端口，协议信息作为请求协议信息，URL信息作为请求URL信息；

组合所述请求源端口、所述请求源地址、所述请求目的端口、所述请求协议信息和所述请求URL信息，得到初始键；

基于所述初始键，将所述数据哈希值作为请求数据哈希值缓存至所述第一哈希表中，并初始化所述缓存状态为不可用状态，所述响应缓存为空；

将所述请求数据包发送至所述目标应用程序进行响应，得到所述响应数据包；

获取并解析所述响应数据包，得到响应数据；所述响应数据包括以下至少一种：响应信息、所述源端口、所述源地址、所述目的端口和所述目的地址；

根据所述源端口、所述源地址、所述目的端口和所述目的地址获取对应的请求数据包，并基于所述请求数据包计算对应的数据哈希值；

将所述数据哈希值作为请求数据哈希值，并将所述请求数据哈希值作为所述第二哈希表的待匹配键，查询得到对应的所述解析数据；

将所述解析数据作为所述第一哈希表的待匹配键，将所述响应信息作为所述响应缓存并缓存至所述第一哈希表中，并更新所述缓存状态为可用状态。

在本申请的一些实施例中，所述将所述请求数据包发送至所述目标应用程序进行响应，得到所述响应数据包之前，还包括：

将所述数据哈希值作为请求数据哈希值，并将所述请求数据哈希值作为所述第二哈希表的键属性，将所述初始键作为所述第二哈希表的值属性；

将所述键属性和所述值属性存储至所述第二哈希表。

在本申请的一些实施例中，所述方法还包括：基于所述解析数据，预测不同的请求数据得到后续请求指令的请求概率，并基于所述请求概率更新所述缓存表，包括：

对所述解析数据进行预处理，得到待预测的请求数据；所述请求数据包括以下至少一种：应用程序标识、源端口、源地址、请求信息、请求时间和命中状态，所述命中状态为第一状态代表所述请求数据包在所述缓存表中有响应缓存，所述命中状态为第二状态代表所述请求数据包在所述缓存表中无响应缓存，所述命中状态为第三状态代表所述请求数据包不在所述缓存表中；

将待预测的请求数据和历史的请求数据输入至预测模型进行预测，得到各个所述请求数据对应的请求指令的请求概率；所述预测模型为预训练的LSTM预测模型；

基于所述请求概率，计算所述缓存表中的各个缓存项的权重，得到权重信息；所述缓存表中存储多个缓存项，所述缓存项包括键属性和值属性；

根据所述权重信息，替换权重最小的所述缓存项，以更新所述缓存表。

在本申请的一些实施例中，所述应用程序有多个，每个所述应用程序具有唯一的应用程序标识；所述响应于的请求指令，获取请求数据包之前，还包括：根据预设接口和所述应用程序标识，对所述匹配条件、所述处理逻辑和所述构造逻辑进行配置，包括：

基于第一接口和所述应用程序标识，配置对应的所述应用程序的匹配条件，并将不同的所述应用程序的所述匹配条件以树形结构存储；所述匹配条件包括所述应用程序标识和协议信息；

基于第二接口和所述应用程序标识，配置对应的所述应用程序的处理逻辑，并将所述处理逻辑进行命名得到处理逻辑名称；所述应用程序标识和所述处理逻辑名称满足第一映射关系；

基于第三接口和所述应用程序标识，配置对应的所述应用程序的构造逻辑，并将所述构造逻辑进行命名得到构造逻辑名称；所述应用程序标识和所述构造逻辑名称满足第二映射关系。

第二方面，本申请实施例还提供了一种数据包缓存装置，应用如本申请第一方面实施例所述的数据包缓存方法，包括：

数据包响应模块，用于响应于用户的请求指令，获取请求数据包；

第一解析模块，用于对所述请求数据包进行第一解析，得到匹配参数，并将所述匹配参数与预设的匹配条件进行匹配，得到匹配结果；

第二解析模块，用于若所述匹配结果表征所述请求数据包与目标应用程序匹配，利用预配置的所述目标应用程序的处理逻辑对所述请求数据包进行第二解析，得到解析数据；

缓存查询模块，用于基于所述解析数据，查询缓存表是否缓存所述请求数据包的数据哈希值，得到缓存标识；

数据包构造模块，用于若所述缓存标识表征所述缓存表已缓存所述请求数据包的数据哈希值，根据所述缓存表和预配置的所述目标应用程序的构造逻辑构造所述请求数据包的响应数据包；

缓存更新模块，用于若所述缓存标识表征所述缓存表未缓存所述请求数据包的数据哈希值，基于所述解析数据初始化所述缓存表，将所述请求数据包发送至所述目标应用程序进行响应，得到响应数据包，并基于所述响应数据包更新所述缓存表。

在本申请的一些实施例中，所述装置还包括：

缓存预测模块，用于基于所述解析数据，预测不同的请求数据得到后续请求指令的请求概率，并基于所述请求概率更新所述缓存表。

在本申请的一些实施例中，所述装置还包括：

预配置模块，用于根据预设接口和应用程序标识，对所述匹配条件、所述处理逻辑和所述构造逻辑进行配置。

第三方面，本申请实施例还提供了一种电子设备，包括存储器、处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现如本申请第一方面实施例所述的数据包缓存方法。

第四方面，本申请实施例还提供了一种计算机可读存储介质，所述存储介质存储有程序，所述程序被处理器执行实现如本申请第一方面实施例所述的数据包缓存方法。

本申请实施例至少包括以下有益效果：

本申请实施例提供了一种数据包缓存方法、装置、电子设备及存储介质，其中，方法通过响应于用户的请求指令，获取请求数据包并进行第一解析，得到匹配参数并与预设的匹配条件进行匹配，若得到的匹配结果表征请求数据包与目标应用程序匹配，则利用预配置的处理逻辑进行第二解析，得到解析数据并进一步查询目标应用程序对应的缓存表是否缓存请求数据包的数据哈希值，若得到的缓存标识表征缓存表已缓存数据哈希值，则根据缓存表和预配置的构造逻辑构造请求数据包的响应数据包，若缓存标识表征缓存表未缓存数据哈希值，则基于解析数据初始化缓存表并将请求数据包发送至目标应用程序进行响应，得到响应数据包后再对应更新缓存表。由此根据预配置的处理逻辑对请求数据包进行处理，在缓存中快速响应并根据预设的构造逻辑构造响应数据包，可以对不同的应用程序的处理逻辑和构造逻辑进行配置，提高了缓存机制的可扩展性和响应速度，并在缓存表没有对应的响应数据时及时更新缓存有效提高了缓存命中率。

本申请的附加方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本申请的实践了解到。

附图说明

本申请的上述和/或附加的方面和优点从结合下面附图对实施例的描述中将变得明显和容易理解，其中：

图1是本申请一个实施例提供的数据包缓存方法的流程示意图；

图2是图1中步骤S101之前的流程示意图；

图3是本申请一个实施例提供的匹配条件树形结构示意图；

图4是图1中步骤S102的流程示意图；

图5是图1中步骤S103的流程示意图；

图6是图1中步骤S104的流程示意图；

图7是图1中步骤S105的流程示意图；

图8是图1中步骤S106的流程示意图；

图9是图8中步骤S705之前的流程示意图；

图10是本申请另一个实施例提供的数据包缓存方法的流程示意图；

图11是本申请一个实施例提供的e-cache缓存框架示意图；

图12是本申请一个实施例提供的入链处理模块流程图；

图13是本申请一个实施例提供的缓存更新流程图；

图14是本申请一个实施例提供的智能内存管理模块流程图；

图15是本申请一个实施例提供的数据包缓存装置模块示意图；

图16是本申请另一个实施例提供的数据包缓存装置模块示意图；

图17是本申请一个实施例提供的电子设备的结构示意图。

附图标记：数据包响应模块 100、第一解析模块 200、第二解析模块 300、缓存查询模块 400、数据包构造模块 500、缓存更新模块 600、缓存预测模块 700、预配置模块800、电子设备 1000、处理器 1001、存储器 1002。

具体实施方式

为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及实施例，对本申请进行进一步详细说明。应当理解，此处所描述的具体实施例仅用以解释本申请，并不用于限定本申请。

下面详细描述本申请的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，仅用于解释本申请，而不能理解为对本申请的限制。

在本申请的描述中，需要理解的是，涉及到方位描述，例如上、下、前、后、左、右等指示的方位或位置关系为基于附图所示的方位或位置关系，仅是为了便于描述本申请和简化描述，而不是指示或暗示所指的装置或元件必须具有特定的方位、以特定的方位构造和操作，因此不能理解为对本申请的限制。

在本申请的描述中，若干的含义是一个或者多个，多个的含义是两个以上，大于、小于、超过等理解为不包括本数，以上、以下、以内等理解为包括本数。如果有描述到第一、第二只是用于区分技术特征为目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量或者隐含指明所指示的技术特征的先后关系。

本申请的描述中，除非另有明确的限定，设置、安装、连接等词语应做广义理解，所属技术领域技术人员可以结合技术方案的具体内容合理确定上述词语在本申请中的具体含义。

随着网络技术仿真验证平台应用的成熟与推广，越来越多的试验任务集中在几个超大规模的仿真平台上，这将会导致仿真平台需要处理的并发请求急剧增加。为了减少响应时长，目前很多应用程序都会采用缓存技术将已处理好的结果进行缓存，当有相同的请求出现时，就能减少计算和响应时间，直接将缓存的结果返回给请求方。但是目前的缓存技术一般存在于用户态，请求数据包从进入到确定返回的结果，需要经过内核态中复杂的网络协议栈，甚至出现多次用户态与内核态之间的数据拷贝，从而导致占用很多机器资源，最终应用程序在大数据流的场景下，性能急剧下降。

目前通用的方式是通过搭建集群解决单机处理能力不足的问题，虽然提升应用服务的总体性能，但是对于单机的处理能力依然无法得到完全释放，而且通过集群只能减少因请求排队而带来的响应延迟，却无法在单个请求进一步提升响应速度。因此，相关技术中利用XDP技术为MemCache在内核中增加缓存机制，使得请求数据包无需经过内核态的网络协议栈和用户态，减少了用户态与内核态之间数据拷贝带来的开销。但是其只能针对MemCache应用，扩展性差，不支持多种应用程序同时使用缓存框架，而且存在不同的应用程序缓存设置不灵活、缓存命中率低、处理流程冗余以及无法支持多种应用程序智能缓存管理等问题。

基于此，本申请实施例提供了一种数据包缓存方法、装置、电子设备及存储介质，能够根据预配置的处理逻辑对请求数据包进行处理，在缓存中快速响应并根据预设的构造逻辑构造响应数据包，可以对不同的应用程序的处理逻辑和构造逻辑进行配置，提高了缓存机制的可扩展性和响应速度，并在缓存表没有对应的响应数据时及时更新缓存提高了缓存命中率。

本申请实施例提供数据包缓存方法、装置、电子设备及存储介质，具体通过如下实施例进行说明，首先描述本申请实施例中的数据包缓存方法。

本申请实施例提供的数据包缓存方法，涉及网络通信技术领域，尤其涉及数据处理技术领域。本申请实施例提供的数据包缓存方法可应用于终端中，也可应用于服务器端中，还可以是运行于终端或服务器端中的计算机程序。举例来说，计算机程序可以是操作系统中的原生程序或软件模块；可以是本地(Native)应用程序(APP，Application)，即需要在操作系统中安装才能运行的程序，如支持数据包缓存的客户端，即只需要下载到浏览器环境中就可以运行的程序。总而言之，上述计算机程序可以是任意形式的应用程序、模块或插件。其中，终端通过网络与服务器进行通信。该数据包缓存方法可以由终端或服务器执行，或由终端和服务器协同执行。

在一些实施例中，终端可以是智能手机、平板电脑、笔记本电脑、台式计算机或者智能手表等。服务器可以是独立的服务器，也可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、内容分发网络(ContentDelivery Network，CDN)、以及大数据和人工智能平台等基础云计算服务的云服务器；也可以是区块链系统中的服务节点，该区块链系统中的各服务节点之间组成点对点（P2P，PeerTo Peer）网络，P2P协议是一个运行在传输控制协议（TCP，Transmission ControlProtocol）协议之上的应用层协议。服务器上可以安装数据包缓存系统的服务端，通过该服务端可以与终端进行交互，例如服务端上安装对应的软件，软件可以是实现数据包缓存方法的应用等，但并不局限于以上形式。终端与服务器之间可以通过蓝牙、USB（UniversalSerial Bus，通用串行总线）或者网络等通讯连接方式进行连接，本实施例在此不做限制。

本申请可用于众多通用或专用的计算机系统环境或配置中。例如：个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器系统、基于微处理器的系统、置顶盒、可编程的消费电子设备、网络PC、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构等等。也可以在分布式计算环境中实践本发明，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

下面描述本发明实施例中的数据包缓存方法。

参照图1所示，本申请实施例提供了一种数据包缓存方法，应用于内核缓存机制，包括但不限于以下步骤S101至步骤S106。

步骤S101，响应于用户的请求指令，获取请求数据包。

在一些实施例中，响应于用户的请求指令，通过XDP钩子函数获取对应的请求数据包。可以理解的是，XDP（eXpress Data Path）是一种高性能的数据包处理技术，可以在网络接口的驱动程序中处理数据包，具体的，XDP钩子函数在请求数据包到达内核态的网络协议栈之前获取并对请求数据包进行过滤和处理等，本实施例对此不做限制。

在一些实施例中，用户的请求指令是基于用户所使用的应用程序发出的，示例性的，当用户使用浏览器搜索时，会对应产生搜索相关的请求指令；又例如当用户登录软件时，会对应产生登录相关的请求指令。可以理解的是，应用程序可以是浏览器或软件等任何需要内核缓存的应用程序，本实施例对此不做限制。

步骤S102，对请求数据包进行第一解析，得到匹配参数，并将匹配参数与预设的匹配条件进行匹配，得到匹配结果。

在一些实施例中，通过XDP钩子函数获取请求数据包后，在内核态中对该请求数据包进行第一解析，得到匹配参数。可以理解的是，第一解析只会获取基础网络协议内的头部信息进行解析，而不会对负载信息或者应用程序所使用的特殊协议或者加密协议等进行解析。具体的，对请求数据包的解析从第一层物理层开始，然后依次解析数据链路层、网络层、传输层和应用层。本实施的第一解析是从物理层解析至传输层，可以利用内核态自带的解析工具完成第一解析，从而得到匹配参数。

在一些实施例中，将匹配参数与预设的匹配条件进行匹配，得到匹配结果，匹配结果用于表征请求数据包与目标应用程序是否匹配。可以理解的是，由于不同的应用程序各自对应不同的内核缓存，通过对不同的应用程序预设不同的匹配条件，据此判断该应用程序是否为请求数据包请求的应用程序，以便进一步在其内核缓存中继续响应。

步骤S103，若匹配结果表征请求数据包与目标应用程序匹配，利用预配置的目标应用程序的处理逻辑对请求数据包进行第二解析，得到解析数据。

在一些实施例中，如果匹配结果表征请求数据包与目标应用程序匹配，代表该请求数据包的请求对象为目标应用程序，因此可以进一步在目标应用程序的内核缓存中继续响应。具体的，利用预配置的目标应用程序的处理逻辑对该请求数据包进行第二解析，得到解析数据。本实施例中的第二解析为应用层解析，通过对不同的应用程序预配置不同的处理逻辑进行第二解析，有效提高了内核缓存机制的可扩展性。

步骤S104，基于解析数据，查询缓存表是否缓存请求数据包的数据哈希值，得到缓存标识。

在一些实施例中，根据解析数据，查询缓存表是否缓存请求数据包的数据哈希值，从而得到缓存标识。其中，数据哈希值可以将请求数据包进行哈希，比如使用常见的MD5、SHA1、SHA256等哈希函数进行计算，或者使用特征提取算法进行哈希，比如对请求数据包提取关键字、特定的字段或者特征向量等再使用哈希函数进行计算。可以理解的是，相同的数据请求包具有相同的数据哈希值，因此将解析数据作为缓存表的索引，可以查询缓存表是否缓存有该请求数据包的数据哈希值。

步骤S105，若缓存标识表征缓存表已缓存请求数据包的数据哈希值，根据缓存表和预配置的目标应用程序的构造逻辑构造请求数据包的响应数据包。

在一些实施例中，如果缓存标识表征缓存表已缓存请求数据包的数据哈希值，代表该目标应用程序的内核缓存中缓存有该请求数据包的响应数据，因此根据缓存表获取对应的响应数据，并根据预配置的目标应用程序的构造逻辑可以快速响应然后构造出请求数据包对应的响应数据包。可以理解的是，不同的应用程序可以预配置响应数据包的不同构造逻辑，从而有效提高了内核缓存机制的可扩展性，提高了请求的响应速度。

步骤S106，若缓存标识表征缓存表未缓存请求数据包的数据哈希值，基于解析数据初始化缓存表，将请求数据包发送至目标应用程序进行响应，得到响应数据包，并基于响应数据包更新缓存表。

在一些实施例中，如果缓存标识表征缓存表未缓存请求数据包的数据哈希值，代表该目标应用程序的内核缓存中未缓存有该请求数据包的响应数据，因此需要将请求数据包发送至目标应用程序进行响应，具体的，将请求数据包上传到内核态的网络协议栈中，然后传输至目标应用程序进行响应，从而得到响应数据包。

在一些实施例中，还基于请求数据包的解析数据对缓存表进行初始化，在目标应用程序响应后，再获取响应数据包更新缓存表，从而将该请求数据包及其响应数据缓存至缓存中，实现了缓存表的及时更新，有效提高了内核缓存的命中率。

在本申请的一些实施例中，每个应用程序具有唯一的应用程序标识，本实施例中使用App_key代表应用程序标识，由此通过App_key标识对应的应用程序。参照图2所示，上述步骤S101之前还可以包括根据预设接口和应用程序标识，对匹配条件、处理逻辑和构造逻辑进行配置，具体包括但不限于以下步骤S201至步骤S203。

步骤S201，基于第一接口和应用程序标识，配置对应的应用程序的匹配条件，并将不同的应用程序的匹配条件以树形结构存储。

在一些实施例中，第一接口为匹配条件配置函数，通过接收用户输入的相关的参数，例如应用程序标识和匹配条件即可完成对应的应用程序的匹配条件的配置。具体的，根据第一接口和应用程序标识，可以配置对应的应用程序的匹配条件。具体的，匹配条件包括应用程序标识和协议信息，所使用的协议信息可以是从网络层到应用层的协议信息，匹配条件还可以包括源端口、源地址、目的端口、目的地址和请求信息等中的一种或多种，可以理解的是，本领域技术人员可以根据实际需求通过第一接口设置应用程序的匹配条件，本实施例对此不做限制。

在一些实施例中，为了快速准确地响应用户的请求指令，各个应用程序的匹配条件以树形结构存储。示例性的，有三个应用程序需要使用内核缓存，具体配置app1的匹配条件为{App_key:”app1”,Dest_IP:”192:10:2:1”,Dest_port:123,Protocols:”IP-TCP”}；配置app2的匹配条件为{App_key:”app2”,Dest_port:13,Protocols:”IP-UDP”}；配置app3的匹配条件为{App_key:”app3”,Dest_IP:”192:10:2:1”,Protocols:”IP-TCP”}，则形成如图3所示的匹配条件树形结构示意图。可以理解的是，本实施例中使用Protocols代表协议信息、Source_port代表源端口、Source_IP代表源地址、Dest_port代表目的端口、Dest_IP代表目的地址和URL代表请求信息。具体的，根据协议信息逐层对匹配条件进行分析，如果存在匹配条件，则在树形结构中新增一个分支进行匹配，如果缺失某个匹配条件，则统一将该匹配条件设置为无约束，本实施例对此不做限制。

步骤S202，基于第二接口和应用程序标识，配置对应的应用程序的处理逻辑，并将处理逻辑进行命名得到处理逻辑名称。

在一些实施例中，第二接口为处理逻辑配置函数，通过接收用户输入的相关的参数，例如应用程序标识、处理逻辑名称和处理逻辑，即可完成对应的应用程序的处理逻辑的配置。具体的，通过第二接口和应用程序标识，可以配置对应的应用程序的处理逻辑。具体的，通过App_key标识配置的处理逻辑属于哪个应用程序，并使用处理逻辑名称Process_name对处理逻辑Process进行命名，即将Process以Process_name命名，并且App_key和Process_name满足第一映射关系。

在一些实施例中，第一映射关系为哈希表，App_key作为哈希表的键，Process_name作为哈希表的值，由此可以通过App_key获取Process_name，从而调用对应的Process处理该应用程序的请求数据包。可以理解的是，第二接口的请求参数包括App_key、Process_name和Process，由此实现了对不同的应用程序配置不同的处理逻辑。

步骤S203，基于第三接口和应用程序标识，配置对应的应用程序的构造逻辑，并将构造逻辑进行命名得到构造逻辑名称。

在一些实施例中，第二接口为构造逻辑配置函数，通过接收用户输入的相关的参数，例如应用程序标识、构造逻辑名称和构造逻辑，即可完成对应的应用程序的构造逻辑的配置。具体的，根据第三接口和应用程序标识，可以配置对应的应用程序的构造逻辑。具体的，通过App_key标识配置的构造逻辑属于哪个应用程序，并使用构造逻辑名称Data_Structure_name对构造逻辑Data_Structure进行命名，即将Data_Structure以Data_Structure_name命名，并且App_key和Data_Structure_name满足第二映射关系。

在一些实施例中，第二映射关系为哈希表，App_key作为哈希表的键，Data_Structure_name作为哈希表的值，由此可以通过App_key获取Data_Structure_name，从而调用对应的Data_Structure构造该应用程序的请求数据包的响应数据包。可以理解的是，第三接口的请求参数包括App_key、Data_Structure_name和Data_Structure，由此实现了对不同的应用程序配置不同的构造逻辑。

在一些实施例中，各个预设接口存在于用户态中，对处理逻辑和构造逻辑进行命名后会发送至eBPF的prog_array中进行保存，在后续的流程中可以被相关的调用接口通过处理逻辑名称和构造逻辑名称调用。可以理解的是，prog_array是一种特殊的数组结构，可以用于保存多个eBPF程序，并根据程序的索引值和bpf_tail_call方法进行调用。匹配条件、第一映射关系和第射关系则会通过eBPF传递至内核中，当获取请求数据包后，便可以快速准确地进行匹配和响应，有效提高了响应速度。

参照图4所示，在本申请的一些实施例中，上述步骤S102还可以包括但不限于以下步骤S301至步骤S303。

步骤S301，对请求数据包的头部信息进行网络协议解析，得到匹配参数。

在一些实施例中，对请求数据包的头部信息进行网络协议解析，具体从物理层开始逐层解析至传输层，得到匹配参数。具体的，匹配参数包括但不限于：源端口、源地址、目的端口、目的地址和协议信息，本实施例对此不做限制。步骤S302，依次将源地址、目的地址、源端口、目的端口、协议信息与匹配条件进行匹配，根据最长匹配原则得到应用程序标识。

在一些实施例中，依次将源地址、目的地址、源端口、目的端口、协议信息与预设的匹配条件进行匹配，具体的，可以先匹配源地址，如果源地址与某个预设的匹配条件相同，则继续匹配目的地址，可以理解的是，如果目的地址为空则匹配树形结构中的“无约束”，然后继续匹配源端口，以此类推，直至将各项匹配参数均于预设的匹配条件进行匹配，最后根据最长匹配原则得到对应的应用程序标识。

示例性的，参照图3所示，若匹配参数中没有源地址，即匹配了第一个“source_IP:无约束”的节点，然后匹配目的地址，若目的地址为192:10:2:1，则匹配了树形结构中第二层的右边节点“dest_IP:192:10:2:1”，如果匹配的协议信息为TCP，同时匹配参数中没有源端口，则匹配了节点“TCP source_port:无约束”，继续匹配目的端口，若目的端口为123，则最终匹配的应用程序标识为app1，若匹配参数中没有目的端口，则最终匹配的应用程序标识为app3。

步骤S303，判断应用程序标识与目标应用程序是否匹配，得到匹配结果。

在一些实施例中，根据匹配参数得到的应用程序标识，判断与目标应用程序是否匹配，即判断请求数据包的请求对象是否为当前内核缓存对应的目标应用程序，从而得到匹配结果。示例性的，当匹配得到的应用程序标识对应的应用程序为app2，但是该内核缓存对应的目标应用程序是app1，则得到匹配结果将表征请求数据包与目标应用程序不匹配。

参照图5所示，在本申请的一些实施例中，上述步骤S103还可以包括但不限于以下步骤S401至步骤S402。

步骤S401，若匹配结果为应用程序标识与目标应用程序匹配，根据应用程序标识获取处理逻辑名称。

在一些实施例中，如果匹配结果为应用程序表示与目标应用程序匹配，则根据应用程序标识App_key和处理逻辑名称Process_name之间的第一映射关系，将App_key作为索引获取对应的Process_name。

步骤S402，基于处理逻辑名称，调用预配置的目标应用程序的处理逻辑对请求数据包进行第二解析，得到解析数据。

在一些实施例中，利用bpf_tail_call方法和Process_name调用预配置的目标应用程序的处理逻辑Process对请求数据包进行第二解析。可以理解的是，bpf_tail_call方法eBPF中的一种跳转操作，用于在内核中执行另一个eBPF程序，并将控制权传递给该程序，可以简化程序的逻辑，减少内存占用和指令数量，并且提高程序的执行效率。

在一些实施例中，第二解析是应用层解析，得到解析数据包括以下至少一种：请求信息、协议信息、源端口、源地址、目的端口和目的地址，其中请求信息包括URL信息。

在本申请的一些实施例中，缓存表包括第一哈希表，第一哈希表的键属性包括以下至少一种：请求源端口、请求源地址、请求目的端口、请求协议信息和请求URL信息，第一哈希表的值属性包括：请求数据哈希值。参照图6所示，上述步骤S104还可以包括但不限于以下步骤S501至步骤S503。

步骤S501，将解析数据中的源端口作为请求源端口，源地址作为请求源地址，目的端口作为请求目的端口，协议信息作为请求协议信息，URL信息作为请求URL信息。

在一些实施例中，将解析数据中的各个参数作为缓存表中键属性的各个组成参数，具体的，将解析数据中的源端口作为缓存表的请求源端口，将解析数据中的源地址作为缓存表的请求源地址，将解析数据中的目的端口作为缓存表的请求目的端口，将解析数据中的协议信息作为缓存表的请求协议信息，将解析数据中的URL信息作为缓存表的请求URL信息。

步骤S502，组合请求源端口、请求源地址、请求目的端口、请求协议信息和请求URL信息，得到待匹配键。

在一些实施例中，将请求源端口、请求源地址、请求目的端口、请求协议信息和请求URL信息进行组合，形成待匹配键，由此作为索引可以在第一哈希表中进行查询。

步骤S503，基于待匹配键，查询第一哈希表是否缓存对应的请求数据哈希值，得到缓存标识。

在一些实施例中，基于待匹配键，查询第一哈希表是否缓存对应的请求数据哈希值，可以理解的是，请求数据哈希值与请求数据包的数据哈希值对应，由此得到缓存标识。

参照图7所示，在本申请的一些实施例中，第一哈希表的值属性还包括：响应缓存，上述步骤S105还可以包括但不限于以下步骤S601至步骤S605。

步骤S601，若缓存标识表征第一哈希表已缓存请求数据包的数据哈希值，基于待匹配键获取第一哈希表中的请求数据包对应的响应缓存。

在一些实施例中，应用程序的响应数据会存储至第一哈希表的响应缓存中，如果缓存标识表征第一哈希表已缓存请求数据包的数据哈希值，代表该请求数据包对应的响应数据缓存至内核缓存中，由此基于待匹配键作为索引可以从第一哈希表中获取对应的响应缓存。

步骤S602，根据应用程序标识获取构造逻辑名称。

在一些实施例中，根据内核中存储的应用程序标识和构造逻辑名称的第二映射关系，将应用程序标识APP_key作为索引即可获取对应的构造逻辑名称data_structure_name。

步骤S603，基于构造逻辑名称，调用预配置的目标应用程序的构造逻辑对响应缓存进行构造，得到初始响应数据包。

在一些实施例中，根据构造逻辑名称data_structure_name在prog_array中调用预配置的目标应用程序的数据包构造逻辑data_structure对响应缓存进行构造，以完成应用级的返回数据包的构造，得到初始响应数据包。

步骤S604，将解析数据中的源端口和目的端口、源地址和目的地址进行交换，并计算校验信息，得到重定向信息。

在一些实施例中，在初始响应数据包的基础上，将请求数据包的解析数据中的源端口和目的端口、源地址和目的地址进行交换，即将原始的源端口作为新的目的端口，原始的目的端口作为新的源端口，原始的源地址作为新的目的地址，原始的目的地址作为新的源地址，并重新计算数据包包头的校验信息，得到重定向信息。

步骤S605，根据初始响应数据包和重定向信息，得到响应数据包。

在一些实施例中，根据初始响应数据包和重定向信息，得到最终的响应数据包，并实现了数据包的重定向，完成了请求数据包的响应，由此无需经过冗长复杂的内核网络协议栈，也减少了内核态与用户态之间不必要的数据拷贝，大大提升了响应性能。

在本申请的一些实施例中，第一哈希表的值属性还包括：缓存状态和响应缓存；缓存表还包括第二哈希表，第二哈希表的键属性为请求数据哈希值，第二哈希表的值属性包括以下至少一种：请求源端口、请求源地址、请求目的端口、请求协议信息和请求URL信息。参照图8所示，上述步骤S106还可以包括但不限于以下步骤S701至步骤S709。

步骤S701，若缓存标识表征缓存表未缓存请求数据包的数据哈希值，计算请求数据包的数据哈希值。

在一些实施例中，如果缓存标识表征第一哈希表未缓存请求数据包的数据哈希值，代表该请求数据包对应的响应数据未缓存至内核缓存中，则基于该请求数据包对第一哈希表进行初始化，以便后续将请求数据包的响应数据及时更新存储至第一哈希表中。具体的，根据相同的哈希计算方法选取相同的字段计算请求数据包的数据哈希值，由此确保相同的请求数据包具有相同的数据哈希值。

步骤S702，将解析数据中的源端口作为请求源端口，源地址作为请求源地址，目的端口作为请求目的端口，协议信息作为请求协议信息，URL信息作为请求URL信息。

在一些实施例中，将解析数据中的各个参数作为缓存表中键属性的各个组成参数，具体的，将解析数据中的源端口作为缓存表的请求源端口，将解析数据中的源地址作为缓存表的请求源地址，将解析数据中的目的端口作为缓存表的请求目的端口，将解析数据中的协议信息作为缓存表的请求协议信息，将解析数据中的URL信息作为缓存表的请求URL信息。

步骤S703，组合请求源端口、请求源地址、请求目的端口、请求协议信息和请求URL信息，得到初始键。

在一些实施例中，将请求源端口、请求源地址、请求目的端口、请求协议信息和请求URL信息进行组合，形成初始键，由此作为索引可以在第一哈希表中存储对应的值属性。

步骤S704，基于初始键，将数据哈希值作为请求数据哈希值缓存至第一哈希表中，并初始化缓存状态为不可用状态，响应缓存为空。

在一些实施例中，基于初始键作为索引，将请求数据包的数据哈希值作为请求数据哈希值缓存至第一哈希表中初始化缓存状态为不可用状态，响应缓存为空。可以理解的是，由于第一哈希表中的值属性需要由请求数据包和响应数据包中的相关信息共同组成，通过设置valid字段表示当前的数据是否可用，因此在没有响应数据包时，可以有效避免误用不完整的缓冲数据，提高了响应性能。

步骤S705，将请求数据包发送至目标应用程序进行响应，得到响应数据包。

在一些实施例中，将请求数据包上传到内核态的网络协议栈中，然后传输至目标应用程序进行响应，然后应用程序将响应数据包返回传递给内核态的网络协议栈。

步骤S706，获取并解析响应数据包，得到响应数据。

在一些实施例中，通过TC钩子函数获取该响应数据包，可以理解的是，TC钩子函数是内核中的一种网络流量控制机制，可以对网络流量进行限制、分流和优化，用于实现自定义的网络流量控制策略，来实现对网络流量的过滤和操作。

在一些实施例中，解析响应数据包的过程和解析请求数据包的过程一致，首先对响应数据包进行第一解析，得到匹配参数与目标应用程序的匹配条件进行匹配，可以理解的是，匹配条件中的源端口和目标端口、源地址和目的地址相互交换，然后调用对应的预配置的处理逻辑进行第二解析，得到响应数据。

在一些实施例中，响应数据包中携带相关的请求信息，因此解析得到的响应数据包括以下至少一种：响应信息、源端口、源地址、目的端口和目的地址，具体的，响应信息是对请求数据包的请求信息的响应，源端口、源地址、目的端口和目的地址即请求数据包中的源端口、源地址、目的端口和目的地址。

步骤S707，根据源端口、源地址、目的端口和目的地址获取对应的请求数据包，并基于请求数据包计算对应的数据哈希值。

在一些实施例中，请求数据包以及是否命中第一哈希表等信息会被缓存，由此可以根据响应数据中的源端口、源地址、目的端口和目的地址获取对应的请求数据包，从而基于请求数据包计算对应的数据哈希值。

步骤S708，将数据哈希值作为请求数据哈希值，并将请求数据哈希值作为第二哈希表的待匹配键，查询得到对应的解析数据。

在一些实施例中，将数据哈希值作为请求数据哈希值，并将请求数据哈希值作为第二哈希表的待匹配键，作为索引查询得到对应的解析数据，具体包括值属性中的以下至少一种：请求源端口、请求源地址、请求目的端口、请求协议信息和请求URL信息。

步骤S709，将解析数据作为第一哈希表的待匹配键，将响应信息作为响应缓存并缓存至第一哈希表中，并更新缓存状态为可用状态。

在一些实施例中，将从第二哈希表查询到的解析数据作为第一哈希表的待匹配键，作为索引找到第一哈希表中的对应位置，从而将响应信息作为响应缓存并缓存至第一哈希表中，并更新缓存状态为可用状态。由此在下次有相同的请求数据包时，可以在内核缓存中快速响应，准确地根据响应缓存构造响应数据包，及时更新缓存有效提高了内核缓存的命中率和响应速度。

参照图9所示，在本申请的一些实施例中，上述步骤S705之前还可以包括但不限于以下步骤S801至步骤S802。

步骤S801，将数据哈希值作为请求数据哈希值，并将请求数据哈希值作为第二哈希表的键属性，将初始键作为第二哈希表的值属性。

在一些实施例中，将数据哈希值作为请求数据哈希值，并将请求数据哈希值作为第二哈希表的键属性，将初始键中的请求源端口、请求源地址、请求目的端口、请求协议信息和请求URL信息作为第二哈希表的值属性。

步骤S802，将键属性和值属性存储至第二哈希表。

在一些实施例中，将键属性作为索引，将值属性存储至第二哈希表中，从而便于后续根据数据哈希值查询对应的值属性。

可以理解的是，由于不同的请求数据包可能会计算得到相同的数据哈希值，即产生了哈希冲突，因此本实施中通过设置第二哈希表，在请求数据包发送至目标应用程序进行响应之前，针对该请求数据包的数据哈希值和解析数据进行映射存储。由此在后续根据响应数据获取请求数据包时，即使是不同的请求数据包和相同的数据哈希值，也能通过对比源端口、源地址、目的端口、目的地址和协议信息等字段进行进一步地确认，由此确保了响应数据缓存至正确的请求数据包对应的缓冲项中。

在本申请的一些实施例中，为了更好地管理内核缓存，将请求数据包及是否命中等信息利用eBPF map传递至用户态中，以便完成对后续请求指令的预测，优化内核缓存的分配情况。可以理解的是，eBPF map是一种特殊的共享内存，可以用于在内核态和用户态之间传递数据。参照图10所示，数据包缓存方法还可以包括基于解析数据，预测不同的请求数据得到后续请求指令的请求概率，并基于请求概率更新缓存表，具体包括但不限于以下步骤S901至步骤S904。

步骤S901，对解析数据进行预处理，得到待预测的请求数据。

在一些实施例中，为了保证对最新最全面的数据进行预测，在对请求数据包进行第二解析得到解析数据后，便将解析数据通过eBPF map传递到用户态中，在用户态对解析数据进行预处理，得到待预测的请求数据。具体的，预处理包括归一化等处理，请求数据包括以下至少一种：应用程序标识、源端口、源地址、请求信息、请求时间和命中状态，命中状态为第一状态代表请求数据包在缓存表中有响应缓存，命中状态为第二状态代表请求数据包在缓存表中无响应缓存，命中状态为第三状态代表请求数据包不在缓存表中。示例性的，第一状态用1表示，第二状态用0表示，第三状态用-1表示，本实施例对此不做限制。

步骤S902，将待预测的请求数据和历史的请求数据输入至预测模型进行预测，得到各个请求数据对应的请求指令的请求概率。

在一些实施例中，将待预测的请求数据和历史的请求数据输入至预测模型进行预测，具体的，预测模型为预训练的LSTM预测模型。可以理解的是，当预测模型接收到待预测的请求数据后，将其记录在内存中，并将离当前时间最近的多个历史请求数据一起传递至预测模型进行后续的请求指令的请求概率的预测。示例性的，可以将30个历史请求数据包的请求数据进行预测，从而得到各个请求数据对应的请求指令的请求概率。

在一些实施例中，将请求概率即对应的请求URL信息存储在哈希表probability_map中，其中键属性为可能出现的URL信息，值属性为URL出现的概率。为了避免占用过多的内存空间，每30秒将会对请求数据进行落盘，方便后续离线优化预测模型，本实施例对此不做限制。

步骤S903，基于请求概率，计算缓存表中的各个缓冲项的权重，得到权重信息。

在一些实施例中，基于请求概率的哈希表，计算缓存表中的各个缓冲项的权重，得到权重信息。具体的，缓存表中有多个缓存项，根据公式计算各个缓存项的权值，其中，代表所述缓存项的权重，表示权重系数，本实施例中，代表请求概率。可以理解的是，对于新增的缓存项或者本次命中的缓存项，预测模型预测的请求概率为=1，哈希表probability_map未出现但缓存项中出现的请求=0。

步骤S904，根据权重信息，替换权重最小的缓存项，以更新所述缓存表。

在一些实施例中，当缓存表中的缓存项已满时，则根据缓存项的权值信息，将权重最小的缓存项进行替换，即将后续最不可能出现的缓存项进行替换，由此实时更新缓存项，有效提高了内核缓存的命中率。

以下通过一个完整的实施例说明本申请的数据包缓存方法：

参照图11所示，本实施中的数据包缓存方法的缓存框架命名为e-cache，其具备四个模块：入链处理模块、出链处理模块、用户定制模块和智能内存管理模块，其中入链处理模块和出链处理模块位于内核态中，用户定制模块和智能内存管理模块位于用户态中。

开发人员可以通过用户定制模块提供的接口对匹配条件、处理逻辑和构造逻辑进行配置。根据用户的设置，用户定制模块会记录每个应用程序对应的匹配条件、处理逻辑和响应数据包的构造方式，并利用eBPF中的prog_array和map结构体传递到入链处理模块中。参照如下表1所示，是匹配条件的相关参数。

表1 匹配条件

参照如下表2和表3所示，是配置处理逻辑的第二接口的请求参数和第一映射关系Process_map结构。

表2 第二接口请求参数

表3 Process_map结构

参照如下表4和表5所示，是配置构造逻辑的第三接口的请求参数和第二映射关系Data_Structure_map结构。

表4 第三接口请求参数

表5 Data_Structure_map结构

当用户定制模块处理完用户的配置信息后，通过eBPF map将信息传递到内核中，当后续在内核中捕获到请求数据包后，便可快速准确地选取最匹配的处理逻辑和构造逻辑完成请求数据包解析和响应数据包的构造。

具体的，响应于用户的请求指令，XDP钩子函数从网卡等网络设备中获取请求数据包后，参照图12所示的入链处理模块流程图，在入链处理模块中对其进行第一解析，得到匹配参数，根据最长匹配原则在匹配条件中得到最匹配的应用程序标识，然后判断该应用程序标识与目标应用程序是否匹配，如果不匹配则按照一般流程对该请求数据包进行处理，如果匹配则根据应用程序标识App_key在Process_map中找到对应的处理逻辑名称Process_name，然后利用Process_name在prog_array中找到对应的处理逻辑Process，最终利用bpf_tail_call方法调用对应的处理逻辑Process对请求数据包进行第二解析。

当请求数据包完成第二解析后，得到解析数据，将其中的源端口、源地址、目的端口、协议信息和URL信息进行组合，形成待匹配键，在第一哈希表中进行查询。参照如下表6的第一哈希表Response_cache_Map结构。

表6 Response_cache_Map结构

由此查询第一哈希表是否缓存有该请求数据包对应的响应缓存，如果命中缓存则根据预配置的构造逻辑和响应缓存对应构造响应数据包，具体利用App_key在Data_Structure_map中找构造逻辑名称Data_Structure_name，再根据Data_Structure_name在prog_array中找到对应构造逻辑Data_Structure对响应数据包进行构造，同时将原数据的源断开和目的端口、源地址和目的地址进行替换，并重新计算数据包包头的校验信息，最后完成数据包的重定向。由此无需经过冗长复杂的内核网络协议栈，也减少了内核态与用户态之间不必要的数据拷贝，大大提升了响应的性能。

如果第一哈希表中没有缓存该请求数据包的响应缓存，则对第一哈希表进行初始化，将请求数据包对应的数据存储至第一哈希表中。具体的，计算请求数据包的数据哈希值，根据解析数据得到的初始键，将数据哈希值存储至第一哈希表中，同时设置vaild字段为不可用状态以及响应缓存Response为空，由此避免了e-cache误用不完整的缓存数据。参照如下表7所示的第二哈希表Key_content_map结构，在请求数据包发送至目标应用程序进行响应之前更新，可以有效解决哈希冲突问题，并帮助出链处理模块找到请求数据包的信息，进而更新缓存的第一哈希表。

表7 Key_content_map结构

当内核缓存的第一哈希表没有缓存请求数据包的响应缓存，则将该请求数据包发送至网络协议栈中，从而传输至用户态中的目标应用程序进行响应，得到响应数据包后通过网络协议栈时，被TC钩子函数获取并在出链处理模块中进行处理。

具体的，和入链处理模块类似，对响应数据包进行第一解析，得到匹配参数与匹配条件进行匹配，可以理解的是，需要将源端口和目的端口、源地址和目的地址进行互换，从而根据最长匹配原则得到对应的应用程序标识，由此选择对应的处理逻辑对响应数据包进行第二解析，得到响应数据。参照图13所示的缓存更新流程图，响应数据中对应有请求数据包中的源地址、源端口、目的地址和目的端口信息，据此可以获取对应的请求数据包，并计算数据哈希值，利用数据哈希值作为索引根据第二哈希表查询对应的解析数据，判断根据解析数据中的URL信息和请求数据包中的URL信息是否从而确定是否为同一请求，有效解决了哈希冲突的问题，最后将响应信息作为响应缓存更新至第一哈希表中的对应位置，并设置vaild字段为可用，及时更新缓存有效提高了缓存命中率。

对于智能内存管理模块，包括数据预处理和预测模型，具体利用LSTM算法，对用户后续的请求指令进行预测，从而确定各个应用程序允许占用的缓存大小。在入链处理模块对请求数据包进行第二解析后，便将解析数据通过eBPF map传递到用户态中智能内存管理模块中，参照图14所示的智能内存管理模块流程图，首先对解析数据进行数据清洗和归一化等处理后，并记录到内存中，然后判断内存数据是否超过阈值，超过阈值则对请求数据进行落盘以及对内存中过期数据进行清理，否则直接将请求数据和内存中的历史请求数据输入至预测模型，然后得到各个请求数据对应的请求指令的请求概率，将请求概率和对应的请求URL信息存储至哈希表probability_map中并传递至内核态，以便及时对缓存项进行更新。可以理解的是，如果预测模型过期，还可以根据最新的请求数据优化更新预测模型，例如最近7天内或者1天内的请求数据优化更新预测模型，由此保证了预测模型的时效性。

由此，本申请的实施例中只需要在用户态由应用开发人员利用用户定制模块的接口，配置好需要的匹配条件、处理逻辑以及构造逻辑即可，灵活适配多种应用程序。针对数据传入与传出两条路径，本申请分别使用了XDP钩子函数以及TC钩子函数进行获取，并对获取到的数据包进行第一解析，找到对应的处理逻辑进行后续处理。为了解决内核缓存空间小，多应用程序内存空间分配难的问题，本申请还增加了智能内存管理模块，对后续请求指令进行预测，指导缓存项的更新，提高整体的缓存命中率。本申请为应用程序实现内核级缓存提供e-cache缓存框架，不仅能对多应用程序间的协议处理逻辑进行有效管理，还能优化系统的整体缓存命中率，提高用户的开发效率的同时也提升了系统的响应性能。

本发明实施例还提供一种数据包缓存装置，可以实现上述数据包缓存方法，参照图15所示，在本申请一些实施例中，数据包缓存装置包括：

数据包响应模块100，用于响应于用户的请求指令，获取请求数据包；

第一解析模块200，用于对请求数据包进行第一解析，得到匹配参数，并将匹配参数与预设的匹配条件进行匹配，得到匹配结果；

第二解析模块300，用于若匹配结果表征请求数据包与目标应用程序匹配，利用预配置的目标应用程序的处理逻辑对请求数据包进行第二解析，得到解析数据；

缓存查询模块400，用于基于解析数据，查询缓存表是否缓存请求数据包的数据哈希值，得到缓存标识；

数据包构造模块500，用于若缓存标识表征缓存表已缓存请求数据包的数据哈希值，根据缓存表和预配置的目标应用程序的构造逻辑构造请求数据包的响应数据包；

缓存更新模块600，用于若缓存标识表征缓存表未缓存请求数据包的数据哈希值，基于解析数据初始化缓存表，将请求数据包发送至目标应用程序进行响应，得到响应数据包，并基于响应数据包更新缓存表。

参照图16所示，在本申请的一些实施例中，数据包缓存装置还包括：

缓存预测模块700，用于基于解析数据，预测不同的请求数据得到后续请求指令的请求概率，并基于请求概率更新缓存表。

预配置模块800，用于根据预设接口和应用程序标识，对匹配条件、处理逻辑和构造逻辑进行配置。

本实施例的数据包缓存装置的具体实施方式与上述数据包缓存方法的具体实施方式基本一致，在此不再一一赘述。

图17示出了本申请实施例提供的电子设备1000。电子设备1000包括：处理器1001、存储器1002及存储在存储器1002上并可在处理器1001上运行的计算机程序，计算机程序运行时用于执行上述的数据包缓存方法。

处理器1001和存储器1002可以通过总线或者其他方式连接。

存储器1002作为一种非暂态计算机可读存储介质，可用于存储非暂态软件程序以及非暂态性计算机可执行程序，如本申请实施例描述的数据包缓存方法。处理器1001通过运行存储在存储器1002中的非暂态软件程序以及指令，从而实现上述的数据包缓存方法。

存储器1002可以包括存储程序区和存储数据区，其中，存储程序区可存储操作系统、至少一个功能所需要的应用程序；存储数据区可存储执行上述的数据包缓存方法。此外，存储器1002可以包括高速随机存取存储器1002，还可以包括非暂态存储器1002，例如至少一个储存设备存储器件、闪存器件或其他非暂态固态存储器件。在一些实施方式中，存储器1002可选包括相对于处理器1001远程设置的存储器1002，这些远程存储器1002可以通过网络连接至该电子设备1000。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

实现上述的数据包缓存方法所需的非暂态软件程序以及指令存储在存储器1002中，当被一个或者多个处理器1001执行时，执行上述的数据包缓存方法，例如，执行图1中的方法步骤S101至步骤S106、图2中的方法步骤S201至步骤S203、图4中的方法步骤S301至步骤S303、图5中的方法步骤S401至步骤S402、图6中的方法步骤S501至步骤S503、图7中的方法步骤S601至步骤S605，图8中的方法步骤S701至步骤S709，图9中的方法步骤S801至步骤S802，图10中的方法步骤S901至步骤S904。

本申请实施例还提供了一种存储介质，存储介质为计算机可读存储介质，该存储介质存储有计算机程序，该计算机程序被处理器执行时实现上述数据包缓存方法。存储器作为一种非暂态计算机可读存储介质，可用于存储非暂态软件程序以及非暂态性计算机可执行程序。此外，存储器可以包括高速随机存取存储器，还可以包括非暂态存储器，例如至少一个磁盘存储器件、闪存器件、或其他非暂态固态存储器件。在一些实施方式中，存储器可选包括相对于处理器远程设置的存储器，这些远程存储器可以通过网络连接至该处理器。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

本申请实施例提供的数据包缓存方法、装置、电子设备及存储介质，能灵活、高效地实现内核缓存，允许网络仿真验证平台灵活、高效、对应用程序无感地提高响应性能。可以根据预配置的处理逻辑对请求数据包进行处理，在缓存中快速响应并根据预设的构造逻辑构造响应数据包，可以对不同的应用程序的处理逻辑和构造逻辑进行配置，提高了缓存机制的可扩展性和响应速度，并在缓存表没有对应的响应数据时及时更新缓存有效提高了缓存命中率。

本申请还具备以下优点：

1、针对内核缓存场景，本申请提出了一个通用的缓存框架e-cache。通过提供匹配条件、协议解析的处理逻辑以及响应数据包的构造逻辑的配置接口，灵活适配多种应用程序的响应优化需求。

2、本申请提出智能内存管理的机制，通过LSTM算法对用户后续的请求指令进行预测，确定内核缓存的分配和更新策略，解决内核缓存空间过小导致缓存命中率低的问题。

3、本申请提出了利用树形结构对不同应用程序的处理逻辑进行管理的方案，不仅可以快速准确地找到最匹配的处理逻辑，同时能大大降低条件匹配所消耗的资源。

4、本申请不仅提供基础协议的第一解析，还提出了内核缓存的通用处理逻辑，使用者只需提供应用级的处理逻辑即可使用内核缓存，解决了现有方案在多应用程序场景下存在的开发难度大、重复代码多的问题。

以上所描述的实施例仅仅是示意性的，其中作为分离部件说明的单元可以是或者也可以不是物理上分开的，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。

本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统可以被实施为软件、固件、硬件及其适当的组合。某些物理组件或所有物理组件可以被实施为由处理器，如中央处理器、数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读介质上，计算机可读介质可以包括计算机存储介质（或非暂时性介质）和通信介质（或暂时性介质）。如本领域普通技术人员公知的，术语计算机存储介质包括在用于存储信息（诸如计算机可读指令、数据结构、程序模块或其他数据）的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于RAM、ROM、EEPROM、闪存或其他存储器技术、CD-ROM、数字多功能盘（DVD）或其他光盘存储、磁盒、磁带、储存设备存储或其他磁存储装置、或者可以用于存储期望的信息并且可以被计算机访问的任何其他的介质。此外，本领域普通技术人员公知的是，通信介质通常包括计算机可读指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据，并且可包括任何信息递送介质。

还应了解，本申请实施例提供的各种实施方式可以任意进行组合，以实现不同的技术效果。以上是对本申请的较佳实施进行了具体说明，但本申请并不局限于上述实施方式，熟悉本领域的技术人员在不违背本申请精神的共享条件下还可作出种种等同的变形或替换。

Claims (14)

1.一种数据包缓存方法，其特征在于，包括：

响应于用户的请求指令，获取请求数据包；

对所述请求数据包进行第一解析，得到匹配参数，并将所述匹配参数与预设的匹配条件进行匹配，得到匹配结果；

若所述匹配结果表征所述请求数据包与目标应用程序匹配，利用预配置的所述目标应用程序的处理逻辑对所述请求数据包进行第二解析，得到解析数据；

基于所述解析数据，查询缓存表是否缓存所述请求数据包的数据哈希值，得到缓存标识；

若所述缓存标识表征所述缓存表已缓存所述请求数据包的数据哈希值，根据所述缓存表和预配置的所述目标应用程序的构造逻辑构造所述请求数据包的响应数据包；

若所述缓存标识表征所述缓存表未缓存所述请求数据包的数据哈希值，基于所述解析数据初始化所述缓存表，将所述请求数据包发送至所述目标应用程序进行响应，得到响应数据包，并基于所述响应数据包更新所述缓存表。

2.根据权利要求1所述的数据包缓存方法，其特征在于，所述对所述请求数据包进行第一解析，得到匹配参数，并将所述匹配参数与预设的匹配条件进行匹配，得到匹配结果，包括：

对所述请求数据包的头部信息进行网络协议解析，得到所述匹配参数；所述匹配参数包括以下至少一种：源端口、源地址、目的端口、目的地址和协议信息；

依次将所述源地址、所述目的地址、所述源端口、所述目的端口、所述协议信息与所述匹配条件进行匹配，根据最长匹配原则得到应用程序标识；

判断所述应用程序标识与所述目标应用程序是否匹配，得到匹配结果。

3.根据权利要求2所述的数据包缓存方法，其特征在于，所述若所述匹配结果表征所述请求数据包与目标应用程序匹配，利用预配置的所述目标应用程序的处理逻辑对所述请求数据包进行第二解析，得到解析数据，包括：

若所述匹配结果为所述应用程序标识与所述目标应用程序匹配，根据所述应用程序标识获取处理逻辑名称；所述应用程序标识与所述处理逻辑名称满足第一映射关系；

基于所述处理逻辑名称，调用预配置的所述目标应用程序的处理逻辑对所述请求数据包进行第二解析，得到所述解析数据；所述解析数据包括以下至少一种：请求信息、所述协议信息、所述源端口、所述源地址、所述目的端口和所述目的地址，所述请求信息包括URL信息。

4.根据权利要求3所述的数据包缓存方法，其特征在于，所述缓存表包括第一哈希表，所述第一哈希表的键属性包括以下至少一种：请求源端口、请求源地址、请求目的端口、请求协议信息和请求URL信息，所述第一哈希表的值属性包括：请求数据哈希值；所述基于所述解析数据，查询缓存表是否缓存所述请求数据包的数据哈希值，得到缓存标识，包括：

将所述解析数据中的源端口作为请求源端口，源地址作为请求源地址，目的端口作为请求目的端口，协议信息作为请求协议信息，URL信息作为请求URL信息；

组合所述请求源端口、所述请求源地址、所述请求目的端口、所述请求协议信息和所述请求URL信息，得到待匹配键；

基于所述待匹配键，查询所述第一哈希表是否缓存对应的请求数据哈希值，得到缓存标识；所述请求数据哈希值与所述请求数据包的数据哈希值对应。

5.根据权利要求4所述的数据包缓存方法，其特征在于，所述第一哈希表的值属性还包括：响应缓存；所述若所述缓存标识表征所述缓存表已缓存所述请求数据包的数据哈希值，根据所述缓存表和预配置的所述目标应用程序的构造逻辑构造所述请求数据包的响应数据包，包括：

若所述缓存标识表征所述第一哈希表已缓存所述请求数据包的数据哈希值，基于所述待匹配键获取所述第一哈希表中的所述请求数据包对应的所述响应缓存；

根据所述应用程序标识获取构造逻辑名称；所述应用程序标识与所述构造逻辑名称满足第二映射关系；

基于所述构造逻辑名称，调用预配置的所述目标应用程序的构造逻辑对所述响应缓存进行构造，得到初始响应数据包；

将所述解析数据中的源端口和目的端口、源地址和目的地址进行交换，并计算校验信息，得到重定向信息；

根据所述初始响应数据包和所述重定向信息，得到所述响应数据包。

6.根据权利要求4所述的数据包缓存方法，其特征在于，所述第一哈希表的值属性还包括：缓存状态和响应缓存；所述缓存表还包括第二哈希表，所述第二哈希表的键属性为请求数据哈希值，所述第二哈希表的值属性包括以下至少一种：请求源端口、请求源地址、请求目的端口、请求协议信息和请求URL信息；所述若所述缓存标识表征所述缓存表未缓存所述请求数据包的数据哈希值，基于所述解析数据初始化所述缓存表，将所述请求数据包发送至所述目标应用程序进行响应，得到响应数据包，并基于所述响应数据包更新所述缓存表，包括：

若所述缓存标识表征所述第一哈希表未缓存所述请求数据包的数据哈希值，计算所述请求数据包的数据哈希值；

将所述解析数据中的源端口作为请求源端口，源地址作为请求源地址，目的端口作为请求目的端口，协议信息作为请求协议信息，URL信息作为请求URL信息；

组合所述请求源端口、所述请求源地址、所述请求目的端口、所述请求协议信息和所述请求URL信息，得到初始键；

基于所述初始键，将所述数据哈希值作为请求数据哈希值缓存至所述第一哈希表中，并初始化所述缓存状态为不可用状态，所述响应缓存为空；

将所述请求数据包发送至所述目标应用程序进行响应，得到所述响应数据包；

获取并解析所述响应数据包，得到响应数据；所述响应数据包括以下至少一种：响应信息、所述源端口、所述源地址、所述目的端口和所述目的地址；

根据所述源端口、所述源地址、所述目的端口和所述目的地址获取对应的请求数据包，并基于所述请求数据包计算对应的数据哈希值；

将所述数据哈希值作为请求数据哈希值，并将所述请求数据哈希值作为所述第二哈希表的待匹配键，查询得到对应的所述解析数据；

将所述解析数据作为所述第一哈希表的待匹配键，将所述响应信息作为所述响应缓存并缓存至所述第一哈希表中，并更新所述缓存状态为可用状态。

7.根据权利要求6所述的数据包缓存方法，其特征在于，所述将所述请求数据包发送至所述目标应用程序进行响应，得到所述响应数据包之前，还包括：

将所述数据哈希值作为请求数据哈希值，并将所述请求数据哈希值作为所述第二哈希表的键属性，将所述初始键作为所述第二哈希表的值属性；

将所述键属性和所述值属性存储至所述第二哈希表。

8.根据权利要求1所述的数据包缓存方法，其特征在于，所述方法还包括：基于所述解析数据，预测不同的请求数据得到后续请求指令的请求概率，并基于所述请求概率更新所述缓存表，包括：

对所述解析数据进行预处理，得到待预测的请求数据；所述请求数据包括以下至少一种：应用程序标识、源端口、源地址、请求信息、请求时间和命中状态，所述命中状态为第一状态代表所述请求数据包在所述缓存表中有响应缓存，所述命中状态为第二状态代表所述请求数据包在所述缓存表中无响应缓存，所述命中状态为第三状态代表所述请求数据包不在所述缓存表中；

将待预测的请求数据和历史的请求数据输入至预测模型进行预测，得到各个所述请求数据对应的请求指令的请求概率；所述预测模型为预训练的LSTM预测模型；

基于所述请求概率，计算所述缓存表中的各个缓存项的权重，得到权重信息；所述缓存表中存储多个缓存项，所述缓存项包括键属性和值属性；

根据所述权重信息，替换权重最小的所述缓存项，以更新所述缓存表。

9.根据权利要求1至8任一项所述的数据包缓存方法，其特征在于，所述应用程序有多个，每个所述应用程序具有唯一的应用程序标识；所述响应于的请求指令，获取请求数据包之前，还包括：根据预设接口和所述应用程序标识，对所述匹配条件、所述处理逻辑和所述构造逻辑进行配置，包括：

基于第一接口和所述应用程序标识，配置对应的所述应用程序的匹配条件，并将不同的所述应用程序的所述匹配条件以树形结构存储；所述匹配条件包括所述应用程序标识和协议信息；

基于第二接口和所述应用程序标识，配置对应的所述应用程序的处理逻辑，并将所述处理逻辑进行命名得到处理逻辑名称；所述应用程序标识和所述处理逻辑名称满足第一映射关系；

基于第三接口和所述应用程序标识，配置对应的所述应用程序的构造逻辑，并将所述构造逻辑进行命名得到构造逻辑名称；所述应用程序标识和所述构造逻辑名称满足第二映射关系。

10.一种数据包缓存装置，其特征在于，应用如权利要求1至9中任一项所述的数据包缓存方法，包括：

数据包响应模块，用于响应于用户的请求指令，获取请求数据包；

第一解析模块，用于对所述请求数据包进行第一解析，得到匹配参数，并将所述匹配参数与预设的匹配条件进行匹配，得到匹配结果；

第二解析模块，用于若所述匹配结果表征所述请求数据包与目标应用程序匹配，利用预配置的所述目标应用程序的处理逻辑对所述请求数据包进行第二解析，得到解析数据；

缓存查询模块，用于基于所述解析数据，查询缓存表是否缓存所述请求数据包的数据哈希值，得到缓存标识；

数据包构造模块，用于若所述缓存标识表征所述缓存表已缓存所述请求数据包的数据哈希值，根据所述缓存表和预配置的所述目标应用程序的构造逻辑构造所述请求数据包的响应数据包；

缓存更新模块，用于若所述缓存标识表征所述缓存表未缓存所述请求数据包的数据哈希值，基于所述解析数据初始化所述缓存表，将所述请求数据包发送至所述目标应用程序进行响应，得到响应数据包，并基于所述响应数据包更新所述缓存表。

11.根据权利要求10所述的数据包缓存装置，其特征在于，所述装置还包括：

缓存预测模块，用于基于所述解析数据，预测不同的请求数据得到后续请求指令的请求概率，并基于所述请求概率更新所述缓存表。

12.根据权利要求10所述的数据包缓存装置，其特征在于，所述装置还包括：

预配置模块，用于根据预设接口和应用程序标识，对所述匹配条件、所述处理逻辑和所述构造逻辑进行配置。

13.一种电子设备，其特征在于，包括存储器、处理器，所述存储器存储有计算机程序，所述处理器执行所述计算机程序时实现如权利要求1至9中任一项所述的数据包缓存方法。

14.一种计算机可读存储介质，其特征在于，所述存储介质存储有程序，所述程序被处理器执行实现如权利要求1至9中任一项所述的数据包缓存方法。