一种故障检测方法和装置与流程

本申请属于互联网技术领域，尤其涉及一种故障检测方法和装置。

背景技术：

目前，云计算的应用越来越多，企业可以利用一些云平台提供的一些虚拟网络产品(例如：虚拟交换机、虚拟负载均衡器等)，通过这些虚拟网络产品，可以搭建出很多较为复杂的网络环境。

然而，在这样一个庞大而复杂的云计算虚拟化网络环境下，经常由于网络设备故障、线路故障、物理机资源抢占、vm(virtualmachine，虚拟机)负载过重、软件产品bug、策略问题、网络攻击等各种问题导致网络访问延时过大，从而影响了用户业务的正常运行。

如果通过人工排查的方式查询这些故障，往往会因为网络链路过长而导致出现比较耗时的问题，且很难准确找出所有问题的链路。且有时候访问延时仅是由一段网络链路有问题造成的，有时候也可能是由于几段网络链路出现问题造成的。

然而，针对准确高效地自动确定出存在故障的链路段，目前尚未提出有效的解决方案。

技术实现要素：

本申请目的在于提供一种故障检测方法和装置，可以实现通过延时分布来定位网络故障链路段的技术效果。

本申请提供一种故障检测方法和装置是这样实现的：

一种故障检测方法，所述方法包括：

获取至少一个网络数据包在待检测链路的多个链路段的多个往返时延，其中，所述待检测链路包括多个链路段；

根据所述多个往返时延，确定所述多个链路段的丢包或延时情况；

确定故障链路段。

一种故障检测装置，所述装置包括：

获取模块，用于获取至少一个网络数据包在待检测链路的多个链路段的多个往返时延，其中，所述待检测链路包括多个链路段；

第一确定模块，用于根据所述多个往返时延，确定所述多个链路段的丢包或延时情况；

第二确定模块，用于确定故障链路段。

一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述方法的步骤。

本申请提供的故障检测方法和装置，将待检测的链路划分为多个链路段，并确定各个链路段的丢包和延时情况，从而可以有效确定是哪个链路段或者是哪几个链路段发生的故障，从而解决了现有方式无法自动高效确定出哪段链路出现故障的技术问题，达到了通过延时分布来定位网络故障链路段的技术效果。

附图说明

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

图1是本申请提供的故障检测方法一种实施例的方法流程图；

图2是本申请提供的网络链路的链路段划分示意图；

图3是本申请提供是网络链路中数据包在链路各个节点的传输示意图；

图4是本申请提供的基于链路上的抓包库中的各个文件对多个网络数据包进行关联分析的方法流程图；

图5是本申请提供的确定延时分布情况的方法流程图；

图6是本申请提供的处理设备的一种实施例的模型结构示意图；

图7是本申请提供的故障检测装置一种实施例的模块结构示意图。

具体实施方式

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

考虑到网络访问延时有时是由于一段链路故障导致的，也可能是由于几段链路故障导致的，在确定访问延时原因的时候，如果仅确定整条链路是否故障显然是不合理的。为了实现简单高效确定出待检测链路上哪段链路发生故障的目的，在本例中，考虑到可以将待检测链路分为多个链路段，然后，进行检测统计得到各个链路段的丢包和延时情况，从而确定出链路中具体的故障链路段，使得查找到的故障链路可以具体到某一段链路或者某几段链路，而不是一整条链路，从而提高了链路故障检测的精度和效率。

图1是本申请所述一种故障链路段的确定方法一个实施例的方法流程图。虽然本申请提供了如下述实施例或附图所示的方法操作步骤或装置结构，但基于常规或者无需创造性的劳动在所述方法或装置中可以包括更多或者更少的操作步骤或模块单元。在逻辑性上不存在必要因果关系的步骤或结构中，这些步骤的执行顺序或装置的模块结构不限于本申请实施例描述及附图所示的执行顺序或模块结构。所述的方法或模块结构的在实际中的装置或终端产品应用时，可以按照实施例或者附图所示的方法或模块结构连接进行顺序执行或者并行执行(例如并行处理器或者多线程处理的环境，甚至分布式处理环境)。

