应用程序的认证方法及装置与流程

本申请涉及网络安全领域，具体而言，涉及一种应用程序(application，简称为app)的认证方法及装置。

背景技术：

因业务平台中某些业务需求，需要app间进行通信完成业务数据的交互。在通信交互过程存在app端伪造，可导致与任意app通信、数据被窃取等攻击，这就需要在app间通信时进行身份认证，当app身份符合时才进行后续的数据交互或功能执行。

app间通信有多种方式，如android中通过导出的activity、contentprovider、broadcast、service进行通信。

目前，在基于本地套接字(localsocket)的通信过程中尚无对app进行身份认证的方案，这使得基于localsocket的通信过程的安全受到威胁。

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

技术实现要素：

本申请实施例提供了一种应用程序的认证方法及装置，以至少解决相关技术中尚无在基于localsocket的通信过程中对app进行身份认证的技术方案的技术问题。

根据本申请实施例的一个方面，提供了一种app的认证方法，包括：第一app通过监听第一本地套接字(localsocket)接收来自第二app的请求；所述第一app从所述请求中获取所述第二app的凭证；所述第一app依据所述第二app的凭证获取所述第二app的签名证书，并对所述第二app的签名证书进行验证；在所述第二app的签名证书通过验证时，确定所述第二app通过认证.

根据本申请实施例的又一方面，还提供了一种app的认证装置，所述装置包括：接收模块，用于通过监听本地套接字localsocket接收来自第二app的请求；获取模块，用于从所述请求中获取所述第二app的凭证；认证模块，用于依据所述第二app的凭证获取所述第二app的签名证书，并对所述第二app的签名证书进行验证；以及在所述第二app的签名证书通过验证时，确定所述第二app通过认证。

在本申请实施例中，采用通过监听第一app的本地locasocket接收来自第二app的请求的方式建立了app间的连接，并且，第一app可以从上述请求中获取第二app的凭证，从而依据凭证得到第二app的签名证书，并对该签名证书进行验证，从而实现了对第二app的身份认证。需要说明的是，第二app也可以使用类似的处理过程对第一app进行身份认证。通过上述方案，可以解决相关技术中尚无在基于localsocket的通信过程中对app进行身份认证的技术方案的技术问题。可以实现app间通信过程中对通信双方中的一方或两方进行身份认证，防止恶意软件伪装成app进行通信导致的未授权访问，进而增强了基于locasocket通信过程的安全性。

附图说明

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

图1是根据本申请实施例的一种计算机终端的结构示意图；

图2是根据本申请实施例的一种app的认证方法的流程图；

图3是根据本申请实施例的一种可选的单向认证的流程示意图；

图4是根据本申请实施例的一种可选的双向认证的流程示意图；

图5为根据本申请实施例的一种app的认证装置的结构框图；

图6是根据本申请实施例的另一种计算机终端的结构示意图。

具体实施方式

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

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

首先，在对本申请实施例进行描述的过程中出现的部分名词或术语适用于如下解释：

进程间通讯(inter-processcommunication，简称为ipc)：操作系统进程或线程间进行数据传输的方式。在andorid操作系统中，app双方或多方以某种方式建立ipc通道进行数据交互。这里的某种方式在android系统中可以用activity组件，binderservice等，也可用socket等。

签名证书：又称为数字证书，为互联网通讯中标志通信各方身份信息的一串字符串(可以为一串数字)，在本申请实施例中为用于验证app签名的证书。

凭证(credential)：应用程序的凭证主要记录app进程的pid，uid等，用于标识应用程序的来源(可以通过该来源中的pid、uid等识别应用)。

实施例1

在基于localsocket的app间通信过程中，相关技术中并未涉及对通信双方的认证。针对上述问题，本申请实施例在基于localsocket方式进行app间通信过程中进行身份认证(即通过对目标客体身份标识的读取、解析，然后与自有认证体系的对比识别并判定目标客体身份的过程)，主要有两种认证方案，第一种是单向认证，通信过程中只验证clientapp的身份；第二种是双向认证，通信过程中相互验证对方(clientapp和serverapp)的身份。以下详细说明：

本申请实施例提供了一种app的认证方法的方法实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

