一种网络URL资源处理方法及系统与流程

本发明涉及网络数据处理技术领域，尤其涉及一种网络url(uniformresourcelocator，统一资源定位符)资源处理方法及系统。

背景技术：

当前网关系统汇集的url资源很多，系统调用过程中，需要配置大量的url地址，而且暴露了真实的url地址，容易造成安全攻击。

因此，如何有效的实现url资源管理和服务治理，是一项亟待解决的问题。

技术实现要素：

有鉴于此，本发明提供了一种网络url资源处理方法，针对url资源汇集量大，服务资源暴露的问题，进行二次url资源汇集，能够使得调用方更为方便，网关引擎扩展更为灵活。

本发明提供了一种网络url资源处理方法，包括：

当外部访问网关时，通过网关前置解析服务密钥生成请求地址，并将所述请求地址转发至网关引擎；

所述网关引擎通过应用配置，将所述请求地址转发至应用系统。

优选地，所述当外部访问网关时，通过网关前置解析服务密钥生成请求地址，并将所述请求地址转发至网关引擎，包括：

当外部访问网关时，通过网关前置中的nginx与lua解析服务密钥生成请求地址，并将所述请求地址转发至网关引擎。

优选地，所述当外部访问网关时，通过网关前置中的nginx与lua解析服务密钥生成请求地址，并将所述请求地址转发至网关引擎，包括：

当外部访问网关时，获取超文本传输协议头信息；

解析所述头信息中的服务密钥字段；

将所述服务密钥字段中的“.”字符转换为“/”字符，生成所述请求地址；

转发所述请求地址至网关引擎。

优选地，所述nginx采用守护模式启动，采取异步非阻塞方式处理请求，所述nginx的io适用epoll函数，所述epoll函数为i/o复用模型。

一种网络url资源处理系统，包括：

网关前置，用于当外部访问网关时，解析服务密钥生成请求地址，并将所述请求地址转发至网关引擎；

网关引擎，用于通过应用配置，将所述请求地址转发至应用系统。

优选地，所述网关前置具体用于：

当外部访问网关时，通过网关前置中的nginx与lua解析服务密钥生成请求地址，并将所述请求地址转发至网关引擎。

优选地，所述网关前置包括：

获取单元，用于当外部访问网关时，获取超文本传输协议头信息；

解析单元，用于解析所述头信息中的服务密钥字段；

生成单元，用于将所述服务密钥字段中的“.”字符转换为“/”字符，生成所述请求地址；

转发单元，用于转发所述请求地址至网关引擎。

优选地，所述nginx采用守护模式启动，采取异步非阻塞方式处理请求，所述nginx的io适用epoll函数，所述epoll函数为i/o复用模型。

综上所述，本发明公开了一种网络url资源处理方法，当外部访问网关时，通过网关前置解析服务密钥生成请求地址，并将所述请求地址转发至网关引擎；所述网关引擎通过应用配置，将所述请求地址转发至应用系统。本发明通过加装网关前置对url资源进行二次汇集，有效解决了url资源汇集量大，服务资源暴露的问题，使得调用方更为方便，网关引擎扩展更为灵活。

附图说明

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

图1为本发明公开的一种网络url资源处理方法实施例1的方法流程图；

图2为本发明公开的一种网络url资源处理方法实施例2的方法流程图；

图3为本发明公开的一种网络url资源处理方法实施例3的方法流程图；

图4为本发明公开的一种网络url资源处理系统实施例1的结构示意图；

图5为本发明公开的一种网络url资源处理系统实施例2的结构示意图；

图6为本发明公开的一种网络url资源处理系统实施例3的结构示意图。

具体实施方式

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

如图1所示，为本发明公开的一种网络url资源处理方法实施例1的方法流程图，所述方法可以包括以下步骤：

s101、当外部访问网关时，通过网关前置解析服务密钥生成请求地址，并将请求地址转发至网关引擎；

当外部访问网关时，首先通过网关前置解析hread中的服务密钥信息，通过解析结果生成相应的请求地址，并将生成的请求地址转发至网关引擎。

s102、网关引擎通过应用配置，将请求地址转发至应用系统。