具体的，如图1所示，本申请一种实施例提供的一种故障检测方法可以包括如下步骤：

步骤101：获取至少一个网络数据包在待检测链路的多个链路段的多个往返时延，其中，所述待检测链路包括多个链路段；

其中，往返时延(round-triptime，简称为rtt)在计算机网络中是一个重要的性能指标，表示从发送端发送数据开始，到发送端收到来自接收端的确认(接收端收到数据会立即发送确认)所经历的时间。例如：发送端为a，接收端b，从发送端向接收端发送数据包x，那么该数据包发送的往返时延，就是从a向b发送x，从a接收到b基于x发送的确收消息的时间。

待检测链路，链路上一般是有多个带有转发功能的网卡的，即，一个数据包在数据链路上一般是通过多个网卡进行转发的。在实现上，可以将带有转发功能的网卡作为分解节点，每两个相邻网卡之间的链路可以作为一个链路段，一般出现问题也是某个网卡出现了问题，或者是相邻俩网卡之间的链路出现问题，使得数据包发送延时。

因此，在进行链路分段的时候，可以通过带有转发功能的网卡作为分解节点，在实现的时候，可以将待检测链路上每个带有转发功能的网卡都作为一个分解节点，也可以是选取该待检测链路上的几个带有转发功能的网卡作为分解节点，例如，间隔性选取，或者随机选取等等。具体采用哪种方式选取分解节点进行链路的分段可以根据实际需要选择，本申请对此不作限定。

在通过选择的分解节点将链路划分为多个链路段之后，可以在每个分解节点上部署一个监控点。为了实现自动化检测，可以自动触发端到端(待检测链路的起始端到终点段)的ping指令，然后通过各个分解节点上的监控点在一段时间内采集到的各个分解节点上传输数据包的延时，然后，将各个监控点的延时结果进行关联分析。

举例而言，如图2所示，一条待检测链路：a至f，其中带转发功能的网卡为：a、b、c、d、e、f。假设每个带有转发功能的网卡都作为分解节点，那么，整个链路也就以这六个网卡作为分解节点分为多个链路段。

假设当前需要检测a到f中是否存在故障链路段，那么可以如图3所示，从a发送数据包，接收端设置为f。在数据包的发送过程中，即通过各个带有转发功能的网卡进行的转发，直至发送到接收端f，然后，接收端f在接收到该数据包后，会立即发送一个确认消息返回至发送端a，确认消息也是通过各个带有转发功能的网卡传送回来的。

因为每个分解节点处都部署了监控节点，因此，可以捕获到数据包传送过程中每个分解节点处的rtt(往返时延)。如果有多个数据包传送，那么就可以获取到每个数据包发送时候，多个数据包中各个数据包传输过程中各个传送节点的往返时延。

如图3所示，假设数据包的发送预定路径是从a传输f(a点为发送端，f点为接收端)，那么a点的rtt是：数据包从a到f，确认消息从f到a的总时间，b点的rtt是：数据包从b到f，确认消息从f到b的总时间，c点的rtt是：数据包从c到f，确认消息从f到c的总时间，d点的rrt是：数据包从d到f，确认消息从f到d的总时间，e点的rtt是：数据包从e到f，确认消息从f到e的总时间。

假设数据包的发送预定路径是从b传输到e(b点为发送端，e点为接收端)，那么b点的rtt是：数据包从b到e，确认消息从e到b的总时间，c点的rtt是：数据包从c到e，确认消息从e到c的总时间，d点的rtt是：数据包从d到e，确认消息从d到b的总时间.，这时就没有a点和f的记录，因为数据包的传输路径就是b到e，a和f都不在传输路径中。