本申请实施例1所提供的方法实施例可以在移动终端、计算机终端或者类似的运算装置中执行。图1示出了一种用于实现app的认证方法的计算机终端(或移动设备)的硬件结构框图。如图1所示，计算机终端10(或移动设备10)可以包括一个或多个(图中采用102a、102b，……，102n来示出)处理器102(处理器102可以包括但不限于微处理器mcu或可编程逻辑器件fpga等的处理装置)、用于存储数据的存储器104、以及用于通信功能的传输模块106。除此以外，还可以包括：显示器、输入/输出接口(i/o接口)、通用串行总线(usb)端口(可以作为i/o接口的端口中的一个端口被包括)、网络接口、电源和/或相机。本领域普通技术人员可以理解，图1所示的结构仅为示意，其并不对上述电子装置的结构造成限定。例如，计算机终端10还可包括比图1中所示更多或者更少的组件，或者具有与图1所示不同的配置。

应当注意到的是上述一个或多个处理器102和/或其他数据处理电路在本文中通常可以被称为“数据处理电路”。该数据处理电路可以全部或部分的体现为软件、硬件、固件或其他任意组合。此外，数据处理电路可为单个独立的处理模块，或全部或部分的结合到计算机终端10(或移动设备)中的其他元件中的任意一个内。如本申请实施例中所涉及到的，该数据处理电路作为一种处理器控制(例如与接口连接的可变电阻终端路径的选择)。

存储器104可用于存储应用软件的软件程序以及模块，如本申请实施例中的()方法对应的程序指令/数据存储装置，处理器102通过运行存储在存储器104内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的应用程序的漏洞检测方法。存储器104可包括高速随机存储器，还可包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器104可进一步包括相对于处理器102远程设置的存储器，这些远程存储器可以通过网络连接至计算机终端10。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

传输装置106用于经由一个网络接收或者发送数据。上述的网络具体实例可包括计算机终端10的通信供应商提供的无线网络。在一个实例中，传输装置106包括一个网络适配器(networkinterfacecontroller，nic)，其可通过基站与其他网络设备相连从而可与互联网进行通讯。在一个实例中，传输装置106可以为射频(radiofrequency，rf)模块，其用于通过无线方式与互联网进行通讯。

显示器可以例如触摸屏式的液晶显示器(lcd)，该液晶显示器可使得用户能够与计算机终端10(或移动设备)的用户界面进行交互。

在上述运行环境下，本申请提供了如图2所示的app的认证方法。需要说明的是，本申请实施例中所涉及的第一app和第二app以同时运行于同一计算机终端10(或移动设备10)中。本实施例中，由第二app向第一app申请认证，在其他实施例中，第一app和第二app可以相互认证。

在计算机终端10上启动第一app和第二app后，第一app(在以下实施例中可以称为serverapp，但不限于此)和第二app(在以下实施例中可以称为clientapp，但不限于此)基于localsocket建立连接，然后第二app向第一app提交请求，并利用图2所示流程实现app的认证，具体地，图2是根据本申请实施例1的app的认证方法的流程图。如图2所示，该方法包括：

步骤s202，第一app通过监听localsocket接收来自第二app的请求(该请求可以为访问请求)。可选地，通信由clientapp发起(即发起连接请求)，clientapp通过serverapp提供的localsocket名建立连接，然后提交访问请求，以进行数据传输。

步骤s204，第一app从上述请求中获取上述第二app的凭证(credentials)，这样便可以利用该凭证中的pid和/或uid等信息查找到第二app，进而获取第二app的签名证书。

可选地，步骤s204中，上述第一app可以依据上述凭证中上述第二app的标识信息获取上述第二app的签名证书，其中，上述第二app的标识信息包括以下至少之一：进程标识(pid)、用户标识(uid)。具体地，可以通过以下方式实现：枚举当前运行的进程，并查找与上述pid和/或uid对应的上述第二app；获取上述第二app的包(package)信息，并将上述package信息的签名信息作为上述第二app的签名证书。需要说明的是，此处的签名信息可以是实际的签名，也可以是对签名证书进行哈希运算后得到的哈希值。

步骤s206，第一app依据上述第二app的凭证获取上述第二app的签名证书，并对上述第二app的签名证书进行验证；在上述第二app的签名证书通过验证时，确定上述第二app通过认证。即在通信过程中serverapp(即第一app)验证clientapp(即第二app)的签名证书是否可信，来识别clientapp的身份。