网关引擎在接收到网关前置代理转发的请求地址后，通过应用配置，将接收到的请求地址代理转发至应用系统。

综上所述，在上述实施例中，当外部访问网关时，通过网关前置解析服务密钥生成请求地址，并将所述请求地址转发至网关引擎；所述网关引擎通过应用配置，将所述请求地址转发至应用系统。通过加装网关前置对url资源进行二次汇集，有效解决了url资源汇集量大，服务资源暴露的问题，使得调用方更为方便，网关引擎扩展更为灵活。

如图2所示，为本发明公开的一种网络url资源处理方法实施例2的方法流程图，所述方法可以包括以下步骤：

s201、当外部访问网关时，通过网关前置中的nginx与lua解析服务密钥生成请求地址，并将请求地址转发至网关引擎；

当外部访问网关时，首先通过网关前置中的nginx与lua解析hread中的服务密钥信息，通过解析结果生成相应的请求地址，并将生成的请求地址转发至网关引擎。

具体的，网关前置中的nginx默认采用守护模式启动，守护模式让master进程启动后在后台运行。在nginx运行期间主要由一个master主进程和多个worker进程。其中，worker进程数目建议设为与cpu核数相同，这样每个worker进程都绑定特定的cpu核心，进程间切换的代价是最小的。因为一是nginx一般做的是高并发代理，基本没有io操作，大多数都是cpu密集型操作，很少出现io阻塞等情况。二是进程与cpu调度的关系，单个核心处理多个进程的时候，是排队处理的，如果设置多个进程的时候，是排队处理的，如果设置多个进程时，会带来进程间切换的开销。

master进程不会对用户请求提供服务，只用于管理真正提供服务的worker进程，所以master进程可以是唯一的，它仅专注于自己的纯管理工作，为管理员提供命令行服务，包括诸如启动服务、停止服务、重载配置文件、平滑升级程序等，当任意一个worker进程出现错误从而导致coredump时，master进程会立刻启动新的worker进程继续服务。

网络请求的处理，是放在worker进程中来完成的，而且只能在一个worker进程中处理。多个worker进程是相互独立且对等竞争的。

采用这种方式的好处：

节省锁带来的开销。对于每个worker进程来说，独立的进程，不需要加锁，所以省掉了锁带来的开销，同时在编程以及问题查上时，也会方便很多

独立进程，减少风险。采用独立的进程，可以让互相之间不会影响，当一个worker进程异常退出时，其它进程还在工作，服务不会中断，master进程则很快重新启动新的worker进程。虽然当前worker上的所有请求失败，不过不会影响到所有请求，所以降低了风险。

每个worker里面只有一个主线程，但一个worker可以同时处理多个请求。nginx采取异步非阻塞的方式处理请求，每个请求进来，worker线程将其注册处理转发给下游服务(如php-fpm)后，并不是挂起等待，而是切换处理别的请求。采用这种轮询的方式来并发处理大量请求。

nginx的io通常使用epoll，epoll函数使用了i/o复用模型。与i/o阻塞模型比较，i/o复用模型的优势在于可以同时等待多个(而不只是一个)套接字描述符就绪。其中，nginx的epoll工作流程如下：

1)首先，master进程接受到信号(如nginx-sreload)后启动，读取配置文件，建好需要listen的socket后，然后再fork出多个woker进程，这样每个work进程都可以去accept这个socket；

2)当一个client连接到来时，所有accept的work进程都会受到通知，但只有一个进程可以accept成功，其它的则会accept失败，nginx提供了一把共享锁accept_mutex来保证同一时刻只有一个work进程在accept连接，从而解决惊群问题；

3)当一个worker进程accept这个连接后，就开始读取请求，解析请求，处理请求，产生数据后，再返回给客户端，最后才断开连接，这样一个完成的请求就结束了；