考虑到是对延时情况或者丢包情况的统计，以确定哪些链路段出现问题，因此，可以仅选择存在延时的数据包作为需要统计的数据包，对于不存在延时的数据包，可以不进行统计，以便减少计算量。

在一个实施方式中，获取网络数据包在待检测链路的多个链路段的往返时延，可以包括：触发在所述待检测链路上进行端到端的数据包传输；获取预定时间内，各分解节点上部署的监控点采集到的数据包往返时延；对所述各分解节点上部署的监控点采集到的数据包往返时延进行联合分析，得到多个存在传输延时的网络数据包在待检测链路的多个链路段的往返时延。具体地，可以通过自动触发端到端的ping，以达到自动实现获取多个数据包的往返延时的目的。

步骤102：根据所述多个往返时延，确定多个链路段的丢包或延时情况。

步骤103：根据所述多个链路段的丢包或延时情况，确定故障链路段。

即，通过一段时间的采集，就可以将各个监控点的结果收集起来在后台进行关联分析，统计出各个链路段的丢包情况和延时情况，例如：确定出a到f的延时次数、丢包次数、b到e的延时次数、丢包次数等等，通过这种直观的结果展示，可以有效确定出哪段或者哪几段链路出现了故障，以及延时和丢包情况哪些链路段比较严重。

进一步的，还可以将出现延时的数据包在每个链路段所消耗的时间依次展现出来，使得简单看出来哪些段延迟比较严重。

在一个实施方式中，根据所述多个往返时延，确定多个链路段的丢包或延时情况，可以包括：

按照以下步骤依次遍历当前网络数据包经过的分解节点对应的往返时延数据，以得到基于当前网络数据包的多个链路段的丢包或延时情况：

s1：将当前分解节点作为第一分解节点；

假设以节点a作为第一分解节点。

s2：读取所述当前网络数据包在所述第一分解节点的第一往返时延；

例如：获取数据包p在节点a处的往返时延rtt1。

s3：确定所述第一分解节点是否存在下一个分解节点；

即，确定在节点a到数据包p的接收端之间是否有其它的分解节点。

s4：如果不存在，则确定所述第一往返时延是否为无穷大，如果为无穷大，则对所述待检测链路的丢包记录执行加一操作，如果不为无穷大，则对所述待检测链路的延时记录执行加一操作并记录该延时的延时信息；

假设接收端为节点b，即，在发送端和接收端之间不存在其它分解节点，就表明数据包p以a为发送端的情况下，传输路径就是直接节点a到节点b，之间不经过其它的节点，那么rtt1所表征的就是数据包从节点a到节点b，确认消息从节点b到节点a的时间。因为确定数据包p是一个延时数据包，因此，确定rtt1是否为无穷大(∞)，无穷大就表明一直没有收到确认消息，那也就可以确认a到b之间发生了一次丢包操作，这时，就可以将该段(a至b)的丢包操作记录执行加一操作，如果rtt1不是无穷大，就表明后续是收到确认消息的，也就相当于没有发生丢包，仅是一次传输延时，那么就可以将该段(a至b)的延时记录执行加一操作，为了使得可以明确每段的数据包传输延时的具体时长等，这时可以记录此数据包在a至b段之间的延时时间。

s4：如果存在，则将下一个分解节点作为第二分解节点，读取所述当前网络数据包在所述第二分解节点的第二往返时延，根据所述第一往返时延和所述第二往返时延确定所述当前网络数据包在所述第一分解节点到所述第二分解节点之间的延时或丢包情况。

具体的，根据所述第一往返时延和所述第二往返时延确定所述当前网络数据包在所述第一分解节点到所述第二分解节点之间的延时或丢包情况，可以包括：

1)在所述第一往返时延为无穷大，所述第二往返时延不为无穷大的情况下，对所述第一分解节点到所述第二分解节点之间的链路段的丢包记录加一；