由于每个app都需要签名才能被系统正常安装。签名证书包括两份，一份是私钥证书，是开发者自己拥有，属于隐私信息，需要妥善保管，证书一旦泄漏会导致很多风险，如：app被打包替换，利用同签名app窃取数据等，对安装量很大的app，换证书签名成本也是非常高昂的；另一份是公钥证书，包含在app中，随app一起发布，在安装时验签使用。步骤s206中的签名证书可以为公钥证书，为了实现步骤s206中上述签名证书的验证，需要定义或维护一个公钥证书库(即以下实施例中所提及的第一预设签名证书库或第二预设签名证书库)，该公钥证书库存放可信的公钥证书信息和不可信的公钥证书信息。app间利用localsocket通信时，系统会将serverapp端的credentials发给对方，其中credentials中包含app的pid、uid等信息，根据pid、uid获取对方app的签名证书信息，与公钥证书库对比对，如果是可信证书，则表示身份合法，否则认证失败。

可选地，在对上述签名证书进行验证时，除了使用公钥证书库进行比对验证之外，还可以采用对签名证书的md5值等信息进行验证的验证方式。

由此可见，可以通过将上述签名证书与白名单中的签名证书进行比对实现对上述签名证书的验证，即第一app判断第一预设签名证书库中是否存在上述第二app的签名证书；其中，如果存在则确定上述第二app的签名证书通过验证，如果不存在，则确定上述第二app的签名证书未通过验证。需要说明的是，此处在验证第二app的签名证书时，可以直接比对app的签名证书和第一预设签名证书库中的证书，也可以比对两者的md5值，但并不限于此。

以上主要介绍了关于单向认证的实现过程，即对通信双方中的其中一方进行身份认证，为便于理解，以下结合图3所示实施例详细说明单向认证的过程，在执行图3所示流程之前，需要首先定义可信任的clientapp签名证书列表，记为clientappsignwhitelist，以对clientapp的签名证书进行验证。如图3所示，该过程包括：

步骤s302，serverapp监听一个本地socket，等待clientapp连接。具体地，在serverapp中采用newlocalserversocket()函数监听serverapp中的localsocket的名称；

步骤s304，clientapp建立与serverapp的连接；

步骤s306，接收请求，并获取clientapp的credentials：

将localsocket对象绑定到读写流中，用于接收和发送消息：

步骤s308，serverapp接收到客户端的请求，获取凭证中的pid、uid，再根据pid和/或uid获取客户端的签名证书；判断该签名证书是否在serverapp保存的白名单中。verifysignatures()方法为签名证书验证的方法，如果返回true表示验证成功，然后可以继续执行相关代码或功能；如果返回false，则不作其它操作直接返回。

其中，签名证书验证方法verifysignatures()，包括以下处理过程：

枚举系统当前正运行的进程，找到与clientpid和clientuid的app，记为clientapp。然后获取其package信息：

比较package的签名信息与白名单是否匹配，如果匹配则返回true，匹配不到则返回false(即验证失败)；

步骤s310，如果客户端证书在服务端白名单中，则继续与客户端通信，否则断开连接。即绑定输入输出流，与serverapp进行通信。

以上描述了单向认证的过程，但是，单向认证只能是server端识别client端是否可信，而client端不能识别server端是否可信。相关技术中存在这样一种攻击：攻击者可以伪造一个server与client进行通信，可以实施server端钓鱼攻击，如果通信中有敏感信息传输也可导致信息被窃取。为解决上述问题，本申请实施例在单向认证的基础上增加了clientapp对serverapp的认证。

即：上述第二app接收上述第一app依据上述请求反馈的响应；上述第二app从上述响应中获取上述第一app的凭证；上述第二app依据上述第一app的凭证获取上述第一app的签名证书，并对上述第一app的签名证书进行验证；在上述第一app的签名证书通过验证时，确定上述第一app通过认证。

可选地，对上述第一app的签名证书进行验证可以通过以下方式实现：上述第二app判断第二预设签名证书库中是否存在上述第一app的签名证书；其中，如果存在则确定上述第一app的签名证书通过验证，如果不存在，则确定上述第一app的签名证书未通过验证。需要说明的是，此处在验证第一app的签名证书时，可以直接比对app的签名证书和第二预设签名证书库中的证书，也可以比对两者的md5值，但并不限于此。