4)一个worker进程可以同时处理多个请求，每个worker进程只有一个主线程，而是采用异步非阻塞的方式来处理并发请求。比如同时有多个httprequest的时候，worker主线程与第一条request建议连接将其处理转发给下游fastcgi后，并不会挂起等待，而是立马处理下一条，可以理解轮询处理。与多线程相比，这种事件处理方式是有很大的优势的，不需要创建线程，每个请求占用的内存也很少，没有上下文切换，事件处理非常的轻量级。并发数再多也不会导致无谓的资源浪费(上下文切换)，更多的并发数，只是会占用更多的内存而已。因此，nginx是非常适合处理高并发请求的。

具体的，网关前置中的lua是一个小巧的脚本语言。是巴西里约热内卢天主教大学(pontificalcatholicuniversityofriodejaneiro)里的一个研究小组，由robertoierusalimschy、waldemarceles和luizhenriquedefigueiredo所组成并于1993年开发。其设计目的是为了嵌入应用程序中，从而为应用程序提供灵活的扩展和定制功能。lua由标准c编写而成，几乎在所有操作系统和平台上都可以编译，运行。lua并没有提供强大的库，这是由它的定位决定的。所以lua不适合作为开发独立应用程序的语言。lua有一个同时进行的jit项目，提供在特定平台上的即时编译功能。

2)lua脚本可以很容易的被c/c++代码调用，也可以反过来调用c/c++的函数，这使得lua在应用程序中可以被广泛应用。不仅仅作为扩展脚本，也可以作为普通的配置文件，代替xml，ini等文件格式，并且更容易理解和维护。lua由标准c编写而成，代码简洁优美，几乎在所有操作系统和平台上都可以编译，运行。一个完整的lua解释器不过200k，在目前所有脚本引擎中，lua的速度是最快的。这一切都决定了lua是作为嵌入式脚本的最佳选择。

s202、网关引擎通过应用配置，将请求地址转发至应用系统。

网关引擎在接收到网关前置代理转发的请求地址后，通过应用配置，将接收到的请求地址代理转发至应用系统。

综上所述，本实施例在上述实施例的基础上，在网关前置中具体采用nginx与lua解析服务密钥生成请求地址，并将请求地址转发至网关引擎，有效实现了并发处理大量请求。

如图3所示，为本发明公开的一种网络url资源处理方法实施例3的方法流程图，所述方法可以包括以下步骤：

s301、当外部访问网关时，获取超文本传输协议头信息；

当外部访问网关时，首先通过网关前置解析hread中的服务密钥信息，通过解析结果生成相应的请求地址，并将生成的请求地址转发至网关引擎。

具体的，首先获取http头信息。

s302、解析头信息中的服务密钥字段；

然后，解析头servicekey字段，判断字段长度，并设置字段头是否存在。

s303、将服务密钥字段中的“.”字符转换为“/”字符，生成请求地址；

将servicekey字段的“.”字符转换为“/”字符，防护一个url资源的值，生成请求地址。

s304、转发请求地址至网关引擎；

然后，将生成的请求地址转发至网关引擎。

例如，用户访问http://xxx/mp-api/，在hread中录入servicekey＝tc.order，则后端转发http://网关/tc/order至网关引擎。

s305、网关引擎通过应用配置，将请求地址转发至应用系统。

网关引擎在接收到网关前置代理转发的请求地址后，通过应用配置，将接收到的请求地址代理转发至应用系统。

综上所述，本发明采用网关前置能够灵活的与网关引擎隔离，可以对url进行汇集，不暴露真实url地址，能够利用nginx自有的高并发能力提供服务。

如图4所示，为本发明公开的一种网络url资源处理系统实施例1的结构示意图，所述系统可以包括：

网关前置401，用于当外部访问网关时，通过网关前置解析服务密钥生成请求地址，并将请求地址转发至网关引擎；

当外部访问网关时，首先通过网关前置解析hread中的服务密钥信息，通过解析结果生成相应的请求地址，并将生成的请求地址转发至网关引擎。

网关引擎402，用于网关引擎通过应用配置，将请求地址转发至应用系统。

网关引擎在接收到网关前置代理转发的请求地址后，通过应用配置，将接收到的请求地址代理转发至应用系统。

综上所述，在上述实施例中，当外部访问网关时，通过网关前置解析服务密钥生成请求地址，并将所述请求地址转发至网关引擎；所述网关引擎通过应用配置，将所述请求地址转发至应用系统。通过加装网关前置对url资源进行二次汇集，有效解决了url资源汇集量大，服务资源暴露的问题，使得调用方更为方便，网关引擎扩展更为灵活。