2)在所述第一往返时延不为无穷大，所述第二往返时延也不为无穷大的情况下，确定所述第一往返时延与所述第二往返时延之间的差值是否大于预设阈值，如果大于预设阈值，则对所述第一分解节点到所述第二分解节点之间的链路段的延时记录执行加一操作并记录该延时的延时信息。

假设当前判断的是从a到c之间的传输延时记录，数据包经过的是a、b、c，那么可以确定出到数据包的接收端除了a之外还有节点b，因此，在得到a到c的rtt1之后，还可以得到b到c的rtt2。基于rtt1和rtt2，可以实现对a到c，a到b，b到c之间的延时和丢包情况的统计。具体的：

1)如果rtt1为无穷大，rtt2也是无穷大，就表明在a到b之间的链路段是没有问题的，后续在以b点为首节点进行判断的时候，如果b之后没有节点，因为b到c之间的rtt是无穷大的，就表明b节点到c之间存在丢包。因此，在以a节点作为首节点判断当前数据包的延时丢包情况的时候，如果a到b，b到c之间的rtt都是无穷大，就忽略不管，等后续确定具体是哪个链路段出现的故障；

2)如果rtt1为无穷大，rtt2不是无穷大，那就表明，b到c之间是没有问题的，问题出现在a和b之间，a和b之间是存在丢包的。从而可以将a至b段的丢包记录执行加一操作；

3)如果rtt1不是无穷大，rtt2也不是无穷大，那就表明a和b都收到了c点的确认消息，这时，可以计算rtt1-rtt2用于表征a和b之间的数据传输时间，如果rtt1-rtt2大于预设的延时阈值，就表明在a到b之间是存在延时的，因此，可以将a至b的延时记录执行加一操作，为了使得可以明确每段的数据包传输延时的具体时长等，这时可以记录此数据包在a至b段之间的延时时间。如果rtt1-rtt2不大于预设的延时阈值，就表明a到b之间是不存在延时的，就可以不进行记录调整。

如果对每个延时数据包，基于传输路径中每个节点都作为首节点进行上述的更新延时和丢包记录的更新，最终就可以得到各个节点(分解节点)所形成的链路段中各个链路的延时和丢包情况，再将所有出现延时的数据包包在每个链路段所消耗时间依次展示出来，可以实现对各个链路段的故障情况进行简单高效的判断。

下面结合一个具体实施例对上述故障链路段的确定方法进行说明，然而，值得注意的是，该具体实施例仅是为了更好地说明本申请，并不构成对本申请的不当限定。

在本例中，考虑到在云计算的虚拟化网络环境下，人工定位网络故障链路段困难而且非常耗时，提出了一种确定链路段故障的方法，从而可以极大地提高服务响应的速度，节省人力成本。

具体地，可以先将待检测的链路分解为多个链路段(例如：n个)，在分解的时候，可以将该链路上每一个具有转发功能的网卡定义为一个分解节点，当然也可以选择某几个具有转发功能的网卡作为分解节点，而不是选择所有的具有转发功能的网卡都作为分解节点。在实际实现的时候，可以根据需要从待检测链路中选择分解节点，以实现对待检测链路的分解。

在每一个节点上都部署一个监控点，然后，自动触发端到端(要检测的两端)的ping，然后，将采集到的icmp(internetcontrolmessageprotocol，internet控制报文协议)包分别保存在文件里，通过一段时间的采集，再将各个监控点的结果收集来到后台进行关联性分析，最后，直观地展示出哪一些或哪几段出现了网络故障，其中，所谓的网络故障可以是数据包延时大于预设的合法阈值，或者是出现了丢包情况，且可以将所有出现延时的包在每个链路段所消耗时间依次展示出来。

具体的，可以如图4所示，对基于链路上的抓包库中的各个文件对多个网络数据包进行关联分析：

s1：加载链路上的第一个pcap文件(针对网络接口、端口和协议的数据包截取的文件)；

