CN104796279A - 请求包的处理方法和装置 - Google Patents

Abstract

本发明公开了一种请求包的处理方法和装置。其中，该方法包括：监视在客户端上运行的目标应用所发出的请求包；判断请求包是否满足拦截条件，其中，拦截条件至少包括：请求包用于指示客户端执行对目标文件的下载操作；若满足拦截条件，则拦截请求包，并生成与目标文件对应的提示信息，用于使客户端的用户根据提示信息输入指示信息；根据获取的指示信息的指示处理拦截的请求包。本发明解决了运行中的目标应用可能会造成客户端下载到非用户所需的下载对象的技术问题。

Description

请求包的处理方法和装置

技术领域

本发明涉及互联网应用领域，具体而言，涉及一种请求包的处理方法和装置。

背景技术

目前，智能手机作为其使用者的延伸已经得到了相当广泛的应用，主要服务于智能手机用户的无线网络如WIFI和3G网络等也得到了推广，然而在当前的网络环境下，用户在使用智能手机、尤其是对网络上的一些资源进行下载时，仍然需要考虑流量的限制，然而出于盈利的考虑，相当一部分在智能手机上运行的应用在其用户界面上会设置有容易被点击到的外部链接区域，而在用户误点到该区域时，智能手机可能会自动地开始对于该区域对应的下载对象的下载，从而为用户带来不必要的流量开销。

针对上述的问题，目前尚未提出有效的解决方案。

发明内容

本发明实施例提供了一种请求包的处理方法和装置，以至少解决运行中的目标应用可能会造成客户端下载到非用户所需的下载对象的技术问题。

根据本发明实施例的一个方面，提供了一种请求包的处理方法，包括：监视在客户端上运行的目标应用所发出的请求包；判断上述请求包是否满足拦截条件，其中，上述拦截条件至少包括：上述请求包用于指示上述客户端执行对目标文件的下载操作；若满足上述拦截条件，则拦截上述请求包，并生成与上述目标文件对应的提示信息，用于使上述客户端的用户根据上述提示信息输入指示信息；根据获取的上述指示信息的指示处理拦截的上述请求包。

根据本发明实施例的另一方面，还提供了一种请求包的处理装置，包括：监视单元，用于监视在客户端上运行的目标应用所发出的请求包；判断单元，用于判断上述请求包是否满足拦截条件，其中，上述拦截条件至少包括：上述请求包用于指示上述客户端执行对目标文件的下载操作；拦截单元，用于在满足上述拦截条件时，拦截上述请求包，并生成与上述目标文件对应的提示信息，上述提示信息用于使上述客户端的用户根据上述提示信息输入指示信息；处理单元，用于根据获取的上述指示信息的指示处理拦截的上述请求包。

在本发明实施例中，通过对目标应用所发出的请求包的监视，可以对满足一定拦截条件的、用于下载目的的请求包进行拦截，然后通过客户端向用户提示与该请求包所指示下载的目标文件相对应的提示信息，进而可以根据用户反馈的指示信息来选择是否继续发送被拦截的该请求包。在上述场景下，由于用户需要对该请求包所指示的下载目标文件的操作进行确认才会继续对请求包的处理，因此可以在一定程度上避免客户端对非用户所需的下载对象的下载，进而解决了运行中的目标应用可能会造成客户端下载到非用户所需的下载对象的问题。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本发明实施例的一种可选的请求包的处理方法的示意图；

图2是根据本发明实施例的一种可选的请求包的处理装置的示意图；

图3是根据本发明实施例的另一种可选的请求包的处理方法的示意图。

具体实施方式

为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。

需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

实施例1

根据本发明实施例，提供了一种请求包的处理方法，如图1所示，该方法包括：

S102：监视在客户端上运行的目标应用所发出的请求包；

S104：判断请求包是否满足拦截条件，其中，拦截条件至少包括：该请求包用于指示客户端执行对目标文件的下载操作；

S106：若满足拦截条件，则拦截请求包，并生成与目标文件对应的提示信息，用于使客户端的用户根据提示信息输入指示信息；

S108：根据获取的指示信息的指示处理拦截的请求包。

应当理解的是，本发明技术方案所要解决的问题之一是提供一种方法，通过对目标应用的下载监控，避免客户端下载到非用户所需的一些下载对象，进而为客户端及其用户免除不必要的下载流量开销。

具体地，在本发明实施例中，上述客户端下载到非用户所需的下载对象通常是由于目标应用中所嵌入的外部链接所造成的。例如，在一个场景下，本发明实施例所提供的方法可以应用于作为客户端的智能手机，在该智能手机上，可以安装并运行有作为目标应用的视频播放应用，其中，该视频播放应用在运行过程中，比如该应用由播放模式切换到暂停模式、或者是该应用处于播放模式的时长超过某一阈值时，该应用可能会在智能手机的用户界面上创建一个与某一外部链接相对应的热区，进而该智能手机在识别到位于该热区内的点击事件后，可以响应于该点击事件进一步地执行与该外部链接对应的下载操作，其中，该点击事件通常来自于用户在智能手机的触屏上的触碰动作。然而站在用户的角度，用户所做出的触碰动作并不一定表示其“想要下载”的主观意愿，例如，在一个实例中，由视频播放应用创建的上述热区中可以显示有某一款手机游戏的广告，该广告提供了该款手机游戏的安装包的下载链接，却并未在广告中明确地给出“点击开始下载”的文字提示，在这一情形下，用户对热区的点击可能仅仅是出于对广告图像的兴趣、想要进一步地访问该款游戏的官网页面，而非直接下载游戏的安装包。在上述情形下，用户的触碰动作及智能手机所识别到的点击事件可以视为是被视频播放应用及其中嵌入的广告链接所误导的，因而客户端响应于点击事件所执行的下载操作可以视为是被动地，并且这一被动地下载操作将会给客户端及用户带来不必要的下载流量开销。