需要说明的是，上述第一预设签名证书库和第二预设签名证书库可以是同一签名证书库，也可以是不同的签名证书库，对于后者，例如可以依据不同的app维护符合个人特色的签名证书库。

可选地，上述第二app依据上述第一app的凭证获取上述第一app的签名证书，包括：上述第二app依据上述凭证中上述第二app的标识信息获取上述第一app的签名证书，其中，上述第一app的标识信息包括以下至少之一：进程标识pid、用户标识uid。

为了更好地理解上述双向认证的过程，以下结合图4所示实施例详细说明，和单向认证的过程类似，在进行具体验证之前，同一需要定义可信任的serverapp签名证书列表，记为serverappsignwhitelist：

如图4所示，server端的实现与单向认证中的相同，在客户端建链时增加身份校验。

步骤s402，serverapp监听一个本地socket，等待clientapp连接。

步骤s404，clientapp建立与serverapp的连接；

步骤s406，客户端app从服务端app返回的凭证中获取其pid、uid，根据此pid、uid获取服务端的签名证书；然后判断该签名证书是否在客户端保存的白名单中；即verifyserviceapp’ssignatures()；

步骤s408，如果不在客户端的白名单中则断开连接，如果在客户端的白名单中则继续通信,向server发送请求(request)，即ifverify()＝＝true:request()。

步骤s410，服务端接收到客户端的请求，获取凭证中的pid、uid，再获取clientapp的签名证书；判断该签名证书是否在serverapp保存的白名单中；

步骤s412，如果客户端证书在服务端白名单中，则继续与客户端通信，否则断开连接。verifysignatures()方法为签名证书验证的方法，如果返回true表示验证成功，然后可以继续执行相关代码或功能；如果返回false，则断开连接并退出。

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

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

实施例2

根据本申请实施例，还提供了一种用于实施上述app的认证方法的装置，如图5所示，该装置包括：

接收模块50，用于通过监听本地套接字localsocket接收来自第二app的请求；

获取模块52，用于从所述请求中获取所述第二app的凭证；

认证模块54，用于依据所述第二app的凭证获取所述第二app的签名证书，并对所述第二app的签名证书进行验证；以及在所述第二app的签名证书通过验证时，确定所述第二app通过认证。

可选地，为了实现通信双方的双向认证，上述接收模块50，还用于接收上述第一app依据上述请求反馈的响应；上述获取模块52，还用于从上述响应中获取上述第一app的凭证；上述认证模块54，还用于依据上述第一app的凭证获取上述第一app的签名证书，并对上述第一app的签名证书进行验证；以及在上述第一app的签名证书通过验证时，确定上述第一app通过认证。

需要说明的是，上述各个模块可以通过软件或硬件的形式实现，对于后者，可以表现为以下实现形式，但不限于此：上述各个处理模块位于同一处理器中，上述各个模块位于不同的处理器中。

需要说明的是，本实施例中的优选实施方式可以参见实施例1中的描述，此处不再赘述。

实施例3

本申请的实施例可以提供一种计算机终端，该计算机终端可以是计算机终端群中的任意一个计算机终端设备。可选地，在本实施例中，上述计算机终端也可以替换为移动终端等终端设备。

可选地，在本实施例中，上述计算机终端可以位于计算机网络的多个网络设备中的至少一个网络设备。

在本实施例中，上述计算机终端可以执行应用程序的app的认证方法中以下步骤的程序代码：第一app通过监听本地套接字localsocket接收来自第二app的请求；所述第一app从所述请求中获取所述第二app的凭证；所述第一app依据所述第二app的凭证获取所述第二app的签名证书，并对所述第二app的签名证书进行验证；在所述第二app的签名证书通过验证时，确定所述第二app通过认证。

可选地，图6是根据本申请实施例的一种计算机终端的结构框图。如图6所示，该计算机终端a可以包括：一个或多个(图中仅示出一个)处理器60、存储器62。