s2：逐个遍历第一个pcap文件中的每一条记录：

如果当前的记录为request(请求)icmp数据包，则新创建一个文件并添加一条新纪录，具体的记录中可以包括<id，seq，request时间戳，response时间戳>；

如果当前的记录为response(确认回复)icmp数据包，则确定延时是否大于阈值，如果大于，那么更新记录，记录该延时记录，如果不小于阈值，则可以将该记录删除了。

s3：加载链路上的下一个pcap文件；

s4：逐个遍历pcap文件中的每一条记录：

如果当前的记录为request(请求)icmp数据包，则建立一条临时记录；

如果当前的记录为response(确认回复)icmp数据包，则确定延时是否大于阈值，如果大于，那么就在上述创建的文件中查找是否存在该记录，就继续记录，如果确定延时不大于阈值，则删除临时记录。

s5：直至遍历完所有的pcap文件，进行保存并展示。

通过上面的关联分析，可以得到所有延时包在各个监控节点上的rtt，也就是说，对于一条延时的icmp包记录而言，在经过一个监控节点时如果rtt大于设定检测阀值，那么就会存在对应的一条rtt记录。基于得到的记录结果，可以进行整个链路的诊断分析，具体的，可以得到所有延时在各链路段上的延时分布情况。

在确定延时分布情况的时候，可以按照如图5所示的步骤实现：

s1：获取一条延时的icmp包记录；

s2：依次遍历该数据包经过的每个监控节点对应的rtt记录：

得到一条记录rtt1，确定该rtt1之后是否还有下一条rtt记录：1)如果不存在下一条rtt记录，则确定rtt1是否为无穷大，如果是无穷大，则对应链路段增加一条丢包统计，如果不是无穷大，则对应链路段增加一条延时统计，并记录下具体的延时；2)如果存在下一条rtt记录，读取下一条记录rtt2，在rtt1为无穷大但rtt1不是无穷大的情况下，对应链路段增加一条丢包统计，在rtt1不是无穷大rtt2也不是无穷大的情况下，确定rtt1-rtt2是否大于预设阈值，如果大于，则对应链路增加一条延时统计，并记录下具体的延时，如果不大于，则执行步骤s3，直至遍历完该数据包对应的所有rtt记录。

s3：退出。

在上例中，通过将长而复杂的网络链路进行分段监测，然后再将各节点的监测结果进行关联分析从而找到有故障的网络链路段，从而自动化地解决了定位网络故障链路段。解决了现有的在云计算的虚拟化网络环境下，人工定位网络故障链路段困难而且非常耗时的技术问题，从而极大地提高服务响应的速度，节省了人力成本。

图6示出了根据本申请的一示例性实施例的处理设备的示意结构图。请参考图6，在硬件层面，该处理设备包括处理器、内部总线、网络接口、内存以及非易失性存储器，当然还可能包括其他业务所需要的硬件。处理器从非易失性存储器中读取对应的计算机程序到内存中然后运行，在逻辑层面上形成故障检测装置。当然，除了软件实现方式之外，本申请并不排除其他实现方式，比如逻辑器件抑或软硬件结合的方式等等，也就是说以下处理流程的执行主体并不限定于各个逻辑单元，也可以是硬件或逻辑器件。

请参考图7，在软件实施方式中，该故障检测装置可以包括获取模块、第一确定模块和第二确定模块。其中：

获取模块，用于获取至少一个网络数据包在待检测链路的多个链路段的多个往返时延，其中，所述待检测链路包括多个链路段；

第一确定模块，用于根据所述多个往返时延，确定所述多个链路段的丢包或延时情况；

第二确定模块，用于确定故障链路段。

在一个实施方式中，待检测链路可以通过多个分解节点被划分为多个链路段，其中，所述分解节点包括：所述待检测链路上具有转发功能的网卡。