当然，以上只是一种示例，并非是对本发明及其应用场景的限定，例如，在本发明的一些实施例中，用户的触碰动作及点击事件也可以来自于用户自身所做出的或主动或被动的误操作，比如在一个实施例中，作为客户端的智能手机上可以运行有作为目标应用的一款手机游戏，该游戏在运行时可能会定时生成与某一下载链接对应的弹出页，从而用户在体验游戏的过程中、以较高的频率连续触碰智能手机的触屏时，很可能无法及时地对该弹出页做出反应，导致相对被动地误点到弹出页并产生相应的点击事件，进而导致客户端被动地下载非用户所愿的下载对象。

事实上，在本发明实施例中，并不会对用户的主观意愿进行观测，而是基于对客户端的改进以提供一种对目标应用的监控机制，并在监视到目标应用发出下载请求后对用户进行提示，比如在用户界面上生成一个确认选择对话框，进而可以由用户来确认是否继续下载，这就解决了运行中的目标应用可能会造成客户端下载到非用户所需的下载对象的问题。

以下将结合附图并通过一些具体的实施例对本发明技术方案及其工作原理进行更为详细的描述。

根据本发明实施例提供的处理方法，在步骤S102中，可以监视在客户端上运行的目标应用所发出的请求包，其中，该目标应用可以表示作为监视目标的应用。具体地，在本发明实施例中，上述请求包通常可以是超文本传输协议http（Hypertext TransferProtocol）请求，然而本发明对此不作限定，例如，在本发明的一些实施例中，该请求包也可以是文件传输协议ftp（File Transfer Protocol）请求，或者是符合其他可行的文本传输格式的请求包等。更具体地，该请求可以表现为一个消息，例如，对于http请求而言，其所对应的消息可以由请求行、消息头和消息体组成。当然，这只是一种实例，本发明对此不作任何限定，例如，对于请求行中所声明的请求方法为GET方法时，上述消息中也可以不存在上述消息体，而是将查询参数设置在同处于请求行中的统一资源定位符URL（Uniform Resource Locator）中，等。

在本发明实施例中，针对步骤S102中所述的请求包的监视可以有多种实现方式，例如，作为一种可行的方式，在步骤S102之前，上述方法可以包括：

S2：获取在客户端上运行的系统的管理权限，其中，上述目标应用运行于该系统中，管理权限用于授权以下操作至少之一：对请求包的监视、对请求包的拦截、对请求包的发送。

例如，对于广泛应用在智能手机上的安卓（Android）操作系统而言，为实现对目标应用所发出的请求包的监视，用于实施上述方法的处理装置可以先获取安卓系统的超级用户权限或者说root权限，从而获取对该系统上运行的应用的管理权限，其中，该管理权限可以用于授权以下操作至少之一：对请求包的监视、对请求包的拦截、对请求包的发送，以便于步骤S102中的监视操作以及后续步骤S106和S108中对请求包的判断及处理操作。具体地，在本发明实施例中，上述超级用户权限可以通过用户切换（Switch User）文件来获取，然而本发明对此不作限定。

当然，以上只是一种示例，并非本发明唯一的实施方式，例如，在本发明的一些实施例中，对于官方未提供root权限的系统、比如苹果公司所开发的IOS操作系统而言，也可以利用这些系统所开放的功能接口来实现对目标应用所发出的请求包的监视，此外，在本发明的另一些实施例中，步骤S102中所述的对请求包的监视也可以通过现有的抓包软件来实现，本发明对此均不作任何限定。

进一步地，作为一种可选的方式，在本发明实施例中，步骤S102可以包括：

S4：判断在客户端上运行的任一应用是否保存在预设的监视列表内，其中，监视列表维护在客户端的本地和/或与客户端连接的服务器上；和/或，

S6：判断任一应用是否处于活动状态；

S8：若任一应用保存在监视列表内和/或任一应用处于活动状态，则将该任一应用作为目标应用，并监视该任一应用所发出的请求包。

在本发明实施例中，可以选择性地对客户端上运行的全部应用中的一个或多个进行监视，以达到节约系统资源的效果。具体地，作为一种可行的方式，可以建立一个监视列表，该监视列表中可以保存有由客户端及其用户或者是与客户端连接的服务器所预先设置的一个或多个应用，进而处理装置可以将保存在监视列表中的应用作为目标应用进行监视，其中，监视列表中所保存的应用通常可以是在一个时期内用户使用频度较高的一些应用、或者是某一类型的易于植入广告的应用，而其他的一些应用、比如长时间运行在系统后台的应用则可以排除在监视列表之外，从而可以在基本对非用户所需的下载对象的拦截的基础上，进一步地达到节约系统资源的效果。

除此之外，作为另一种可行的方式，在本发明实施例中，还可以判断客户端上运行的任一应用是否处于活动状态，进而处理装置可以对处于活动状态的应用进行监控，并忽略掉处于不活动状态的应用，其中，由于在通常情况下通过用户操作所导致的非用户所需的下载发生在处于活动状态下的应用中，因而通过上述方式同样可以在基本保证对非用户所需的下载对象的拦截的基础上，进一步地达到节约系统资源的目的。具体的，在本发明实施例中，对任一应用是否处于活动状态的判断通常也可以通过对该任一应用的状态的监视来实现，例如，可以在监视到任一应用的状态为“active”时将其判断为活动状态，而“inactive”则可以判断为不活动状态。

