一种数据包传输方法和系统

摘要

本发明公开了一种数据包传输方法，所述方法包括：代理程序通过监听端口接收请求数据包，为所述请求数据包设置标签后，发送所述带标签的请求数据包；本地系统接收所述代理程序和所述应用程序发出的请求数据包，匹配所述请求数据包中的标签，若匹配成功，则直接转发所述请求数据包，若匹配失败，则重定向所述请求数据包至所述代理程序监听端口；对代理程序发送出去的数据包进行标签设置，以使得本地系统可根据标签区分来自应用和代理的请求数据包，并进行相应操作，避免数据包在本地的死循环。本发明还公开了一种数据包传输系统。

权利要求

1.一种数据包传输方法，其特征在于，所述方法包括：

代理程序通过监听端口接收请求数据包，为所述请求数据包设置标签后，发送带标签的请求数据包；所述代理程序在为所述请求数据包设置标签的同时，为所述标签添加掩码；

所述掩码的取值范围为0x8000000～0xfff00000；

本地系统接收所述代理程序和应用程序发出的请求数据包，匹配所述请求数据包中的标签，若匹配成功，则直接转发所述请求数据包，若匹配失败，则重定向所述请求数据包至所述代理程序监听端口。

2.根据权利要求1所述的数据包传输方法，其特征在于，所述本地系统版本为Android 

5.0及其以上版本。

3.根据权利要求1所述的数据包传输方法，其特征在于，在所述代理程序发送所述带标签的请求数据包之前，所述代理程序判断所述请求数据包是否需要进行加速，若需要则修改所述请求数据包的目的端口和目的IP地址至加速服务器。

4.根据权利要求3所述的数据包传输方法，其特征在于，判断所述请求数据包是否需要进行加速的方法包含：先白名单校验，若校验成功则判断所述请求数据包需要加速；若校验失败，则判断所述请求数据包是否为HTTP请求的数据包，如果是，则根据URL及预设规则判断是否需要加速。

5.根据权利要求1所述的数据包传输方法，其特征在于，所述代理程序和所述应用程序运行在所述本地系统上。

6.根据权利要求1所述的数据包传输方法，其特征在于，所述本地系统内核为Linux内核。

7.一种数据包传输系统，其特征在于，所述系统包括终端设备、加速服务器和源站，所述终端设备的本地系统上运行有应用程序、代理程序；其中，所述代理程序通过监听端口接收请求数据包，为所述请求数据包设置标签后，发送带标签的请求数据包，所述代理程序在为所述请求数据包设置标签的同时，为所述标签添加掩码，所述掩码的取值范围为

0x8000000～0xfff00000；本地系统接收所述代理程序和所述应用程序发出的请求数据包，匹配所述请求数据包中的标签，若匹配成功，则直接转发所述请求数据包至所述加速服务器或所述源站，若匹配失败，则重定向所述请求数据包至所述代理程序监听端口。

8.根据权利要求7所述的数据包传输系统，其特征在于，所述本地系统版本为Android 

5.0及其以上版本。

9.根据权利要求7所述的数据包传输系统，其特征在于，所述代理程序包含加速处理单元，在所述代理程序发送所述带标签的请求数据包之前，所述代理程序的加速处理单元判断所述请求数据包是否需要进行加速，若需要则修改所述请求数据包的目的端口和目的IP地址至加速服务器。

10.根据权利要求9所述的数据包传输系统，其特征在于，所述代理程序的加速处理单元判断所述请求数据包是否需要进行加速的方法包含：先白名单校验，若校验成功则所述请求数据包需要加速；若校验失败，则判断所述请求数据包是否为HTTP请求的数据包，如果是，则根据URL及预设规则判断是否需要加速。

11.根据权利要求7所述的数据包传输系统，其特征在于，所述本地系统内核为Linux内核。

说明书

一种数据包传输方法和系统

技术领域

[0001] 本发明涉及网络技术领域，尤其涉及一种数据包传输方法和系统。

背景技术

[0002] 随着互联网技术的不断发展，各种应用程序如雨后春笋般密集涌现。为了提供更好的用户体验，针对应用程序的网络加速服务也应运而生，以Android应用代理加速为例，可以分为主动代理和被动代理两种方式，主动代理是应用程序在发起网络请求时主动进行代理加速，被动代理，又称本地代理，是在系统层面通过某些手段将特定的请求数据包拦截至本地的加速服务程序，由本地代理程序做相应的加速控制后再将数据包重新发出去。