在一个实施方式中，获取模块可以包括：触发单元，用于触发在所述待检测链路上进行端到端的数据包传输；获取单元，用于获取预定时间内，所述待检测链路上的分解节点上部署的监控点采集到的数据包往返时延；分析单元，用于对所述分解节点上部署的监控点采集到的数据包往返时延进行联合分析，得到存在传输延时的网络数据包在所述多个链路段的多个往返时延。

在一个实施方式中，第一确定模块具体可以用于按照以下步骤依次遍历当前网络数据包经过的分解节点对应的往返时延数据，以得到基于当前网络数据包的多个链路段的丢包或延时情况：

将当前分解节点作为第一分解节点；

读取所述当前网络数据包在所述第一分解节点的第一往返时延；

确定所述第一分解节点是否存在下一个分解节点；

如果不存在，则确定所述第一往返时延是否为无穷大，如果为无穷大，则对所述待检测链路的丢包记录执行加一操作，如果不为无穷大，则对所述待检测链路的延时记录执行加一操作并记录该延时的延时信息；

如果存在，则将下一个分解节点作为第二分解节点，读取所述当前网络数据包在所述第二分解节点的第二往返时延，根据所述第一往返时延和所述第二往返时延确定所述当前网络数据包在所述第一分解节点到所述第二分解节点之间的延时或丢包情况。

在一个实施方式中，第一确定模块可以根据所述第一往返时延和所述第二往返时延确定所述当前网络数据包在所述第一分解节点到所述第二分解节点之间的延时或丢包情况，具体包括：

在所述第一往返时延为无穷大，所述第二往返时延不为无穷大的情况下，对所述第一分解节点到所述第二分解节点之间的链路段的丢包记录加一；

在所述第一往返时延不为无穷大，所述第二往返时延也不为无穷大的情况下，确定所述第一往返时延与所述第二往返时延之间的差值是否大于预设阈值，如果大于预设阈值，则对所述第一分解节点到所述第二分解节点之间的链路段的延时记录执行加一操作并记录该延时的延时信息。

本申请提供的故障检测方法和装置，将待检测的链路划分为多个链路段，并确定各个链路段的丢包和延时情况，从而可以有效确定是哪个链路段或者是哪几个链路段发生的故障，从而解决了现有方式无法自动高效确定出哪段链路出现故障的技术问题，达到了通过延时分布来定位网络故障链路段的技术效果。

虽然本申请提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的劳动可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的装置或客户端产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境)。

上述实施例阐明的装置或模块，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。为了描述的方便，描述以上装置时以功能分为各种模块分别描述。在实施本申请时可以把各模块的功能在同一个或多个软件和/或硬件中实现。当然，也可以将实现某功能的模块由多个子模块或子单元组合实现。

本申请中所述的方法、装置或模块可以以计算机可读程序代码方式实现控制器按任何适当的方式实现，例如，控制器可以采取例如微处理器或处理器以及存储可由该(微)处理器执行的计算机可读程序代码(例如软件或固件)的计算机可读介质、逻辑门、开关、专用集成电路(applicationspecificintegratedcircuit，asic)、可编程逻辑控制器和嵌入微控制器的形式，控制器的例子包括但不限于以下微控制器：arc625d、atmelat91sam、microchippic18f26k20以及siliconelabsc8051f320，存储器控制器还可以被实现为存储器的控制逻辑的一部分。本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内部包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

本申请所述装置中的部分模块可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构、类等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

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

本说明书中的各个实施例采用递进的方式描述，各个实施例之间相同或相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。本申请的全部或者部分可用于众多通用或专用的计算机系统环境或配置中。例如：个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、移动通信终端、多处理器系统、基于微处理器的系统、可编程的电子设备、网络pc、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。

虽然通过实施例描绘了本申请，本领域普通技术人员知道，本申请有许多变形和变化而不脱离本申请的精神，希望所附的权利要求包括这些变形和变化而不脱离本申请的精神。