当然，上述两种可行的实施方式仅用作示例，而非对本发明的限定，例如，上述两种方式也可以结合起来实施，例如，在前一实施例中所提供的预设的相对静态的监视列表的基础上，还可以进一步地筛选出一个相对动态的监视列表，该动态的监视列表中可以保存有属于上述预设的监视列表的、且处于活动状态下的全部应用，其中，需要说明的是，本发明技术方案还可以与任何现有的或未来的可行的技术手段进行结合，以达到更优的效果，应当理解，此类实施方式仍应视为在本发明的保护范围之内。

在以上描述的基础上，根据本发明实施例提供的处理方法，在步骤S104中，可以判断请求包是否满足拦截条件，其中，该拦截条件至少可以包括：请求包用于使客户端执行对目标文件的下载，换而言之，在本发明实施例中，处理装置可以仅针对目标应用所发出的用于下载目的请求包进行拦截，从而可以在实现对非用户所需的下载对象的拦截的基础上，进一步地达到节约系统资源的效果。其中，上述下载对象通常可以是存储在客户端的外部的某一文件资源，其中，为表述方便，并避免非用户所需的下载对象这一表述可能造成的错误解释，以下将用于下载目的的请求包所指示下载的目标记为目标文件。更具体地，在本发明实施例中，该目标文件的具体表现形式可以有很多种，例如其可以是文本、图像、视频、音频、表格、样式等内容相对单一的文件或者其结合，也可以是如前所述的安装文件等具有特定格式的不同类型的文件，这并不影响本发明技术方案的实施及其技术效果的实现，本发明对此也不作任何限定。

具体地，在本发明实施例中，对请求包是否用于下载目的的判断方式可以有多种，例如，作为一种可选的方式，上述步骤S104可以包括：

S10：判断请求包中是否存在用于标识下载操作的下载标识，若存在，则判断出请求包满足拦截条件，若不存在，则判断出请求包不满足拦截条件，其中，一个或多个下载标识维护在客户端的本地和/或与客户端连接的服务器上。

在本发明实施例中，在客户端的本地和/或服务器上可以预先设置有用于标识下载操作的下载标识，其中，该下载标识通常还可以作为一种可识别的字段来指示客户端执行对应的下载操作，例如，在本发明的一些实施例中，上述下载标识可以是html标准字段“download”，从而处理装置在请求包所携带的URL中解析出来这一字段后既可以判断出该请求包用于指示客户端执行下载操作，进而判断出该请求包满足拦截条件，然而本发明对此不作限定。

进一步可选地，在本发明实施例中，在用于判断请求包是否用于下载目的拦截条件外，步骤S104中所述的拦截条件还可以包括更多，例如，作为一种可选的方式，步骤S104还可以包括：

S12：判断目标文件是否属于预设类型，若属于，则判断出请求包满足拦截条件，其中，拦截条件还包括：请求包所指示下载的目标文件属于预设类型。

在这一场景下，处理装置可以在判断出请求包用于下载目的的基础上，进一步地判断请求包所指示下载的目标文件是否属于预设类型，并在该目标文件属于预设类型时判断出该请求包满足拦截条件，从而可以进一步地提高处理效率并节约系统资源。例如，在一些实施例中，上述预设类型可以设置为安装文件，或者是图像文件等尺寸较大的文件，等。

进一步地，本发明实施例提供了一种可行的用于判断目标文件所属类型的实施方式，其中，上述步骤S12可以包括：

S14：判断请求包中记录的目标文件的后缀是否属于与预设类型对应的后缀，若是，则判断出请求包满足拦截条件，其中，与预设类型对应的一个或多个后缀维护在客户端的本地和/或与客户端连接的服务器上。

例如，在一个实施例中，可以将拦截条件设置为：1）请求包用于指示客户端执行对目标文件的下载操作；以及2）该目标文件为安装文件，其中，为判断目标文件是否属于安装文件这一预设类型，则可以通过步骤S14判断该目标文件的后缀是否为“.apk”或“ipa”等，其中，“.apk”为适用于安卓系统的安装文件，“.ipa”为适用于IOS系统的安装文件，然而本发明对此不作限定，与预设类型对应的一个或多个后缀也可以设置为可行的其他后缀名。

在以上描述的基础上，根据本发明实施例提供的处理方法，在步骤S106中，可以进一步地在判断出满足上述拦截条件后，对满足拦截条件的请求包进行拦截，并生成与该请求包对应的提示信息，以便于使该客户端的用户可以根据提示信息输入指示信息，进而在步骤S108中，可以获取的指示信息的指示处理拦截的请求包。

具体地，在本发明实施例中，对满足拦截条件的请求包进行拦截的具体实施方式通常可以表现为停止对上述请求包的发送，并通过客户端的显示界面提供方便用户确认的提示信息，进而可以在步骤S108中接收到用户向客户端输入的指示信息后选择是否继续发送被拦截的该请求包。在上述场景下，由于用户需要对该请求包所指示的下载目标文件的操作进行确认才会继续对请求包的处理，因此可以在一定程度上避免客户端对非用户所需的下载对象的下载，进而解决了运行中的目标应用可能会造成客户端下载到非用户所需的下载对象的问题。