如图5所示，为本发明公开的一种网络url资源处理系统实施例2的结构示意图，所述系统可以包括：

网关前置501，用于当外部访问网关时，通过网关前置中的nginx与lua解析服务密钥生成请求地址，并将请求地址转发至网关引擎；

当外部访问网关时，首先通过网关前置中的nginx与lua解析hread中的服务密钥信息，通过解析结果生成相应的请求地址，并将生成的请求地址转发至网关引擎。

具体的，网关前置中的nginx默认采用守护模式启动，守护模式让master进程启动后在后台运行。在nginx运行期间主要由一个master主进程和多个worker进程。其中，worker进程数目建议设为与cpu核数相同，这样每个worker进程都绑定特定的cpu核心，进程间切换的代价是最小的。因为一是nginx一般做的是高并发代理，基本没有io操作，大多数都是cpu密集型操作，很少出现io阻塞等情况。二是进程与cpu调度的关系，单个核心处理多个进程的时候，是排队处理的，如果设置多个进程的时候，是排队处理的，如果设置多个进程时，会带来进程间切换的开销。

master进程不会对用户请求提供服务，只用于管理真正提供服务的worker进程，所以master进程可以是唯一的，它仅专注于自己的纯管理工作，为管理员提供命令行服务，包括诸如启动服务、停止服务、重载配置文件、平滑升级程序等，当任意一个worker进程出现错误从而导致coredump时，master进程会立刻启动新的worker进程继续服务。

网络请求的处理，是放在worker进程中来完成的，而且只能在一个worker进程中处理。多个worker进程是相互独立且对等竞争的。

采用这种方式的好处：

节省锁带来的开销。对于每个worker进程来说，独立的进程，不需要加锁，所以省掉了锁带来的开销，同时在编程以及问题查上时，也会方便很多

独立进程，减少风险。采用独立的进程，可以让互相之间不会影响，当一个worker进程异常退出时，其它进程还在工作，服务不会中断，master进程则很快重新启动新的worker进程。虽然当前worker上的所有请求失败，不过不会影响到所有请求，所以降低了风险。

每个worker里面只有一个主线程，但一个worker可以同时处理多个请求。nginx采取异步非阻塞的方式处理请求，每个请求进来，worker线程将其注册处理转发给下游服务(如php-fpm)后，并不是挂起等待，而是切换处理别的请求。采用这种轮询的方式来并发处理大量请求。

nginx的io通常使用epoll，epoll函数使用了i/o复用模型。与i/o阻塞模型比较，i/o复用模型的优势在于可以同时等待多个(而不只是一个)套接字描述符就绪。其中，nginx的epoll工作流程如下：

3)首先，master进程接受到信号(如nginx-sreload)后启动，读取配置文件，建好需要listen的socket后，然后再fork出多个woker进程，这样每个work进程都可以去accept这个socket；

2)当一个client连接到来时，所有accept的work进程都会受到通知，但只有一个进程可以accept成功，其它的则会accept失败，nginx提供了一把共享锁accept_mutex来保证同一时刻只有一个work进程在accept连接，从而解决惊群问题；

3)当一个worker进程accept这个连接后，就开始读取请求，解析请求，处理请求，产生数据后，再返回给客户端，最后才断开连接，这样一个完成的请求就结束了；

4)一个worker进程可以同时处理多个请求，每个worker进程只有一个主线程，而是采用异步非阻塞的方式来处理并发请求。比如同时有多个httprequest的时候，worker主线程与第一条request建议连接将其处理转发给下游fastcgi后，并不会挂起等待，而是立马处理下一条，可以理解轮询处理。与多线程相比，这种事件处理方式是有很大的优势的，不需要创建线程，每个请求占用的内存也很少，没有上下文切换，事件处理非常的轻量级。并发数再多也不会导致无谓的资源浪费(上下文切换)，更多的并发数，只是会占用更多的内存而已。因此，nginx是非常适合处理高并发请求的。

