请求处理方法及装置、电子设备及存储介质与流程

1.本公开涉及网络技术领域，尤其涉及一种请求处理方法及装置、电子设备及存储介质。


背景技术：

2.目前手机等智能设备的应用程序中收到的广告较多，极大地影响使用体验。相关技术中的一些广告拦截方法，在拦截广告相关的网络请求的同时，也会同时导致非广告网络请求的响应速度变慢，进而对正常业务功能的工作效率产生影响。


技术实现要素：

3.本公开实施例提供一种请求处理方法及装置、电子设备及存储介质。
4.本公开实施例第一方面提供一种请求处理方法，应用于第一设备，所述方法包括：
5.接收请求消息；
6.在接收到所述请求消息后，向所述请求消息的发送方返回应答消息；所述应答消息，用于指示所述请求消息的发送方获取待处理的目标数据；
7.通过解析所述请求消息，确定所述请求消息是否为拒绝响应的请求消息；
8.当所述请求消息不是拒绝响应的请求消息时，接收所述目标数据；
9.当所述请求消息是拒绝响应的请求消息时，拒绝接收所述目标数据。
10.基于上述方案，所述通过解析所述请求消息，确定所述请求消息是否为拒绝响应的请求消息，包括：
11.通过解析所述请求消息，获取所述请求消息的发送方的第一特征，其中，所述第一特征至少包括：统一资源地址；
12.当所述第一特征与预先知晓的拒绝响应请求消息类型的第二特征匹配时，确定所述请求消息为拒绝响应的请求消息。
13.基于上述方案，所述第二特征记录在特征表中；所述特征表包括：所述第一设备本地存储的第一特征表和/或从第二设备接收的第二特征表。
14.基于上述方案，所述方法还包括：
15.在接收所述目标数据后，通过解析所述目标数据确定所述目标数据是否为拒绝处理的目标数据；
16.若所述目标数据不是拒绝处理的目标数据，则处理所述目标数据；
17.若所述目标数据是拒绝处理的目标数据，则删除所述目标数据。
18.基于上述方案，所述通过解析所述目标数据确定所述目标数据是否为拒绝处理的目标数据，包括：
19.通过解析所述目标数据，获取所述目标数据的发送方的第三特征；所述第三特征至少包括：统一资源地址；
20.若所述第三特征与所述第一特征相同，则当所述第三特征与预先知晓的拒绝处理
目标数据类型的第四特征匹配时，确定所述目标数据为拒绝处理的目标数据；
21.若所述第三特征与所述第一特征不同，则当所述第三特征与所述第四特征和/或所述第二特征匹配时，确定所述目标数据为拒绝处理的目标数据。
22.基于上述方案，所述方法还包括：
23.若所述第一特征与预先知晓的允许响应的请求消息类型的第五特征匹配，确定所述请求消息不是拒绝响应的请求消息；
24.所述当所述第一特征与预先知晓的拒绝响应请求消息类型的第二特征匹配时，确定所述请求消息为拒绝响应的请求消息，包括：
25.若所述第一特征与所述第五特征不匹配，当所述第一特征与预先知晓的拒绝响应请求消息类型的第二特征匹配时，确定所述请求消息为拒绝响应的请求消息。
26.基于上述方案，所述方法还包括：
27.若所述第三特征与所述第四特征匹配，则基于所述第三特征对应的目标数据确定所述目标数据对应的请求消息；
28.将所述目标数据对应的请求消息的第一特征添加到所述第二特征。
29.基于上述方案，所述方法还包括：
30.若所述第一特征与所述第二特征不匹配，则将所述第一特征添加到所述第五特征。
31.基于上述方案，所述特征表存储于具备固定的预设容量的先进先出fifo队列中。
32.基于上述方案，所述方法还包括：
33.每隔预设时长基于所述第一设备包含的至少一个第一特征表对应的应用程序，将所述应用程序对应的第二特征表中的第二特征，写入所述应用程序对应的第一特征表中。
34.本公开实施例第二方面提供一种请求处理装置，应用于第一设备，所述装置包括：
35.第一接收单元，用于接收请求消息；
36.返回单元，用于在接收到所述请求消息后，向所述请求消息的发送方返回应答消息；所述应答消息，用于指示所述请求消息的发送方获取待处理的目标数据；
37.解析单元，用于通过解析所述请求消息，确定所述请求消息是否为拒绝响应的请求消息；
38.第二接收单元，用于当所述请求消息不是拒绝响应的请求消息时，接收所述目标数据；当所述请求消息是拒绝响应的请求消息时，拒绝接收所述目标数据。
39.基于上述方案，所述解析单元，具体用于：
40.通过解析所述请求消息，获取所述请求消息的发送方的第一特征，其中，所述第一特征至少包括：统一资源地址；
41.当所述第一特征与预先知晓的拒绝响应请求消息类型的第二特征匹配时，确定所述请求消息为拒绝响应的请求消息。
42.基于上述方案，所述第二特征记录在特征表中；所述特征表包括：所述第一设备本地存储的第一特征表和/或从第二设备接收的第二特征表。
43.基于上述方案，所述解析单元，还用于：
44.在接收所述目标数据后，通过解析所述目标数据确定所述目标数据是否为拒绝处理的目标数据；
45.所述装置还包括：
46.处理单元，用于若所述目标数据不是拒绝处理的目标数据，则处理所述目标数据；若所述目标数据是拒绝处理的目标数据，则删除所述目标数据。
47.基于上述方案，所述解析单元，具体用于：
48.通过解析所述目标数据，获取所述目标数据的发送方的第三特征；所述第三特征至少包括：统一资源地址；
49.若所述第三特征与所述第一特征相同，则当所述第三特征与预先知晓的拒绝处理目标数据类型的第四特征匹配时，确定所述目标数据为拒绝处理的目标数据；
50.若所述第三特征与所述第一特征不同，则当所述第三特征与所述第四特征和/或所述第二特征匹配时，确定所述目标数据为拒绝处理的目标数据。
51.基于上述方案，所述解析单元，还用于：
52.若所述第一特征与预先知晓的允许响应的请求消息类型的第五特征匹配，确定所述请求消息不是拒绝响应的请求消息；
53.所述解析单元，具体用于：
54.若所述第一特征与所述第五特征不匹配，当所述第一特征与预先知晓的拒绝响应请求消息类型的第二特征匹配时，确定所述请求消息为拒绝响应的请求消息。
55.基于上述方案，所述装置还包括：
56.第一添加单元，用于若所述第三特征与所述第四特征匹配，则基于所述第三特征对应的目标数据确定所述目标数据对应的请求消息；将所述目标数据对应的请求消息的第一特征添加到所述第二特征。
57.基于上述方案，所述装置还包括：
58.第二添加单元，用于若所述第一特征与所述第二特征不匹配，则将所述第一特征添加到所述第五特征。
59.基于上述方案，所述特征表存储于具备固定的预设容量的先进先出fifo队列中。
60.基于上述方案，所述装置还包括：
61.更新单元，用于每隔预设时长基于所述第一设备包含的至少一个第一特征表对应的应用程序，将所述应用程序对应的第二特征表中的第二特征，写入所述应用程序对应的第一特征表中。
62.本公开实施例第三方面提供一种电子设备，包括：
63.用于存储处理器可执行指令的存储器；
64.处理器，与所述存储器连接；
65.其中，所述处理器被配置为执行如前述任意技术方案提供的请求处理方法。
66.本公开实施例第四方面提供一种非临时性计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机可执行指令，所述计算机可执行指令被处理器执行时实现前述任意技术方案提供的请求处理方法。
67.本公开的实施例提供的请求处理方法，应用于第一设备，包括：接收请求消息；在接收到所述请求消息后，向所述请求消息的发送方返回应答消息；所述应答消息，用于指示所述请求消息的发送方获取待处理的目标数据；通过解析所述请求消息，确定所述请求消息是否为拒绝响应的请求消息；当所述请求消息不是拒绝响应的请求消息时，接收所述目
标数据；当所述请求消息是拒绝响应的请求消息时，拒绝接收所述目标数据。如此，在接收到请求后直接返回应答消息，从而请求消息的处理过程与目标数据的发送过程可同步进行，无需在确认请求消息是否需要响应的过程中导致目标数据的发送过程出现停滞。基于请求消息的处理结果可以确定是否接收对应的目标数据，从而在有效过滤广告请求等需要拒绝响应的请求消息的基础上，提高需要响应的请求消息及目标数据的传输和处理效率。
68.应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。
附图说明
69.此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本发明的实施例，并与说明书一起用于解释本发明的原理。
70.图1是本公开实施例示出的一种请求处理方法的流程示意图；
71.图2是本公开实施例示出的一种请求处理装置的结构示意图；
72.图3是本公开实施例示出的一种广告拦截方法的流程示意图。
具体实施方式
73.这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本发明相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本发明的一些方面相一致的装置和方法的例子。
74.如图1所示，本公开实施例提供一种请求处理方法，应用于第一设备，所述方法包括：
75.s110：接收请求消息；
76.s120：在接收到所述请求消息后，向所述请求消息的发送方返回应答消息；所述应答消息，用于指示所述请求消息的发送方获取待处理的目标数据；
77.s130：通过解析所述请求消息，确定所述请求消息是否为拒绝响应的请求消息；
78.s140：当所述请求消息不是拒绝响应的请求消息时，接收所述目标数据；
79.s150：当所述请求消息是拒绝响应的请求消息时，拒绝接收所述目标数据。
80.在本公开实施例中，第一设备可以为用于处理请求消息和目标数据的设备，例如手机、电脑等智能设备。请求消息可以为来自网络侧的发送方或其它设备的请求，例如用于请求访问第一设备或向第一设备提供目标数据的网络请求等。应答消息用于表征第一设备允许请求消息的发送方获取并发送目标数据，或者请求消息的发送方指示目标数据的发送方发送目标数据。
81.这里，应答消息可以为第一设备基于请求消息生成的独立的消息，也可以为在请求消息中添加指示发送目标数据的指令形成的应答消息。
82.例如，应答消息可以携带请求消息发送方的统一资源地址(uniform resource locat or，url)或者请求参数等特征信息，其中，请求参数可以包括请求发送的目标数据的数据量和/或数据内容参数等。
83.请求处理方法可以应用于第一设备的虚拟专用网络(virtual private network，
vpn)中，或者也可以应用于第一设备的一个或多个应用程序(application，app)中，用于处理vpn或者一个或多个app接收到的请求消息及目标数据。目标数据可以为第一设备接收后用于进行显示等处理操作的数据，例如用于显示app业务内容、服务支持或者广告等内容的数据。
84.在一个实施例中，所述s130可包括：
85.通过解析所述请求消息，确定所述请求消息发送方的统一资源地址url是否为拒绝响应的url，如果所述请求消息发送方的统一资源地址url为拒绝响应的url，确定所述请求消息为拒绝响应的请求消息。
86.第一设备接收到请求消息后直接返回应答消息以指示发送目标数据，并进行请求消息的解析处理。例如，解析获取请求消息发送方的url和/或互联网协议地址(internet prot ocol address，ip)等信息，用于标识请求消息的发送方的身份。进一步地，解析得到的url可用于确定请求消息是否需要响应，例如可以为确定请求消息的发送方url是否为允许响应的url或者为黑名单中的拒绝响应的url等。
87.在一些实施例中，所述s130，可包括：解析所述请求消息携带的请求参数，确定所述请求消息指示的内容是否为拒绝响应内容，若所述请求消息涉及的内容为拒绝响应的内容，确定所述请求消息为拒绝响应的请求消息。
88.例如，所述请求消息除了携带有url等统一资源地址以外，还会携带一些其他的请求参数。请求参数可以指示请求消息请求发送的目标数据的数据内容，该请求参数可包括：数据内容参数。该数据内容参数可以包括：指示文章的“article”参数、指示应用程序“application”的参数，或者指示广告的广告内容参数等。
89.这里，根据url以外的请求参数，确定所述请求消息是否为拒绝响应的请求消息，可以根据第一设备的设备配置确定。例如，基于第一设备的用户标识确定使用的用户为儿童或老年人，则基于请求消息中的请求参数，确定满足预设请求内容条件的请求消息为拒绝响应的请求消息。其中，预设请求内容条件可以包括：涉及支付请求内容、隐私信息调用请求内容、有害信息推送请求内容等的至少之一。
90.示例性地，针对儿童或少年或者老龄人使用的第一设备，家长或者子女可以在配置页面执行相关输入操作，则第一设备会在检测到该输入操作之后生成相关配置，如此第一设备就会收不到一些危及用户财产安全、信息安全和/或身心健康的信息推送了。
91.在另一个实施例中，第一设备接收到请求消息后直接将请求消息作为应答消息返回给请求消息的发送方。例如，可以在请求消息中携带指示发送目标数据的指令并返回。第一设备可以将请求消息拷贝后返回给发送方，然后通过解析拷贝后的请求消息，确定请求消息是否为拒绝响应的请求消息。
92.在另一个实施例中，由于应答消息指示请求消息的发送方发送目标数据，因此确定请求消息是否为拒绝响应的请求消息，可以用于进一步确定第一设备是否需要接收请求消息对应的被发送的目标数据。当请求消息是拒绝响应的请求消息时，第一设备拒绝接收对应的目标数据。当请求消息不是拒绝响应的请求消息时，第一设备接收对应的目标数据。
93.在又一个实施例中，接收到的目标数据可用于直接转发至数据处理模块进行处理以在第一设备显示，或者也可以用于确定数据有效性，例如基于目标数据对应的url或请求参数等信息确定是否需要处理或拦截目标数据。
94.如此，在接收到请求消息后直接返回应答消息，同时在第一设备侧进行请求消息的验证，以确定是否需要响应。因此，对于请求消息的验证过程不会导致目标数据的发送过程被暂停，从而可以有效提高目标数据的接收和处理效率。基于验证请求消息是否需要响应，可以确定是否接收请求消息对应的目标数据，从而在实现对拒绝响应的网络请求及相应的数据进行过滤的基础上，可以大大提高需要响应及处理的请求消息和目标数据的处理速度，降低对第一设备中正常业务请求的负面影响。
95.在一些实施例中，所述s130，可包括：
96.通过解析所述请求消息，获取所述请求消息的发送方的第一特征，其中，所述第一特征至少包括：统一资源地址；
97.当所述第一特征与预先知晓的拒绝响应请求消息类型的第二特征匹配时，确定所述请求消息为拒绝响应的请求消息。
98.在本公开实施例中，第一特征可以包括统一资源地址url、ip地址或者其他标识信息等。第二特征可以为预先存储的表征第一设备拒绝响应的请求消息对应的url、ip地址或其他标识信息等，例如，第二特征可以记录在一个或多个特征表中。在解析得到第一特征后，可以调取第二特征所在的特征表等用于与第一特征进行比对验证。这里，特征表可以为广告请求特征列表或者请求特征信息黑名单等形式。
99.在一个实施例中，当第一特征与第二特征匹配时，例如当请求消息的发送方的url与广告请求url列表中的一个url匹配时，可以确定该请求消息是拒绝响应的请求消息，即第一设备不需要接收其对应的目标数据。此时，第一设备拒绝接收目标数据。
100.在另一个实施例中，第二特征可以为第一设备曾经接收过的拒绝响应请求消息的特征信息，也可以为第一设备向服务器或其它设备获取的拒绝响应的请求消息的特征信息。例如，第一设备将历史接收过的并且确定为拒绝响应的请求消息发送方的url，或者确定为拒绝处理的目标数据对应请求消息发送方的url，设置为第二特征并保存。
101.在又一个实施例中，当第一特征与预先知晓的拒绝响应请求消息类型的第二特征匹配时，可以包括第一特征与第二特征相同，或者，第一特征与第二特征存在预设关联关系。这里，预设关联关系可以包括：相似程度达到预设相似度条件，和/或内容关联度达到预设关联度条件等。
102.在又一个实施例中，若确定请求消息发送方的第一特征，表征与至少一个第二特征对应的请求消息发送方之间存在一定的相似度，则可以确定第一特征与第二特征匹配。
103.如此，基于与第二特征的比对匹配，可以快速准确地验证第一特征是否属于需要拒绝响应的请求消息的特征信息，进而可以更快地确定是否需要接收目标数据。
104.在一些实施例中，所述第二特征记录在特征表中；所述特征表包括：所述第一设备本地存储的第一特征表和/或从第二设备接收的第二特征表。
105.在本公开实施例中，第一设备中可以包含一个或多个记录第二特征的特征表，其中，可以包含第一设备本地存储的第一特征表，例如第一设备本地存储的本机广告url列表，和/或，包含第一设备从第二设备获取的第二特征表，例如服务器记录的云端广告url列表等。
106.这里，第一特征表中记录的第二特征，可以为第二特征表中记录的第二特征的子集，例如第一设备向服务器的第二特征表中获取第一设备侧所拥有的应用程序对应的第二
特征，并添加至第一特征表。
107.第一特征表中记录的第二特征，也可以为与第二特征表中记录的第二特征存在一定的交集。例如，第一特征表中记录的第二特征，包含第一设备与第二设备共同拥有的应用程序在第二特征表中对应的第二特征。
108.在一个实施例中，第一特征表和/或第二特征表，可以通过向各应用程序获取，例如调取应用程序服务器记录的屏蔽广告url信息等，添加至第一特征表和/或第二特征表中。
109.在一个实施例中，当特征表包括第一特征表和第二特征表时，当第一特征与预先知晓的拒绝响应请求消息类型的第二特征匹配时，确定请求消息为拒绝响应的请求消息可以包括：当第一特征与第一特征表中的第二特征匹配时，或者，当第一特征与第一特征表中的第二特征不匹配，且与第二特征表中的第二特征匹配时，确定请求消息为拒绝响应的请求消息。
110.示例性地，第一特征为请求消息的发送方的url，将第一特征与本机广告url列表比对，若匹配，则确定为拒绝响应的请求消息；若不匹配，则将第一特征与云端广告url列表比对，若匹配，则确定为拒绝响应的请求消息；若仍不匹配，则确定请求消息不是拒绝响应的请求消息。
111.这里，本机广告url列表可以设置一定的列表长度限制，例如设置为最多记录n条(例如，n等于200、300或500)条url。云端广告url列表可以为第一设备从云端服务器下载获取的，可以定时向云端进行同步。
112.在另一个实施例中，所述方法还可以包括：若第一特征与至少一个特征表中的第二特征均不匹配，则将第一特征记录在白名单中。
113.如此，基于本地存储和从其他设备获取的特征表，可以进一步提高对第一特征的筛选验证精准度，提高对拒绝响应的请求消息的过滤精度。
114.在一些实施例中，所述方法还包括：
115.在接收所述目标数据后，通过解析所述目标数据确定所述目标数据是否为拒绝处理的目标数据；
116.若所述目标数据不是拒绝处理的目标数据，则处理所述目标数据；其中，所述处理所述目标数据包括但不限于：显示所述目标数据和/或转发所述目标数据；
117.若所述目标数据是拒绝处理的目标数据，则删除所述目标数据或屏蔽所述目标数据的显示。
118.在本公开实施例中，由于在第一设备vpn建立初始，特征表中包含的第二特征可能较少，仍需依靠对接收到的目标数据进行解析确定是否为拒绝处理的非法目标数据。
119.在一个实施例中，通过解析目标数据确定目标数据是否为拒绝处理的目标数据，可以包括解析获取目标数据的发送方的url等特征信息，基于特征信息确定是否为拒绝处理的目标数据，或者，基于解析得到的目标数据的数据内容确定是否为拒绝处理的目标数据。
120.示例性地，解析目标数据的数据内容，确定数据内容是否包含与对应的应用程序关联程度低于预设条件的内容，或者，包含广告等非法数据内容。若包含，则确定目标数据为拒绝处理的目标数据。
121.在另一个实施例中，接收到目标数据后，若目标数据为拒绝处理的目标数据，则第一设备需要对目标数据进行拦截处理，例如删除，或者禁止显示目标数据，或将目标数据存入预设存储位置例如广告数据列表中。
122.在又一个实施例中，接收到目标数据后，若目标数据不是拒绝处理的目标数据，则对目标数据进行正常的处理操作，例如直接进行显示操作，或者转发至业务处理模块进行后续数据处理。
123.在另一个实施例中，若基于目标数据的特征信息(例如url)确定目标数据为拒绝处理的目标数据，则删除目标数据，并将目标数据的特征信息记录在特征表中作为第二特征，用于在下一次接收到请求消息时与其第一特征进行比对。
124.如此，在基于请求消息的第一特征对是否接收目标数据进行初步筛选后，基于目标数据的解析进一步确定是否处理或拦截接收到的目标数据，从而更好地弥补了特征表不完备导致第二特征无法准确过滤需要拦截的请求消息的第一特征。
125.在一些实施例中，所述通过解析所述目标数据确定所述目标数据是否为拒绝处理的目标数据，包括：
126.通过解析所述目标数据，获取所述目标数据的发送方的第三特征；所述第三特征至少包括：统一资源地址；
127.若所述第三特征与所述第一特征相同，则当所述第三特征与预先知晓的拒绝处理目标数据类型的第四特征匹配时，确定所述目标数据为拒绝处理的目标数据；
128.若所述第三特征与所述第一特征不同，则当所述第三特征与所述第四特征和/或所述第二特征匹配时，确定所述目标数据为拒绝处理的目标数据。
129.在本公开实施例中，通过解析确定目标数据的发送方的第三特征，可以包括url以及ip地址等特征信息。这里，由于请求消息的发送方在接收到应答消息后，可能通过自身再次发送目标数据，也可能通过另一个发送方发送目标数据。因而为更加准确地验证目标数据的有效性，基于目标数据的发送方的第三特征进行进一步比对验证。
130.在一个实施例中，当目标数据的第三特征与目标数据对应的请求消息的第一特征相同时，例如目标数据发送方的url与请求消息发送方的url相同，表征目标数据和请求消息为相同的发送方。因此，仅将第三特征与第四特征进行比对匹配，其中，第四特征可以记录于第三特征表中。例如第三特征表可以为一个返回拦截列表，用于记录需要拦截的返回的目标数据发送方的url。
131.这里，第三特征表可以与第一特征表共同存储在第一设备的本机中，也可以针对各应用程序的第三特征表，分别与每一应用程序的第一特征表共同存储于一个存储位置。
132.在一个实施例中，在调用第一特征表进行第一特征与第二特征的比对时，若确定请求消息不是拒绝响应的请求消息，则在第一特征表的存储位置调取与该第一特征表共同存储的第三特征表，用于在接收到目标数据后进行比对。
133.在另一个实施例中，当目标数据的第三特征与目标数据对应的请求消息的第一特征不同时，表征目标数据和请求消息为不同的发送方。因此，将第三特征与第二特征和第四特征分别进行比对匹配。例如，可以将第三特征与第一特征表、第二特征表和第三特征表中记录的第二特征和第四特征比对，若存在匹配，则目标数据为拒绝处理的目标数据。
134.在又一个实施例中，若目标数据为拒绝处理的目标数据，则将目标数据的发送方
的第三特征记录为第四特征和第二特征。例如可以将第三特征记录在返回拦截列表、本地广告url列表以及云端广告url列表中，从而实现返回拦截列表和广告url列表的更新。
135.在另一个实施例中，记录第四特征的返回拦截列表，可以设置为定期删除过期特征信息。例如，记录每个第四特征存入返回拦截列表的存储时刻，当存储时刻与当前时刻的时间间隔超出预设间隔时，删除对应的第四特征。如此，可以保持第四特征的时效性，且减少第四特征占据的存储资源。
136.在一个实施例中，第三特征与第四特征匹配，可以包括第三特征与第四特征相同，或者，第三特征与第四特征存在预设关联关系。这里，预设关联关系可以包括：相似程度达到预设相似度条件，和/或内容关联度达到预设关联度条件等。
137.在又一个实施例中，若确定目标数据发送方的第三特征，表征与至少一个第四特征对应的数据发送方之间存在的相似度达到预设相似度条件，则可以确定第三特征与第四特征匹配。
138.如此，无论目标数据的发送方相较于请求消息的发送方是否发生改变，都可以基于目标数据进行进一步的匹配筛选，从而提高对广告数据等需要拦截的数据的过滤精度。
139.在一些实施例中，所述方法还包括：
140.若所述第一特征与预先知晓的允许响应的请求消息类型的第五特征匹配，确定所述请求消息不是拒绝响应的请求消息；
141.所述当所述第一特征与预先知晓的拒绝响应请求消息类型的第二特征匹配时，确定所述请求消息为拒绝响应的请求消息，包括：
142.若所述第一特征与所述第五特征不匹配，当所述第一特征与预先知晓的拒绝响应请求消息类型的第二特征匹配时，确定所述请求消息为拒绝响应的请求消息。
143.在本公开实施例中，第五特征表征允许响应的请求消息的特征信息，例如，可以记录在请求消息url白名单中。基于白名单中第五特征对第一特征进行匹配确认，可以对频繁接收的正常业务请求进行更快速的验证，无需进行后续第二特征的比对，即可确认接收对应的目标数据。
144.在一个实施例中，所述方法还可以包括：若第一特征与第五特征不匹配，则将第一特征与预设的请求拦截列表进行比对。请求拦截列表中记录了预设的需要拦截的请求消息的发送方url，可以作为请求消息url黑名单。
145.在另一个实施例中，所述在接收到所述请求消息后，向所述请求消息的发送方返回应答消息，可包括：在接收到所述请求消息后，若第一特征与第五特征匹配，向所述请求消息的发送方返回应答消息；若第一特征与第五特征不匹配，比对所述第一特征与请求拦截列表中的特征信息；若第一特征与请求拦截列表中的特征信息不匹配，则向所述请求消息的发送方返回应答消息。
146.在又一个实施例中，所述方法还可以包括：若第一特征与第五特征匹配若第一特征与请求拦截列表中的特征信息匹配，则向请求消息的发送方返回空消息，以阻止发送方返回目标数据。
147.在又一个实施例中，若第一特征与第五特征不匹配，且与请求拦截列表中的特征信息不匹配，则向请求消息发送方返回应答消息，并基于第一特征与第二特征的比对确定是否为拒绝响应的请求消息。
148.这里，请求拦截列表可以与第一特征表和/或第三特征表共同存储在第一设备的本机中，也可以针对各应用程序的请求拦截列表，分别与每一应用程序的第一特征表和/或第三特征表共同存储于一个存储位置。
149.在一个实施例中，在调用请求拦截列表进行特征的比对时，若确定不匹配并返回应答消息，则在请求拦截列表的存储位置调取与该请求拦截列表共同存储的第一特征表，用于继续进行第一特征和第二特征的比对。
150.如此，基于白名单中的第五特征对请求消息进行初步筛选，从而提高白名单中记录的正常业务请求的处理速度，进一步降低非法请求消息验证与过滤对正常请求消息处理效率的影响。
151.在一些实施例中，所述方法还包括：
152.若所述第三特征与所述第四特征匹配，则基于所述第三特征对应的目标数据确定所述目标数据对应的请求消息；
153.将所述目标数据对应的请求消息的第一特征添加到所述第二特征。
154.在本公开实施例中，若第三特征与第四特征匹配表征接收到的目标数据是拒绝处理的目标数据，且对应的请求消息的第一特征未匹配第二特征，表明该拒绝处理的目标数据对应的请求消息并未被认为是拒绝响应的请求消息。因此，将对应的第一特征添加到第二特征，可以及时更新记录的第二特征，将该第一特征对应的请求消息可被认定为拒绝响应的请求消息，从而相较于目标数据阶段的验证，可以更早地确定拒绝响应及拒绝接收目标数据，便于更准确高效地进行特征比对验证。
155.在一些实施例中，所述方法还包括：
156.若所述第一特征与所述第二特征不匹配，则将所述第一特征添加到所述第五特征。
157.在本公开实施例中，若第一特征与第二特征不匹配，表征请求消息不是拒绝响应的请求消息，则可以将请求消息的第一特征添加到第五特征。例如，将第一特征添加至记录第五特征的白名单中，从而及时更新第五特征，便于进一步前置特征比对结果，基于白名单的匹配可以免除后续与第二特征的比对过程，进而更好地实现正常业务请求的快速验证。
158.在一个实施例中，若第一特征与第二特征匹配，则将第一特征添加至请求拦截列表，从而将拒绝响应的请求消息的识别进一步前置，更好地加快下一次请求消息验证的效率。
159.在一些实施例中，所述特征表存储于具备固定的预设容量的先进先出fifo队列中。
160.这里，先进先出(first input first output，fifo)队列用于存储特征表中的第二特征，且当fifo队列中存储的第二特征数量达到预设容量后，每插入一个新的第二特征，会按队列中第二特征存储时刻的先后顺序，依次删除一个第二特征，从而实现存储的第二特征为最新的一定数量的第二特征。
161.在一个实施例中，第一特征表和第二特征表对应的fifo队列预设容量可以相同，例如均为500，也可以不同。
162.在另一个实施例中，第四特征和/或第五特征也可以记录在特征表中，并存储在具备固定容量的fifo队列中。
163.在一些实施例中，所述方法还包括：
164.每隔预设时长基于所述第一设备包含的至少一个第一特征表对应的应用程序，将所述应用程序对应的第二特征表中的第二特征，写入所述应用程序对应的第一特征表中。
165.在本公开实施例中，每隔预设时长基于第二设备的第二特征表对第一设备中的第一特征表进行更新，例如，基于服务器存储的第二特征，定期更新第一特征表中的第二特征。这里，应用程序对应的第二特征表，可以向一个服务器获取，也可以向各应用程序分别对应的服务器获取。
166.在一个实施例中，第二设备中可能包含与第一设备不同的应用程序的第二特征表，因而首先确定第一设备中第一特征表对应的应用程序，进而在第二设备中查询与所述应用程序对应的第二特征表。
167.在另一个实施例中，将各应用程序的第二特征表中的第二特征分别写入对应的第一特征表，可以为将预设时长内第二特征表中新增的第二特征写入对应的第一特征表，或者，也可以为将第二特征表中包含的且第一特征表未记录的第二特征写入第一特征表。
168.如图2所示，本公开实施例提供一种请求处理装置，应用于第一设备，所述装置包括：
169.第一接收单元10，用于接收请求消息；
170.返回单元20，用于在接收到所述请求消息后，向所述请求消息的发送方返回应答消息；所述应答消息，用于指示所述请求消息的发送方获取待处理的目标数据；
171.解析单元30，用于通过解析所述请求消息，确定所述请求消息是否为拒绝响应的请求消息；
172.第二接收单元40，用于当所述请求消息不是拒绝响应的请求消息时，接收所述目标数据；当所述请求消息是拒绝响应的请求消息时，拒绝接收所述目标数据。
173.在一些实施例中，所述解析单元30，具体用于：
174.通过解析所述请求消息，获取所述请求消息的发送方的第一特征，其中，所述第一特征至少包括：统一资源地址；
175.当所述第一特征与预先知晓的拒绝响应请求消息类型的第二特征匹配时，确定所述请求消息为拒绝响应的请求消息。
176.在一些实施例中，所述第二特征记录在特征表中；所述特征表包括：所述第一设备本地存储的第一特征表和/或从第二设备接收的第二特征表。
177.在一些实施例中，所述解析单元30，还用于：
178.在接收所述目标数据后，通过解析所述目标数据确定所述目标数据是否为拒绝处理的目标数据；
179.所述装置还包括：
180.处理单元，用于若所述目标数据不是拒绝处理的目标数据，则处理所述目标数据；若所述目标数据是拒绝处理的目标数据，则删除所述目标数据。
181.在一些实施例中，所述解析单元30，具体用于：
182.通过解析所述目标数据，获取所述目标数据的发送方的第三特征；所述第三特征至少包括：统一资源地址；
183.若所述第三特征与所述第一特征相同，则当所述第三特征与预先知晓的拒绝处理
目标数据类型的第四特征匹配时，确定所述目标数据为拒绝处理的目标数据；
184.若所述第三特征与所述第一特征不同，则当所述第三特征与所述第四特征和/或所述第二特征匹配时，确定所述目标数据为拒绝处理的目标数据。
185.在一些实施例中，所述解析单元30，还用于：
186.若所述第一特征与预先知晓的允许响应的请求消息类型的第五特征匹配，确定所述请求消息不是拒绝响应的请求消息；
187.所述解析单元30，具体用于：
188.若所述第一特征与所述第五特征不匹配，当所述第一特征与预先知晓的拒绝响应请求消息类型的第二特征匹配时，确定所述请求消息为拒绝响应的请求消息。
189.在一些实施例中，所述装置还包括：
190.第一添加单元，用于若所述第三特征与所述第四特征匹配，则基于所述第三特征对应的目标数据确定所述目标数据对应的请求消息；将所述目标数据对应的请求消息的第一特征添加到所述第二特征。
191.在一些实施例中，所述装置还包括：
192.第二添加单元，用于若所述第一特征与所述第二特征不匹配，则将所述第一特征添加到所述第五特征。
193.在一些实施例中，所述特征表存储于具备固定的预设容量的先进先出fifo队列中。
194.在一些实施例中，所述装置还包括：
195.更新单元，用于每隔预设时长基于所述第一设备包含的至少一个第一特征表对应的应用程序，将所述应用程序对应的第二特征表中的第二特征，写入所述应用程序对应的第一特征表中。
196.以下结合上述任一实施例提供一个具体示例：
197.本公开实施例提供一种广告拦截方法，在手机端创建vpn，通过vpn获取所有的网络请求，对网络请求拷贝后直接发送，对拷贝后的数据与预设条件进行比对，通过比对结果拦截返回的广告数据。这种方案可以高效拦截手机中app的广告请求，从而达到屏蔽广告的目的。
198.如图3所示，本公开实施例基于vpn的广告拦截方法，在手机端创建vpn，这样可以获取手机的所有网络请求。
199.发送过程：
200.在获取网络请求后，提取其中的url，并判断该url是否在网络请求白名单(该名单是一个先进先出队列，有固定长度，例如200；并且只在内存维护，每次vpn进程重启都会清空重置)中。如果在，则直接发送请求；如果不在，则判断其是否在请求拦截列表中。
201.请求拦截列表和网络请求白名单一样，也是一个先进先出队列，有固定的长度，例如100；并且它是一个内存值，每次vpn进程重启都会清空重置。如果上个步骤中的url存在于请求拦截列表，则拦截，并基于该请求返回假数据；如果不在，则发送请求，并在拦截请求线程中判断该url是否在本机广告列表中。
202.本机广告列表是本手机已经请求过的广告url，既在内存中维护，又持久化存储，设置较大的长度限制，如500。如果上个步骤中的url存在于本机广告列表中，则把该url插
入请求拦截列表和返回拦截列表中；如果不在，则判断是否在云广告黑名单中。
203.云广告黑名单是本机持久化存储的广告黑名单，定期同云端同步，如果上个步骤中的url存在于云广告黑名单，则把该url插入请求拦截列表、返回拦截列表以及本机广告列表中；如果不在，则插入网络白名单中。
204.返回过程：
205.如果返回拦截列表为空，则不进行返回拦截；反之，则需要获取网络返回的数据及其对应的url。
206.判断url是否在返回拦截列表(该列表只在内存中维护，每次vpn进程重启，会清空重置)中，如果存在，则拦截，返回假数据；如果不存在，则正常返回数据。
207.返回拦截列表需要记录存入每个数据的时间，一段时间(例如10秒)以后，删除过期数据。
208.这里，本公开实施例通过设置多级黑白名单使效率达到了很高的水平，同时内存占用、性能消耗都维持在较低的水平。
209.vpn进程创建并开始拦截的时候，会逐渐填充网络白名单、请求拦截列表、返回拦截列表(本机广告列表暂时不提)。此时的拦截主要靠返回拦截列表，但是随着时间的推移，拦截会逐渐前置，返回拦截列表会逐渐清空，主要起作用的是请求拦截列表。
210.手机中非广告的网络请求还是最多的，网络白名单的设置是为了提高这些请求的效率的，频繁发生的请求只需要一次判断就可以走完整个流程。请求拦截列表的作用也一样，随着请求拦截列表的填充。频繁发生的广告请求只需要两次判断就会返回假数据，完成拦截。
211.网络白名单、请求拦截列表、返回拦截列表只在内存中维护，并且前两个列表长度是有限的。用户在不同时间段、不同的使用场景下使用的app是不一样的，触发的网络请求也是不一样的。要逐渐填充、更新这些列表，是为了保持正常请求和广告拦截的高效，只需要检索很短的列表。
212.本机广告列表是云广告黑名单的一个子集，它的设置也是为了提高检索效率，毕竟云广告黑名单是从很多app中提炼出来的广告url，本手机可能只包含其中的几个app，每次更新云广告黑名单都会和本机广告列表取交集来更新本机广告列表。
213.云广告黑名单可以是在各个app中提取的，定期更新，手机在无线网络下，会定期同步。
214.本公开实施例提供一种电子设备，包括：
215.用于存储处理器可执行指令的存储器；
216.处理器，与存储器连接；
217.其中，处理器被配置为执行前述任意技术方案提供的请求处理方法。
218.处理器可包括各种类型的存储介质，该存储介质为非临时性计算机存储介质，在电子设备掉电之后能够继续记忆存储其上的信息。
219.处理器可以通过总线等与存储器连接，用于读取存储器上存储的可执行程序，例如，能够执行前述一个或多个技术方案所述方法。
220.本公开一实施例提供一种电子设备的结构。电子设备包括处理组件，其进一步包括一个或多个处理器，以及由存储器所代表的存储器资源，用于存储可由处理组件的执行
的指令，例如应用程序。存储器中存储的应用程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外，处理组件被配置为执行指令，以执行上述方法应用在所述电子设备的任意方法，例如，前述一个或多个技术方案所述方法。
221.电子设备还可以包括一个电源组件被配置为执行电子设备的电源管理，一个有线或无线网络接口被配置为将电子设备连接到网络，和一个输入输出(i/o)接口。电子设备可以操作基于存储在存储器的操作系统，例如windows server tm，mac os xtm，unixtm，linuxtm，freebsdtm或类似。
222.本公开实施例提供一种非临时性计算机可读存储介质，当存储介质中的指令由计算机的处理器执行时，使得计算机能够执行前述一个或多个技术方案所述的请求处理方法。
223.本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本公开旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由下面的权利要求指出。
224.应当理解的是，本公开并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本公开的范围仅由所附的权利要求来限制。