值得注意的是，本发明对于上述拦截操作以及对请求包的后续处理操作并不作限定，例如，在本发明实施例中，上述提示信息通常可以表现为确认选择对话框，一般地，该对话框上可以显示有选项“是”和“否”，其中，“是”可以用于指示客户端继续发送请求包以下载对应的目标文件，“否”可以用于指示客户端不再发送该请求包，然而在本发明的一些实施例中，上述提示信息也可以通过图像信息或者是语音信息提示给用户，对应地，处理装置所获取的指示信息也可以采用语音信息的形式，以进一步地方便用户的使用，本发明对此不作限定。

进一步地，在本发明实施例中，上述提示信息所包含的信息内容除上述用于确认下载与否的下载确认信息之外，还可以包括目标文件的文件名、文件大小、文件的提供者、以及文件的安全认证相关的信息等，以便于用户根据这些信息内容来选择是否下载目标文件或者是相对更为复杂的处理方式。换而言之，在本发明实施例中，上述步骤S106中所述的生成与目标文件对应的提示信息的操作可以包括：

S16：生成与目标文件对应的以下至少之一的提示信息：文件名、文件大小、提供者、下载确认信息、安全认证信息，其中，该提示信息包括以下至少之一：文字信息、图形信息、声音信息。

最后，通过本发明实施例提供一种对请求包进行拦截的具体的实施方式，以及对请求包的更为复杂的处理方式，其中，如图3所示，可选地，步骤S106中所述的拦截请求包的操作可以包括：

S302：将一个或多个满足拦截条件的请求包添加到待发送列表中；

其中，生成与目标文件对应的提示信息的操作可以包括：

S304：生成与待发送列表中的每一请求包所指示下载的目标文件相对应的提示信息；

其中，步骤S108可以包括以下至少之一：

S306：若获取的指示信息用于指示确认下载任一目标文件，则发送与任一目标文件对应的请求包，并将与任一目标文件对应的请求包从待发送列表中清除；

S308：若获取的指示信息用于指示暂停下载任一目标文件，则将与任一目标文件对应的请求包继续保存在待发送列表中；

S310：若获取的指示信息用于指示拒绝下载目标文件，则将请求包从待发送列表中清除；

S312：若获取的指示信息用于指示屏蔽目标文件，则将请求包从待发送列表中清除，并将与目标文件对应的标识项添加到屏蔽列表中，其中，上述拦截条件还包括：请求包中存在该标识项。

通过上述方式，给出了一种基于待发送列表的拦截及后续处理操作的实现方式，其中，通过对该待发送列表的管理，在一方面可以方便地向用户展示提示信息，在另一方面可以方便地响应于用户所反馈的指示信息对相应的请求包进行处理，其中，本领域技术人员应当理解的是，上述实施例中所称的待发送列表可以并不限于是表格的形式。

通过以上实施例，对本发明技术方案及其工作原理进行了描述，然而应当理解的是，上述实施例仅用于对本发明的理解，而不应视为对本发明的限定。值得注意的是，虽然在上述实施例中以智能手机为例对本发明的实施场景进行了描述，然而这并不意味着对本发明构成了限定，例如，在本发明的一些实施例中，上述处理方法也可以实施在计算机，以避免用户在使用计算机、比如通过浏览器对网页进行浏览时由于误操作所造成的对非用户所需的下载对象的下载，其具体的工作原理与上述实施例中所述的类似，本发明在此不作累述。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到根据上述实施例的方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质（如ROM/RAM、磁碟、光盘）中，包括若干指令用以使得一台终端设备（可以是手机，计算机，服务器，或者网络设备等）执行本发明各个实施例所述的方法。

实施例2

根据本发明实施例，还提供了一种用于实施上述请求包的处理方法的处理装置，如图2所示，该装置包括：

1）监视单元202，用于监视在客户端上运行的目标应用所发出的请求包；

2）判断单元204，用于判断请求包是否满足拦截条件，其中，拦截条件至少包括：请求包用于指示客户端执行对目标文件的下载操作；

3）拦截单元206，用于在满足拦截条件时，拦截请求包，并生成与目标文件对应的提示信息，提示信息用于使客户端的用户根据提示信息输入指示信息；

4）处理单元208，用于根据获取的指示信息的指示处理拦截的请求包。

应当理解的是，本发明技术方案所要解决的问题之一是提供一种装置，通过对目标应用的下载监控，避免客户端下载到非用户所需的一些下载对象，进而为客户端及其用户免除不必要的下载流量开销。

具体地，在本发明实施例中，上述客户端下载到非用户所需的下载对象通常是由于目标应用中所嵌入的外部链接所造成的。例如，在一个场景下，本发明实施例所提供的装置可以应用于作为客户端的智能手机，在该智能手机上，可以安装并运行有作为目标应用的视频播放应用，其中，该视频播放应用在运行过程中，比如该应用由播放模式切换到暂停模式、或者是该应用处于播放模式的时长超过某一阈值时，该应用可能会在智能手机的用户界面上创建一个与某一外部链接相对应的热区，进而该智能手机在识别到位于该热区内的点击事件后，可以响应于该点击事件进一步地执行与该外部链接对应的下载操作，其中，该点击事件通常来自于用户在智能手机的触屏上的触碰动作。然而站在用户的角度，用户所做出的触碰动作并不一定表示其“想要下载”的主观意愿，例如，在一个实例中，由视频播放应用创建的上述热区中可以显示有某一款手机游戏的广告，该广告提供了该款手机游戏的安装包的下载链接，却并未在广告中明确地给出“点击开始下载”的文字提示，在这一情形下，用户对热区的点击可能仅仅是出于对广告图像的兴趣、想要进一步地访问该款游戏的官网页面，而非直接下载游戏的安装包。在上述情形下，用户的触碰动作及智能手机所识别到的点击事件可以视为是被视频播放应用及其中嵌入的广告链接所误导的，因而客户端响应于点击事件所执行的下载操作可以视为是被动地，并且这一被动地下载操作将会给客户端及用户带来不必要的下载流量开销。