具体的，网关前置中的lua是一个小巧的脚本语言。是巴西里约热内卢天主教大学(pontificalcatholicuniversityofriodejaneiro)里的一个研究小组，由robertoierusalimschy、waldemarceles和luizhenriquedefigueiredo所组成并于1993年开发。其设计目的是为了嵌入应用程序中，从而为应用程序提供灵活的扩展和定制功能。lua由标准c编写而成，几乎在所有操作系统和平台上都可以编译，运行。lua并没有提供强大的库，这是由它的定位决定的。所以lua不适合作为开发独立应用程序的语言。lua有一个同时进行的jit项目，提供在特定平台上的即时编译功能。

4)lua脚本可以很容易的被c/c++代码调用，也可以反过来调用c/c++的函数，这使得lua在应用程序中可以被广泛应用。不仅仅作为扩展脚本，也可以作为普通的配置文件，代替xml，ini等文件格式，并且更容易理解和维护。lua由标准c编写而成，代码简洁优美，几乎在所有操作系统和平台上都可以编译，运行。一个完整的lua解释器不过200k，在目前所有脚本引擎中，lua的速度是最快的。这一切都决定了lua是作为嵌入式脚本的最佳选择。

网关引擎502，用于网关引擎通过应用配置，将请求地址转发至应用系统。

网关引擎在接收到网关前置代理转发的请求地址后，通过应用配置，将接收到的请求地址代理转发至应用系统。

综上所述，本实施例在上述实施例的基础上，在网关前置中具体采用nginx与lua解析服务密钥生成请求地址，并将请求地址转发至网关引擎，有效实现了并发处理大量请求。

如图6所示，为本发明公开的一种网络url资源处理系统实施例3的结构示意图，所述系统可以包括：

获取单元601，用于当外部访问网关时，获取超文本传输协议头信息；

当外部访问网关时，首先通过网关前置解析hread中的服务密钥信息，通过解析结果生成相应的请求地址，并将生成的请求地址转发至网关引擎。

具体的，首先获取http头信息。

解析单元602，用于解析头信息中的服务密钥字段；

然后，解析头servicekey字段，判断字段长度，并设置字段头是否存在。

生成单元603，用于将服务密钥字段中的“.”字符转换为“/”字符，生成请求地址；

将servicekey字段的“.”字符转换为“/”字符，防护一个url资源的值，生成请求地址。

转发单元604，用于转发请求地址至网关引擎；

然后，将生成的请求地址转发至网关引擎。

例如，用户访问http://xxx/mp-api/，在hread中录入servicekey＝tc.order，则后端转发http://网关/tc/order至网关引擎。

网关引擎605，用于网关引擎通过应用配置，将请求地址转发至应用系统。

网关引擎在接收到网关前置代理转发的请求地址后，通过应用配置，将接收到的请求地址代理转发至应用系统。

综上所述，本发明采用网关前置能够灵活的与网关引擎隔离，可以对url进行汇集，不暴露真实url地址，能够利用nginx自有的高并发能力提供服务。

本发明提供了一种内生安全的网络数据报文可编程处理装置。其中，内生安全设计，来源于拟态防御的核心思想：采用动态异构冗余架构和负反馈控制机制将不确定威胁转化为概率可控的事件，从而实现了自主可控、安全可信。在拟态防御系统中，复制分发代理将输入请求被发送到多个功能等价的异构执行体；每个异构执行体单独处理输入并产生给定语义和语法的输出矢量，处理后的结果提交给裁决器进行判决，裁决器根据多次迭代的裁决策略，对满足判决条件的结果进行输出。通常一般攻击效果只能单次作用，拟态系统可以快速感知并恢复，而一旦某个执行体出现持续性异常，此时需要消除一致状态进行系统重构与清洗。如果发现判决出现多数不一致情况，此时需要考虑是否更换裁决策因此，拟态防御技术可以引入到数据平面，从而有效抵抗数据平面的已知和未知威胁。