[0003] 现有的被动代理中，主要是通过添加重定向规则，将应用数据包重定向到代理程序来实现，但在某些实际应用中，发现仅仅依靠重定向规则可能无法区分待加速应用与经代理程序处理后发出的数据包，代理程序发出的数据包将会再次被重定向至代理程序，造成数据包在系统内死循环。

发明内容

[0004] 为了解决现有技术的问题，本发明实施例提供了一种数据包传输方法和系统。所述技术方案如下：

[0005] 一方面，一种数据包传输方法，所述方法包括：

[0006] 代理程序通过监听端口接收请求数据包，为所述请求数据包设置标签后，发送所述带标签的请求数据包；

[0007] 本地系统接收所述代理程序和所述应用程序发出的请求数据包，匹配所述请求数据包中的标签，若匹配成功，则直接转发所述请求数据包，若匹配失败，则重定向所述请求数据包至所述代理程序监听端口。

[0008] 进一步的，所述代理程序在为所述请求数据包设置标签的同时，为所述标签添加掩码。

[0009] 进一步的，所述掩码的取值范围为0x8000000～0xfff00000。

[0010] 进一步的，所述本地系统版本为Android 5.0及其以上版本。

[0011] 进一步的，在所述代理程序发送所述带标签的请求数据包之前，所述代理程序判断所述请求数据包是否需要进行加速，若需要则修改所述请求数据包的目的端口和目的IP地址至加速服务器。

[0012] 进一步的，判断所述请求数据包是否需要进行加速的方法包含：先白名单校验，若校验成功则所述请求数据包需要加速；若校验失败，则判断所述请求数据包是否为HTTP请求的数据包，如果是HTTP，则根据URL及预设规则判断是否需要加速。

[0013] 进一步的，所述代理程序和所述应用程序运行在所述本地系统上。

[0014] 进一步的，所述本地系统内核为Linux内核。

[0015] 另一方面，一种数据包传输系统，所述系统包括终端设备、加速服务器和源站，所述终端设备的本地系统上运行有应用程序、代理程序；其中，所述代理程序通过监听端口接收请求数据包，为所述请求数据包设置标签后，发送所述带标签的请求数据包；本地系统接收所述代理程序和所述应用程序发出的请求数据包，匹配所述请求数据包中的标签，若匹配成功，则直接转发所述请求数据包至所述加速服务器或所述源站，若匹配失败，则重定向所述请求数据包至所述代理程序监听端口。

[0016] 进一步的，所述代理程序在为所述请求数据包设置标签的同时，为所述标签添加掩码。

[0017] 进一步的，所述掩码的取值范围为0x8000000～0xfff00000。

[0018] 进一步的，所述本地系统版本为Android 5.0及其以上版本。

[0019] 进一步的，在所述代理程序包含加速处理单元，在所述代理程序发送所述带标签的请求数据包之前，所述代理程序的加速处理单元，判断所述请求数据包是否需要进行加速，若需要则修改所述请求数据包的目的端口和目的IP地址至加速服务器。

[0020] 进一步的，所述代理程序的加速处理单元判断所述请求数据包是否需要进行加速的方法包含：先白名单校验，若校验成功则所述请求数据包需要加速；若校验失败，则判断所述请求数据包是否为HTTP请求的数据包，如果是HTTP，则根据URL及预设规则判断是否需要加速。

[0021] 进一步的，所述本地系统内核为Linux内核。

[0022] 本发明实施例提供的技术方案带来的有益效果是：本发明实施例的数据包传输方法，代理程序通过监听端口接收请求数据包，为所述请求数据包设置标签后，发送所述带标签的请求数据包；本地系统接收所述代理程序和所述应用程序发出的请求数据包，匹配所述请求数据包中的标签，若匹配成功，则直接转发所述请求数据包，若匹配失败，则重定向所述请求数据包至所述代理程序监听端口；对代理程序发送出去的数据包进行标签设置，以使得本地系统可根据标签区分来自应用和代理的请求数据包，并进行相应操作，避免数据包在本地的死循环。