当然，以上只是一种示例，并非是对本发明及其应用场景的限定，例如，在本发明的一些实施例中，用户的触碰动作及点击事件也可以来自于用户自身所做出的或主动或被动的误操作，比如在一个实施例中，作为客户端的智能手机上可以运行有作为目标应用的一款手机游戏，该游戏在运行时可能会定时生成与某一下载链接对应的弹出页，从而用户在体验游戏的过程中、以较高的频率连续触碰智能手机的触屏时，很可能无法及时地对该弹出页做出反应，导致相对被动地误点到弹出页并产生相应的点击事件，进而导致客户端被动地下载非用户所愿的下载对象。

事实上，在本发明实施例中，并不会对用户的主观意愿进行观测，而是基于对客户端的改进以提供一种对目标应用的监控机制，并在监视到目标应用发出下载请求后对用户进行提示，比如在用户界面上生成一个确认选择对话框，进而可以由用户来确认是否继续下载，这就解决了运行中的目标应用可能会造成客户端下载到非用户所需的下载对象的问题。

以下将结合附图并通过一些具体的实施例对本发明技术方案及其工作原理进行更为详细的描述。

根据本发明实施例提供的处理装置，通过监视单元202，可以监视在客户端上运行的目标应用所发出的请求包，其中，该目标应用可以表示作为监视目标的应用。具体地，在本发明实施例中，上述请求包通常可以是http请求，然而本发明对此不作限定，例如，在本发明的一些实施例中，该请求包也可以是ftp请求，或者是符合其他可行的文本传输格式的请求包等。更具体地，该请求可以表现为一个消息，例如，对于http请求而言，其所对应的消息可以由请求行、消息头和消息体组成。当然，这只是一种实例，本发明对此不作任何限定，例如，对于请求行中所声明的请求装置为GET装置时，上述消息中也可以不存在上述消息体，而是将查询参数设置在同处于请求行中的URL中，等。

在本发明实施例中，针对监视单元202中所述的请求包的监视可以有多种实现方式，例如，作为一种可行的方式，上述装置可以包括：

1）获取单元，用于获取在客户端上运行的系统的管理权限，其中，目标应用运行于系统中，管理权限用于授权以下操作至少之一：对请求包的监视、对请求包的拦截、对请求包的发送。

例如，对于广泛应用在智能手机上的安卓（Android）操作系统而言，为实现对目标应用所发出的请求包的监视，用于实施上述装置的处理装置可以先获取安卓系统的超级用户权限或者说root权限，从而获取对该系统上运行的应用的管理权限，其中，该管理权限可以用于授权以下操作至少之一：对请求包的监视、对请求包的拦截、对请求包的发送，以便于监视单元202所执行的监视操作以及拦截单元206和处理单元208所后续执行对请求包的判断及处理操作。具体地，在本发明实施例中，上述超级用户权限可以通过用户切换（Switch User）文件来获取，然而本发明对此不作限定。

当然，以上只是一种示例，并非本发明唯一的实施方式，例如，在本发明的一些实施例中，对于官方未提供root权限的系统、比如苹果公司所开发的IOS操作系统而言，也可以利用这些系统所开放的功能接口来实现对目标应用所发出的请求包的监视，此外，在本发明的另一些实施例中，监视单元202中所述的对请求包的监视也可以通过现有的抓包软件来实现，本发明对此均不作任何限定。

进一步地，作为一种可选的方式，在本发明实施例中，监视单元202可以包括：

1）第一判断模块，用于判断目标应用是否位于监视列表内，其中，监视列表维护在客户端的本地和/或与客户端连接的服务器上；和/或，用于判断目标应用是否处于活动状态；

2）监视模块，用于在目标应用位于监视列表内和/或目标应用处于活动状态时，监视请求包。

在本发明实施例中，可以选择性地对客户端上运行的全部应用中的一个或多个进行监视，以达到节约系统资源的效果。具体地，作为一种可行的方式，可以建立一个监视列表，该监视列表中可以保存有由客户端及其用户或者是与客户端连接的服务器所预先设置的一个或多个应用，进而处理装置可以将保存在监视列表中的应用作为目标应用进行监视，其中，监视列表中所保存的应用通常可以是在一个时期内用户使用频度较高的一些应用、或者是某一类型的易于植入广告的应用，而其他的一些应用、比如长时间运行在系统后台的应用则可以排除在监视列表之外，从而可以在基本对非用户所需的下载对象的拦截的基础上，进一步地达到节约系统资源的效果。

除此之外，作为另一种可行的方式，在本发明实施例中，还可以判断客户端上运行的任一应用是否处于活动状态，进而处理装置可以对处于活动状态的应用进行监控，并忽略掉处于不活动状态的应用，其中，由于在通常情况下通过用户操作所导致的非用户所需的下载发生在处于活动状态下的应用中，因而通过上述方式同样可以在基本保证对非用户所需的下载对象的拦截的基础上，进一步地达到节约系统资源的目的。具体的，在本发明实施例中，对任一应用是否处于活动状态的判断通常也可以通过对该任一应用的状态的监视来实现，例如，可以在监视到任一应用的状态为“active”时将其判断为活动状态，而“inactive”则可以判断为不活动状态。