在可编程数据平面中，由于缺少安全技术的部署，用户在自定义程序设计过程不可避免的会带来安全漏洞。因此本发明在网络数据报文可编程处理装置中引入拟态防御思想，设计了一种内生安全的网络数据报文可编程处理装置100，其总体架构如图1所示。本发明首先对解析器进行内生安全设计，设计了解析分发器10。再对流水线结构进行改造，设计了多种功能等价的异构流水线结构20(图1中流水线结构1-流水线结构n)。接着再将n条异构流水线处理结果进行裁决，于是对逆解析器进行改造，设计了逆解析裁决器30。最后再对整个过程设计一个负反馈控制器40，实现对裁决后解析分发器和流水线结构状态信息的动态反馈调节。

为进一步理解本发明的具体过程，下面对本发明的工作原理进行详细描述，分为2个步骤：

步骤1：本发明基于拟态防御思想对网络数据报文可编程处理装置进行动态异构冗余改造。按照数据处理的先后顺序，分别对数据报文解析分发器10、多个功能等价的异构流水线结构20、逆解析裁决器30以及负反馈控制器40进行设计。解析分发器10通过物理器件或逻辑固化方式实现对数据报文的解析以及复制分发功能。解析配置阶段，首先，对交换机进行特定的配置操作，用于编写解析器，指定“匹配-执行动作”各阶段要处理的协议首部区域。解析分发器10接收到装置外输入的网络数据报文后，根据交换机配置信息中的解析图进行解析处理，并提取出特定名称和类型的首部区域，并将那些需要进行“匹配-动作”的首部区域与余下报文头和载荷进行分开缓存。对解析后的数据报文的信息进行记录，如地址、接入端口。对于需要匹配动作的数据部分进行复制并分发到异构的流水线结构20，各流水线结构根据自身配置独自对数据报文进行匹配动作等操作，将输出结果发送给逆解析裁决器30。具体的，如图2所示，异构流水线中的入口流水线在接收到数据报文解析结果后，根据自身配置进行流水线处理，对数据的匹配动作等操作，包括丢弃、转发、数据修改等。若收到负反馈控制器的控制指令则进行相应的重配置、清洗、初始化等操作。异构流水线中的流量管理模块用于流量控制。经入口流水线处理后的解析数据会送至异构流水线中的出口流水线进行处理，出口流水线处理的结果包含对数据的执行操作，包括但不限于丢弃、转发、数据修改等。若收到负反馈控制器的控制指令则进行相应的重配置、清洗、初始化等操作。

逆解析裁决器30通过物理器件或逻辑固化方式实现对数据报文的裁决以及逆解析功能。逆解析裁决器30接收到经异构流水线结构20处理后的数据报文结果后，首先会对所有数据结果进行裁决，裁决包括多模判决和策略裁决两部分。首先，逆解析裁决器30会对多条流水线输出数据进行多模判决，将多数一致的结果作为唯一结果。若多模判决出现多数不一致情况，逆解析裁决器30会依据流水线的历史置信度、流水线结构品质等因素选出其中一条符合裁决要求的输出结果。将符合裁决要求的唯一结果送至逆解析模块；逆解析模块接收到数据后，将裁决数据，余下报文头和报文载荷逆解析为一个完整的数据报文。最后逆解析裁决器30将裁决状态信息发送给负反馈控制器40，为数据报文解析分发器和异构流水线结构提供动态调度和重构策略，最终实现该模型对已知和未知攻击具有内生安全属性。

步骤2：本发明中负反馈控制器40为下次数据处理提供策略，在整个数据报文处理模型中，逆解析裁决器30-负反馈控制器40-解析分发器10(或异构流水线结构20)为单向设计。逆解析裁决器30通过简单逻辑固化处理，保证裁决单点安全，为负反馈控制器40提供正常状态信息。负反馈控制器40本身通过相应算法或自学习机制进行策略反馈。

通过步骤1和步骤2实现整个数据报文处理模型中数据处理与反馈控制，本发明可有效应对网络空间已知和未知风险，保证网络基础平台的内生安全性。

本说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(ram)、内存、只读存储器(rom)、电可编程rom、电可擦除可编程rom、寄存器、硬盘、可移动磁盘、cd-rom、或技术领域内所公知的任意其它形式的存储介质中。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的精神或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。