附图说明

[0023] 为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

[0024] 图1是本发明实施例一提供的一种数据包传输方法的流程图；

[0025] 图2是本发明实施例二提供的一种数据包传输方法的流程图；

[0026] 图3是本发明实施例三提供的一种数据包传输系统结构图。

具体实施方式

[0027] 为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明实施方式作进一步地详细描述。

[0028] 第一实施例

[0029] 参见图1所示，本发明第一实施例提供一种数据包传输方法，该数据包传输方法中涉及代理程序、应用程序及本地系统，其中应用程序是为用户提供具体业务服务的程序，例如浏览器、音乐视频服务、及其他功能性服务程序，用户通过对该些应用程序的操作来获取相应的服务；代理程序对应用程序发出的请求数据包进行处理，以使得享受网络加速服务的应用程序所发出的请求数据包能被转发到加速服务器；应用程序及代理程序均运行在本地系统上，本发明的实施例中，本地系统的内核为Linux内核，可以是Android系统，本实施例就是以Android系统为例。

[0030] 本实施例中的数据包传输方法包括步骤A101～A103和步骤S101～S102，详述如下。

[0031] 步骤A101：代理程序通过监听端口接收请求数据包。如上所述，代理程序需要对应用程序发出的请求数据包进行处理，故在代理程序初始化时，设置专门的监听端口，用于接收应用程序的请求数据包，例如，代理程序的监听端口设置为8123。

[0032] 步骤A102：代理程序为所述请求数据包设置标签。具体的，代理程序接收到请求数据包后通过创建代理socket，并使用Linux的setsockopt()函数对socket设置标签，例如mark＝0x12345678。

[0033] 步骤A103：代理程序发送带标签的请求数据包。代理程序发送出的带标签的请求数据包将被本地系统接收。

[0034] 步骤S101：本地系统接收所述代理程序和所述应用程序发出的请求数据包。本发明的实施例中，本地系统为Android系统，而Android系统的内核为Linux内核，众所周知，Netfilter是Linux内核中的一个软件框架，用于管理网络数据包。iptables是基于Netfilter基本架构实现的一个可扩展的的用户层数据包管理工具，大部分Linux系统都自带iptables模块，并通过它对网络数据包进行过滤、拦截、重定向等操作，从而实现系统防火墙等功能，本发明的实施例中，也是通过iptables对代理程序和应用程序发出的请求数据包进行接收。

[0035] 步骤S102：匹配所述请求数据包中的标签，若匹配成功，则直接转发所述请求数据包，若匹配失败，则重定向所述请求数据包至所述代理程序监听端口。同样的，本地系统通过设置iptables mark标签匹配规则和重定向规则，对数据包中的标签进行匹配，若匹配成功，根据设置规则则直接转发该请求数据包，若匹配失败，则重定向该请求数据包至代理程序监听端口。例如，设置iptables mark标签匹配规则、重定向规则如下：

[0036] iptables-t nat-A OUTPUT-m mark--mark 0x12345678-j RETURN[0037] iptables-t nat-A OUTPUT-p tcp-j REDIRECT--to-port 8123

[0038] 第一条规则的作用是当数据包具有mark＝0x12345678的标签时，数据包不被重定向，以系统默认方式处理，否则执行第二条规则；第二条规则的作用是将数据包重定向至代理程序的监听端口8123端口。

[0039] 如此一来，代理程序所发出的请求数据包均包含Mark标签，本地系统可通过Mark标签匹配来区分应用程序和代理程序，并进行分别处理，从而避免了背景技术中描述的死循环现象。

[0040] 可以理解的是，虽然本实施例的图示中，步骤A103和S101之间是先后关系，但在实际应用中，步骤A101～A103为代理程序内部的执行步骤，而步骤S101～S102为本地系统内部执行的步骤，各步骤之间先后关系并非全部如此明确，故图示仅用于对本实施例进行示意说明，本发明并不以此为限。

[0041] 更进一步的，本实施例中的数据包传输方法更包含步骤：代理程序判断请求数据包是否需要进行加速，若需要则修改所述请求数据包的目的端口和目的IP地址至加速服务器。如此一来，当本地系统接收到需要加速的请求数据包时，根据重定向规则，将会按照该请求数据包的目的端口和目的IP地址转发该请求数据包至加速服务器，加速服务器为其提供相应的网络加速服务。该步骤设置在步骤A103之前。