当然，上述两种可行的实施方式仅用作示例，而非对本发明的限定，例如，上述两种方式也可以结合起来实施，例如，在前一实施例中所提供的预设的相对静态的监视列表的基础上，还可以进一步地筛选出一个相对动态的监视列表，该动态的监视列表中可以保存有属于上述预设的监视列表的、且处于活动状态下的全部应用，其中，需要说明的是，本发明技术方案还可以与任何现有的或未来的可行的技术手段进行结合，以达到更优的效果，应当理解，此类实施方式仍应视为在本发明的保护范围之内。

在以上描述的基础上，根据本发明实施例提供的处理装置，通过判断单元204，可以判断请求包是否满足拦截条件，其中，该拦截条件至少可以包括：请求包用于使客户端执行对目标文件的下载，换而言之，在本发明实施例中，处理装置可以仅针对目标应用所发出的用于下载目的请求包进行拦截，从而可以在实现对非用户所需的下载对象的拦截的基础上，进一步地达到节约系统资源的效果。其中，上述下载对象通常可以是存储在客户端的外部的某一文件资源，其中，为表述方便，并避免非用户所需的下载对象这一表述可能造成的错误解释，以下将用于下载目的的请求包所指示下载的目标记为目标文件。更具体地，在本发明实施例中，该目标文件的具体表现形式可以有很多种，例如其可以是文本、图像、视频、音频、表格、样式等内容相对单一的文件或者其结合，也可以是如前所述的安装文件等具有特定格式的不同类型的文件，这并不影响本发明技术方案的实施及其技术效果的实现，本发明对此也不作任何限定。

具体地，在本发明实施例中，对请求包是否用于下载目的的判断方式可以有多种，例如，作为一种可选的方式，上述判断单元204可以包括：

1）第三判断模块，用于判断请求包中是否存在用于指示下载操作的下载标识，若存在，则判断出请求包满足拦截条件，若不存在，则判断出请求包不满足拦截条件，其中，一个或多个下载标识维护在客户端的本地和/或与客户端连接的服务器上。

在本发明实施例中，在客户端的本地和/或服务器上可以预先设置有用于标识下载操作的下载标识，其中，该下载标识通常还可以作为一种可识别的字段来指示客户端执行对应的下载操作，例如，在本发明的一些实施例中，上述下载标识可以是html标准字段“download”，从而处理装置在请求包所携带的URL中解析出来这一字段后既可以判断出该请求包用于指示客户端执行下载操作，进而判断出该请求包满足拦截条件，然而本发明对此不作限定。

进一步可选地，在本发明实施例中，在用于判断请求包是否用于下载目的拦截条件外，判断单元204中所述的拦截条件还可以包括更多，例如，作为一种可选的方式，判断单元204还可以包括：

1）第二判断模块，用于判断目标文件是否属于预设类型，若属于，则判断出请求包满足拦截条件，其中，拦截条件还包括：请求包所指示下载的目标文件属于预设类型。

在这一场景下，处理装置可以在判断出请求包用于下载目的的基础上，进一步地判断请求包所指示下载的目标文件是否属于预设类型，并在该目标文件属于预设类型时判断出该请求包满足拦截条件，从而可以进一步地提高处理效率并节约系统资源。例如，在一些实施例中，上述预设类型可以设置为安装文件，或者是图像文件等尺寸较大的文件，等。

进一步地，本发明实施例提供了一种可行的用于判断目标文件所属类型的实施方式，其中，第二判断模块可以包括：

1）判断子模块，用于判断请求包中记录的目标文件的后缀是否属于与预设类型对应的后缀，若是，则判断出请求包满足拦截条件，其中，与预设类型对应的一个或多个后缀维护在客户端的本地和/或与客户端连接的服务器上。

例如，在一个实施例中，可以将拦截条件设置为：1）请求包用于指示客户端执行对目标文件的下载操作；以及2）该目标文件为安装文件，其中，为判断目标文件是否属于安装文件这一预设类型，则可以通过判断子模块来判断该目标文件的后缀是否为“.apk”或“ipa”等，其中，“.apk”为适用于安卓系统的安装文件，“.ipa”为适用于IOS系统的安装文件，然而本发明对此不作限定，与预设类型对应的一个或多个后缀也可以设置为可行的其他后缀名。

在以上描述的基础上，根据本发明实施例提供的处理装置，通过拦截单元206，可以进一步地在判断出满足上述拦截条件后，对满足拦截条件的请求包进行拦截，并生成与该请求包对应的提示信息，以便于使该客户端的用户可以根据提示信息输入指示信息，进而通过处理单元208，可以获取的指示信息的指示处理拦截的请求包。

具体地，在本发明实施例中，对满足拦截条件的请求包进行拦截的具体实施方式通常可以表现为停止对上述请求包的发送，并通过客户端的显示界面提供方便用户确认的提示信息，进而可以在处理单元208接收到用户向客户端输入的指示信息后选择是否继续发送被拦截的该请求包。在上述场景下，由于用户需要对该请求包所指示的下载目标文件的操作进行确认才会继续对请求包的处理，因此可以在一定程度上避免客户端对非用户所需的下载对象的下载，进而解决了运行中的目标应用可能会造成客户端下载到非用户所需的下载对象的问题。

值得注意的是，本发明对于上述拦截操作以及对请求包的后续处理操作并不作限定，例如，在本发明实施例中，上述提示信息通常可以表现为确认选择对话框，一般地，该对话框上可以显示有选项“是”和“否”，其中，“是”可以用于指示客户端继续发送请求包以下载对应的目标文件，“否”可以用于指示客户端不再发送该请求包，然而在本发明的一些实施例中，上述提示信息也可以通过图像信息或者是语音信息提示给用户，对应地，处理装置所获取的指示信息也可以采用语音信息的形式，以进一步地方便用户的使用，本发明对此不作限定。