其中，存储器可用于存储软件程序以及模块，如本申请实施例中的安全漏洞检测方法和装置对应的程序指令/模块，处理器通过运行存储在存储器内的软件程序以及模块，从而执行各种功能应用以及数据处理，即实现上述的系统漏洞攻击的检测方法。存储器可包括高速随机存储器，还可以包括非易失性存储器，如一个或者多个磁性存储装置、闪存、或者其他非易失性固态存储器。在一些实例中，存储器可进一步包括相对于处理器远程设置的存储器，这些远程存储器可以通过网络连接至终端a。上述网络的实例包括但不限于互联网、企业内部网、局域网、移动通信网及其组合。

处理器可以通过传输装置调用存储器存储的信息及应用程序，以执行下述步骤：第一app通过监听本地套接字localsocket接收来自第二app的请求；所述第一app从所述请求中获取所述第二app的凭证；所述第一app依据所述第二app的凭证获取所述第二app的签名证书，并对所述第二app的签名证书进行验证；在所述第二app的签名证书通过验证时，确定所述第二app通过认证。

可选的，上述处理器还可以执行如下步骤的程序代码：所述第一app判断第一预设签名证书库中是否存在所述第二app的签名证书；其中，如果存在则确定所述第二app的签名证书通过验证，如果不存在，则确定所述第二app的签名证书未通过验证。

可选的，上述处理器还可以执行如下步骤的程序代码：所述第一app依据所述凭证中所述第二app的标识信息获取所述第二app的签名证书，其中，所述第二app的标识信息包括以下至少之一：进程标识pid、用户标识uid。

可选的，上述处理器还可以执行如下步骤的程序代码：枚举当前运行的进程，并查找与所述pid和/或uid对应的所述第二app；获取所述第二app的包package信息，并将所述package信息的签名信息作为所述第二app的签名证书。

可选的，上述处理器还可以执行如下步骤的程序代码：所述第二app接收所述第一app依据所述请求反馈的响应；所述第二app从所述响应中获取所述第一app的凭证；所述第二app依据所述第一app的凭证获取所述第一app的签名证书，并对所述第一app的签名证书进行验证；在所述第一app的签名证书通过验证时，确定所述第一app通过认证。

采用本申请实施例，提供了一种app的认证方案，解决了相关技术中尚无在基于localsocket的通信过程中对app进行身份认证的技术方案的技术问题。

本领域普通技术人员可以理解，图6所示的结构仅为示意，计算机终端也可以是智能手机(如android手机、ios手机等)、平板电脑、掌声电脑以及移动互联网设备(mobileinternetdevices，mid)、pad等终端设备。图6其并不对上述电子装置的结构造成限定。例如，计算机终端a还可包括比图6中所示更多或者更少的组件(如网络接口、显示装置等)，或者具有与图6所示不同的配置。

本领域普通技术人员可以理解上述实施例的各种方法中的全部或部分步骤是可以通过程序来指令终端设备相关的硬件来完成，该程序可以存储于一计算机可读存储介质中，存储介质可以包括：闪存盘、只读存储器(read-onlymemory，rom)、随机存取器(randomaccessmemory，ram)、磁盘或光盘等。

实施例4

本申请的实施例还提供了一种存储介质。可选地，在本实施例中，上述存储介质可以用于保存上述实施例1所提供的app的认证方法所执行的程序代码。

可选地，在本实施例中，上述存储介质可以位于计算机网络中计算机终端群中的任意一个计算机终端中，或者位于移动终端群中的任意一个移动终端中。

可选地，在本实施例中，存储介质被设置为存储用于执行以下步骤的程序代码：第一app通过监听本地套接字localsocket接收来自第二app的请求；所述第一app从所述请求中获取所述第二app的凭证；所述第一app依据所述第二app的凭证获取所述第二app的签名证书，并对所述第二app的签名证书进行验证；在所述第二app的签名证书通过验证时，确定所述第二app通过认证。

可选地，在本实施例中，存储介质被设置为存储用于执行以下步骤的程序代码：所述第二app接收所述第一app依据所述请求反馈的响应；所述第二app从所述响应中获取所述第一app的凭证；所述第二app依据所述第一app的凭证获取所述第一app的签名证书，并对所述第一app的签名证书进行验证；在所述第一app的签名证书通过验证时，确定所述第一app通过认证。

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

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

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

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

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

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

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