[0042] 具体而言，由于本地系统上可能安装了多种应用程序，然而有些应用程序并没有购买相应的加速服务，故代理程序应对需要加速的应用程序进行判断，具体的判断方法包含：先白名单校验，若校验成功则判断所述请求数据包需要加速，其中所述白名单中保存了需要加速的应用程序包名信息；若校验失败，则判断所述请求数据包是否为HTTP请求的数据包，如果是HTTP，则根据URL及预设规则判断是否需要加速。

[0043] 如此一来，可实现对应用程序的分类处理，只对需要加速的应用程序进行处理。

[0044] 第二实施例

[0045] 参见图2所示，本发明第二实施例提供一种数据包传输方法，该数据包传输方法中涉及代理程序、应用程序及本地系统，其中应用程序是为用户提供具体业务服务的程序，例如浏览器、音乐视频服务、及其他功能性服务程序，用户通过对该些应用程序的操作来获取相应的服务；代理程序对应用程序发出的请求数据包进行处理，以使得享受网络加速服务的应用程序所发出的请求数据包能被转发到加速服务器；应用程序及代理程序均运行在本地系统上，本发明的实施例中，本地系统的内核为Linux内核，可以是Android系统，本实施例就是以Android系统为例。

[0046] 本实施例中的数据包传输方法包括步骤A201～A203和步骤S201～S202，详述如下。

[0047] 步骤A201：代理程序通过监听端口接收请求数据包。如上所述，代理程序需要对应用程序发出的请求数据包进行处理，故在代理程序初始化时，设置专门的监听端口，用于接收应用程序的请求数据包，例如，代理程序的监听端口设置为8123。

[0048] 步骤A202：代理程序为所述请求数据包设置标签，并为所述标签添加掩码。具体的，代理程序接收到请求数据包后通过创建代理socket，并使用Linux的setsockopt()函数对socket设置标签，并为该标签添加掩码，例如mark＝0x12345678/0xfff00000。

[0049] 步骤A203：代理程序发送带掩码标签的请求数据包。代理程序发送出的带标签的请求数据包将被本地系统接收。

[0050] 步骤S201：本地系统接收所述代理程序和所述应用程序发出的请求数据包。本发明的实施例中，本地系统为Android系统，而Android系统的内核为Linux内核，众所周知，Netfilter是Linux内核中的一个软件框架，用于管理网络数据包。iptables是基于Netfilter基本架构实现的一个可扩展的的用户层数据包管理工具，大部分Linux系统都自带iptables模块，并通过它对网络数据包进行过滤、拦截、重定向等操作，从而实现系统防火墙等功能，本发明的实施例中，也是通过iptables对代理程序和应用程序发出的请求数据包进行接收。

[0051] 步骤S202：匹配所述请求数据包中的掩码标签，若匹配成功，则直接转发所述请求数据包，若匹配失败，则重定向所述请求数据包至所述代理程序监听端口。同样的，本地系统通过设置iptables掩码标签匹配规则和重定向规则，对数据包中的掩码标签进行匹配，若匹配成功，根据设置规则则直接转发该请求数据包，若匹配失败，则重定向该请求数据包至代理程序监听端口。例如，设置iptables掩码标签匹配规则、重定向规则如下：

[0052] iptables-t nat-A OUTPUT-m mark--mark 0x12345678/0xfff00000-j RETURN[0053] iptables-t nat-A OUTPUT-p tcp-j REDIRECT--to-port 8123

[0054] 第一条规则的作用是当数据包具有mark＝0x12345678/0xfff00000的掩码标签时，数据包不被重定向，以系统默认方式处理，否则执行第二条规则；第二条规则的作用是将数据包重定向至代理程序的监听端口8123端口。

[0055] 如此一来，代理程序所发出的请求数据包均包含Mark标签，本地系统可通过Mark标签匹配来区分应用程序和代理程序，并进行分别处理，从而避免了背景技术中描述的死循环现象。