进一步地，在本发明实施例中，上述提示信息所包含的信息内容除上述用于确认下载与否的下载确认信息之外，还可以包括目标文件的文件名、文件大小、文件的提供者、以及文件的安全认证相关的信息等，以便于用户根据这些信息内容来选择是否下载目标文件或者是相对更为复杂的处理方式。换而言之，在本发明实施例中，为执行上述生成与目标文件对应的提示信息的操作，拦截单元206可以包括：

1）第二生成模块，用于生成与目标文件对应的以下至少之一的提示信息：文件名、大小、提供者、下载确认信息、安全认证信息，其中，提示信息包括以下至少之一：文字信息、图形信息、声音信息。

最后，通过本发明实施例提供一种对请求包进行拦截的具体的实施方式，以及对请求包的更为复杂的处理方式，其中，可选地，为执行上述拦截请求包的操作以及生成与目标文件对应的提示信息的操作，拦截单元206可以包括：

1）添加模块，用于将一个或多个满足拦截条件的请求包添加到待发送列表中；

2）第一生成模块，用于生成与待发送列表中的每一请求包所指示下载的目标文件相对应的提示信息；

其中，处理单元208可以包括以下至少之一：

1）第一处理模块，用于在获取的指示信息用于指示确认下载任一目标文件时，发送与任一目标文件对应的请求包，并将与任一目标文件对应的请求包从待发送列表中清除；

2）第二处理模块，用于在获取的指示信息用于指示暂停下载任一目标文件时，将与任一目标文件对应的请求包继续保存在待发送列表中；

3）第三处理模块，用于在获取的指示信息用于指示拒绝下载目标文件时，将请求包从待发送列表中清除；

4）第四处理模块，用于在获取的指示信息用于指示屏蔽目标文件时，将请求包从待发送列表中清除，并将与目标文件对应的标识项添加到屏蔽列表中，其中，拦截条件还包括：请求包中存在标识项。

通过上述方式，给出了一种基于待发送列表的拦截及后续处理操作的实现方式，其中，通过对该待发送列表的管理，在一方面可以方便地向用户展示提示信息，在另一方面可以方便地响应于用户所反馈的指示信息对相应的请求包进行处理，其中，本领域技术人员应当理解的是，上述实施例中所称的待发送列表可以并不限于是表格的形式。

通过以上实施例，对本发明技术方案及其工作原理进行了描述，然而应当理解的是，上述实施例仅用于对本发明的理解，而不应视为对本发明的限定。值得注意的是，虽然在上述实施例中以智能手机为例对本发明的实施场景进行了描述，然而这并不意味着对本发明构成了限定，例如，在本发明的一些实施例中，上述处理装置也可以实施在计算机，以避免用户在使用计算机、比如通过浏览器对网页进行浏览时由于误操作所造成的对非用户所需的下载对象的下载，其具体的工作原理与上述实施例中所述的类似，本发明在此不作累述。

上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

在本发明的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的客户端或服务器，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

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

另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可为个人计算机、服务器或者网络设备等）执行本发明各个实施例所述方法的全部或部分步骤。而前述的存储介质包括：U盘、只读存储器（ROM，Read-OnlyMemory）、随机存取存储器（RAM，Random Access Memory）、移动硬盘、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (16)

1.一种请求包的处理方法，其特征在于，包括：

监视在客户端上运行的目标应用所发出的请求包；

判断所述请求包是否满足拦截条件，其中，所述拦截条件至少包括：所述请求包用于指示所述客户端执行对目标文件的下载操作；

若满足所述拦截条件，则拦截所述请求包，并生成与所述目标文件对应的提示信息，用于使所述客户端的用户根据所述提示信息输入指示信息；

根据获取的所述指示信息的指示处理拦截的所述请求包。

2.根据权利要求1所述的方法，其特征在于，所述监视在客户端上运行的目标应用所发出的请求包包括：

判断在客户端上运行的任一应用是否保存在预设的监视列表内，其中，所述监视列表维护在所述客户端的本地和/或与所述客户端连接的服务器上；和/或，

判断所述任一应用是否处于活动状态；

若所述任一应用保存在所述监视列表内和/或所述任一应用处于活动状态，则将所述任一应用作为所述目标应用，并监视所述任一应用所发出的请求包。

3.根据权利要求1所述的方法，其特征在于，所述判断所述请求包是否满足拦截条件包括：

判断所述目标文件是否属于预设类型，若属于，则判断出所述请求包满足所述拦截条件，其中，所述拦截条件还包括：所述请求包所指示下载的目标文件属于所述预设类型。

4.根据权利要求3所述的方法，其特征在于，所述判断所述目标文件是否属于预设类型包括：

判断所述请求包中记录的所述目标文件的后缀是否属于与所述预设类型对应的后缀，若是，则判断出所述请求包满足所述拦截条件，其中，与所述预设类型对应的一个或多个后缀维护在所述客户端的本地和/或与所述客户端连接的服务器上。

5.根据权利要求1所述的方法，其特征在于，所述判断所述请求包是否满足拦截条件包括：

判断所述请求包中是否存在用于标识下载操作的下载标识，若存在，则判断出所述请求包满足所述拦截条件，若不存在，则判断出所述请求包不满足所述拦截条件，其中，一个或多个所述下载标识维护在所述客户端的本地和/或与所述客户端连接的服务器上。

6.根据权利要求1至5中任一项所述的方法，其特征在于，