[0056] 不仅如此，由于请求数据包中的标签均带有掩码，可避免请求数据包在传输过程中，标签被修改后无法正确匹配的问题，具体而言，在Android 5.0及其以上版本的系统中，系统中的Netd会对数据包中的标签进行篡改，若标签中没有增加掩码，则无法正确进行匹配，经仔细研究发现，Netd对于一个32bits的标签的篡改，仅会影响其低20bits，故本实施例中，为标签打上掩码，并同时修改匹配规则，对未被篡改的部分进行匹配，从而避免了标签被篡改后无法正确匹配的问题，相应的，在Android 5.0及其以上版本的系统中，掩码的取值范围为0x8000000～0xfff00000。可以理解的是，在一些其他版本的系统下，若符合相应规则，也可以根据本实施例的处理思路进行处理，本发明并不以此为限。

[0057] 可以理解的是，虽然本实施例的图示中，步骤A203和S201之间是先后关系，但在实际应用中，步骤A201～A203为代理程序内部的执行步骤，而步骤S201～S202为本地系统内部执行的步骤，各步骤之间先后关系并非全部如此明确，故图示仅用于对本实施例进行示意说明，本发明并不以此为限。

[0058] 更进一步的，本实施例中的数据包传输方法更包含步骤：代理程序判断请求数据包是否需要进行加速，若需要则修改所述请求数据包的目的端口和目的IP地址至加速服务器。如此一来，当本地系统接收到需要加速的请求数据包时，根据重定向规则，将会按照该请求数据包的目的端口和目的IP地址转发该请求数据包至加速服务器，加速服务器为其提供相应的网络加速服务。该步骤设置在步骤A203之前。

[0059] 具体而言，由于本地系统上可能安装了多种应用程序，然而有些应用程序并没有购买相应的加速服务，故代理程序应对需要加速的应用程序进行判断，具体的判断方法包含：先白名单校验，若校验成功则判断所述请求数据包需要加速，其中所述白名单中保存了需要加速的应用程序包名信息；若校验失败，则判断所述请求数据包是否为HTTP请求的数据包，如果是HTTP，则根据URL及预设规则判断是否需要加速。

[0060] 如此一来，可实现对应用程序的分类处理，只对需要加速的应用程序进行处理。

[0061] 第三实施例

[0062] 参见图3所示，本发明第三实施例提供一种数据包传输系统，所述数据包传输系统包括终端设备、加速服务器和源站，所述终端设备的本地系统上运行有应用程序、代理程序。

[0063] 具体而言，应用程序是为用户提供具体业务服务的程序，例如浏览器、音乐视频服务、及其他功能性服务程序，用户通过对该些应用程序的操作来获取相应的服务。应用程序接收用户操作，并发出相应的请求数据包，该请求数据包将经过代理程序和本地系统，最终发送至加速服务器或者源站进行回源，以响应用户请求。

[0064] 代理程序对应用程序发出的请求数据包进行处理，以使得享受网络加速服务的应用程序所发出的请求数据包能被转发到加速服务器。代理程序通过监听端口接收请求数据包，为请求数据包设置标签后，发送所述带标签的请求数据包。

[0065] 详细而言，代理程序初始化时，设置专门的监听端口，用于接收应用程序的请求数据包，例如，代理程序的监听端口设置为8123。在接收到请求数据包后，通过创建代理socket，并使用Linux的setsockopt()函数对socket设置标签，例如mark＝0x12345678。代理程序发送出的带标签的请求数据包将被本地系统接收。

[0066] 值得注意的是，在本发明的一些其他较佳实施例中，代理程序为请求数据包添加的标签为带有掩码的标签，例如mark＝0x12345678/0xfff00000，不仅可以实现标签同样的功能，还能防止在一些版本的系统中，标签被篡改的而无法正确匹配的问题。

[0067] 例如在Android 5.0及其以上版本的系统中，系统中的Netd会对数据包中的标签进行篡改，若标签中没有增加掩码，则无法正确进行匹配，经仔细研究发现，Netd对于一个32bits的标签的篡改，仅会影响其低20bits，故本实施例中，为标签打上掩码，并同时修改匹配规则，对未被篡改的部分进行匹配，从而避免了标签被篡改后无法正确匹配的问题，相应的，在Android 5.0及其以上版本的系统中，掩码的取值范围为0x8000000～0xfff00000。
可以理解的是，在一些其他版本的系统下，若符合相应规则，也可以根据本实施例的处理思路进行处理，本发明并不以此为限。

[0068] 代理程序在发送带标签的请求数据包之前，还需判断请求数据包是否需要进行加速，若需要则修改所述请求数据包的目的端口和目的IP地址至加速服务器。如此一来，当本地系统接收到需要加速的请求数据包时，根据重定向规则，将会按照该请求数据包的目的端口和目的IP地址转发该请求数据包至加速服务器，加速服务器为其提供相应的网络加速服务。而不需要加速的请求数据包将根据原始端口及IP地址被本地系统转发至源站。

[0069] 具体而言，由于本地系统上可能安装了多种应用程序，然而有些应用程序并没有购买相应的加速服务，故代理程序应对需要加速的应用程序进行判断，具体的判断方法包含：先白名单校验，若校验成功则判断所述请求数据包需要加速，其中所述白名单中保存了需要加速的应用程序包名信息；若校验失败，则判断所述请求数据包是否为HTTP请求的数据包，如果是HTTP，则根据URL及预设规则判断是否需要加速。

[0070] 如此一来，可实现对应用程序的分类处理，只对需要加速的应用程序进行处理。

[0071] 本地系统接收所述代理程序和所述应用程序发出的请求数据包，匹配所述请求数据包中的标签，若匹配成功，则直接转发所述请求数据包至所述加速服务器或所述源站，若匹配失败，则重定向所述请求数据包至所述代理程序监听端口。

[0072] 本发明的实施例中，本地系统为Android系统，而Android系统的内核为Linux内核，众所周知，Netfilter是Linux内核中的一个软件框架，用于管理网络数据包。iptables是基于Netfilter基本架构实现的一个可扩展的的用户层数据包管理工具，大部分Linux系统都自带iptables模块，并通过它对网络数据包进行过滤、拦截、重定向等操作，从而实现系统防火墙等功能，本发明的实施例中，也是通过iptables对代理程序和应用程序发出的请求数据包进行接收。

[0073] 同样的，本地系统通过设置iptables标签匹配规则和重定向规则，对数据包中的标签进行匹配，若匹配成功，根据设置规则则直接转发该请求数据包，若匹配失败，则重定向该请求数据包至代理程序监听端口，可以理解的是，在本发明的实施例中，本地系统在设置iptables标签匹配规则时所设置的标签与代理程序为请求数据包设置的标签相同。以带有掩码的标签为例，设置iptables标签匹配规则、重定向规则如下：

[0074] iptables-t nat-A OUTPUT-m mark--mark 0x12345678/0xfff00000-j RETURN[0075] iptables-t nat-A OUTPUT-p tcp-j REDIRECT--to-port 8123

[0076] 第一条规则的作用是当数据包具有mark＝0x12345678/0xfff00000的掩码标签时，数据包不被重定向，以系统默认方式处理，否则执行第二条规则；第二条规则的作用是将数据包重定向至代理程序的监听端口8123端口。

[0077] 如此一来，代理程序所发出的请求数据包均包含Mark标签，本地系统可通过Mark标签匹配来区分应用程序和代理程序，并进行分别处理，从而避免了背景技术中描述的死循环现象。

[0078] 不仅如此，由于请求数据包中的标签均带有掩码，可避免请求数据包在传输过程中，标签被修改后无法正确匹配的问题，具体而言，在Android 5.0及其以上版本的系统中，系统中的Netd会对数据包中的标签进行篡改，若标签中没有增加掩码，则无法正确进行匹配，经仔细研究发现，Netd对于一个32bits的标签的篡改，仅会影响其低20bits，故本实施例中，为标签打上掩码，并同时修改匹配规则，对未被篡改的部分进行匹配，从而避免了标签被篡改后无法正确匹配的问题，相应的，在Android 5.0及其以上版本的系统中，掩码的取值范围为0x8000000～0xfff00000。可以理解的是，在一些其他版本的系统下，若符合相应规则，也可以根据本实施例的处理思路进行处理，本发明并不以此为限。

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

[0080] 以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

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

[0082] 以上所述仅为本发明的较佳实施例，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。