所述拦截所述请求包包括：将一个或多个满足所述拦截条件的请求包添加到待发送列表中；

所述生成与所述目标文件对应的提示信息包括：生成与所述待发送列表中的每一请求包所指示下载的目标文件相对应的提示信息；

其中，所述根据获取的所述指示信息的指示处理拦截的所述请求包包括以下至少之一：

若获取的所述指示信息用于指示确认下载任一目标文件，则发送与所述任一目标文件对应的请求包，并将与所述任一目标文件对应的请求包从所述待发送列表中清除；

若获取的所述指示信息用于指示暂停下载任一目标文件，则将与所述任一目标文件对应的请求包继续保存在所述待发送列表中；

若获取的所述指示信息用于指示拒绝下载所述目标文件，则将所述请求包从所述待发送列表中清除；

若获取的所述指示信息用于指示屏蔽所述目标文件，则将所述请求包从所述待发送列表中清除，并将与所述目标文件对应的标识项添加到屏蔽列表中，其中，所述拦截条件还包括：所述请求包中存在所述标识项。

7.根据权利要求1至5中任一项所述的方法，其特征在于，所述生成与所述目标文件对应的提示信息包括：

生成与所述目标文件对应的以下至少之一的提示信息：文件名、大小、提供者、下载确认信息、安全认证信息，其中，所述提示信息包括以下至少之一：文字信息、图形信息、声音信息。

8.根据权利要求1至5中任一项所述的方法，其特征在于，在所述监视在客户端上运行的目标应用所发出的请求包之前，还包括：

获取在所述客户端上运行的系统的管理权限，其中，所述目标应用运行于所述系统中，所述管理权限用于授权以下操作至少之一：对所述请求包的监视、对所述请求包的拦截、对所述请求包的发送。

9.一种请求包的处理装置，其特征在于，包括：

监视单元，用于监视在客户端上运行的目标应用所发出的请求包；

判断单元，用于判断所述请求包是否满足拦截条件，其中，所述拦截条件至少包括：所述请求包用于指示所述客户端执行对目标文件的下载操作；

拦截单元，用于在满足所述拦截条件时，拦截所述请求包，并生成与所述目标文件对应的提示信息，所述提示信息用于使所述客户端的用户根据所述提示信息输入指示信息；

处理单元，用于根据获取的所述指示信息的指示处理拦截的所述请求包。

10.根据权利要求9所述的装置，其特征在于，所述监视单元包括：

第一判断模块，用于判断所述目标应用是否位于监视列表内，其中，所述监视列表维护在所述客户端的本地和/或与所述客户端连接的服务器上；和/或，用于判断所述目标应用是否处于活动状态；

监视模块，用于在所述目标应用位于所述监视列表内和/或所述目标应用处于活动状态时，监视所述请求包。

11.根据权利要求9所述的装置，其特征在于，所述判断单元包括：

第二判断模块，用于判断所述目标文件是否属于预设类型，若属于，则判断出所述请求包满足所述拦截条件，其中，所述拦截条件还包括：所述请求包所指示下载的目标文件属于所述预设类型。

12.根据权利要求11所述的装置，其特征在于，所述第二判断模块包括：

判断子模块，用于判断所述请求包中记录的所述目标文件的后缀是否属于与所述预设类型对应的后缀，若是，则判断出所述请求包满足所述拦截条件，其中，与所述预设类型对应的一个或多个后缀维护在所述客户端的本地和/或与所述客户端连接的服务器上。

13.根据权利要求9所述的装置，其特征在于，所述判断单元包括：

第三判断模块，用于判断所述请求包中是否存在用于指示下载操作的下载标识，若存在，则判断出所述请求包满足所述拦截条件，若不存在，则判断出所述请求包不满足所述拦截条件，其中，一个或多个所述下载标识维护在所述客户端的本地和/或与所述客户端连接的服务器上。

14.根据权利要求9至13中任一项所述的装置，其特征在于，

所述拦截单元包括：添加模块，用于将一个或多个满足所述拦截条件的请求包添加到待发送列表中；第一生成模块，用于生成与所述待发送列表中的每一请求包所指示下载的目标文件相对应的提示信息；

其中，所述处理单元包括以下至少之一：

第一处理模块，用于在获取的所述指示信息用于指示确认下载任一目标文件时，发送与所述任一目标文件对应的请求包，并将与所述任一目标文件对应的请求包从所述待发送列表中清除；

第二处理模块，用于在获取的所述指示信息用于指示暂停下载任一目标文件时，将与所述任一目标文件对应的请求包继续保存在所述待发送列表中；

第三处理模块，用于在获取的所述指示信息用于指示拒绝下载所述目标文件时，将所述请求包从所述待发送列表中清除；

第四处理模块，用于在获取的所述指示信息用于指示屏蔽所述目标文件时，将所述请求包从所述待发送列表中清除，并将与所述目标文件对应的标识项添加到屏蔽列表中，其中，所述拦截条件还包括：所述请求包中存在所述标识项。

15.根据权利要求9至13中任一项所述的装置，其特征在于，所述拦截单元包括：

第二生成模块，用于生成与所述目标文件对应的以下至少之一的提示信息：文件名、大小、提供者、下载确认信息、安全认证信息，其中，所述提示信息包括以下至少之一：文字信息、图形信息、声音信息。

16.根据权利要求9至13中任一项所述的装置，其特征在于，还包括：

获取单元，用于获取在所述客户端上运行的系统的管理权限，其中，所述目标应用运行于所述系统中，所述管理权限用于授权以下操作至少之一：对所述请求包的监视、对所述请求包的拦截、对所述请求包的发送。