该第二 RSS队列进行数据包接收及处理的过程。根据该第一实例中至少一个待迁移负载在共享资源池中所对应的协议控制块PCB在该第二实例中重建该至少一个待迁移负载具体实现为:根据该第一实例的至少一个待迁移负载之第二负载在该共享资源池中所对应的第二 PCB在该第二实例中实现该第二负载与该用户态协议栈的上层服务的对接以使得该第二实例实现与该第二负载对应的应用app的交互，并在该第一实例中解除该第二负载在该第一实例中绑定的第二 RSS队列，在该第二实例中将该第二 RSS队列绑定到该第二负载中，以使得该第二实例实现从该第二 RSS队列进行数据包接收及处理的过程。
[0030]结合第二方面的第十种可能的实现方式或第二方面的第i^一种可能的实现方式，在第十二种可能的实现方式中，在用于确定该第一实例中的至少一个待迁移负载的过程中，该确定单元具体用于:
[0031]确定该第一实例中的第三负载为该第一实例的待迁移负载，该第三负载在该第一实例中所绑定的第三RSS队列满足以下条件:该第三RSS队列的连接数、接收字节数、发送字节数3个参数中都达到该第一实例的所有负载中对应参数的均值。确定该第一实例中的至少一个待迁移负载具体实现为:确定该第一实例中的第三负载为该第一实例的待迁移负载，该第三负载在该第一实例中所绑定的第三RSS队列满足以下条件:该第三RSS队列的连接数、接收字节数、发送字节数3个参数中都达到该第一实例的所有负载中对应参数的均值。
[0032]基于以上技术方案，本发明实施例的并行用户态协议栈的管理方法和协议栈系统，通过根据异常实例中待迁移负载在共享资源池对应的PCB在具备迁入负载能力的实例中重建待迁移负载，能够克服协议栈共用一个分发模块带来的系统分发瓶颈，快速进行负载均衡和故障恢复，从而提高协议栈系统的性能。
【附图说明】
[0033]为了更清楚地说明本发明实施例的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
[0034]图1是本发明实施例并行用户态协议栈的管理方法流程图。
[0035]图2是本发明实施例并行用户态协议栈的另一管理方法流程图。
[0036]图3是本发明实施例故障线程恢复的流程示意图。
[0037]图4是本发明实施例线程负载均衡的流程示意图。
[0038]图5是本发明实施例线程负载均衡的另一流程示意图。
[0039]图6是本发明实施例协议栈系统的结构示意图。
[0040]图7是本发明实施例协议栈系统的另一结构示意图。
[0041]图8是本发明实施例协议栈系统的再一结构示意图。
【具体实施方式】
[0042]下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。
[0043]为了方便理解本发明实施例，首先在此介绍本发明实施例描述中会引入的几个要素。
[0044]用户栈与内核栈:内核在创建进程/线程的时候，会为进程/线程创建相应的堆栈。每个进程/线程会有两个栈，一个用户栈，存在于用户空间，一个内核栈，存在于内核空间。当进程/线程在用户空间运行时，CPU堆栈指针寄存器里面的内容是用户堆栈地址，使用用户栈；当进程/线程在内核空间时，CPU堆栈指针寄存器里面的内容是内核栈空间地址，使用内核栈。
[0045]用户态协议栈:协议栈是操作系统的网络处理部分通常都会包含的模块。当与网络处理部分相关的进程/线程在用户空间运行时，CPU堆栈指针寄存器指向的协议栈即为用户态协议栈，本发明实施例中，用户态协议栈指在用户空间运行的所有协议栈的集合。
[0046]连接数:连接的数量。连接作为CPU负载的最终载体，具有直观意义。而且，接收端(Recv)接收到数据时需要进行连接查找，进而转入连接状态处理，因此考虑平衡各协议栈线程连接数量，对优化查找速度也很有意义。
[0047]接收字节数(Recv Bytes):接收端扩展(Receive Side Scaling,RSS)本身主要是针对Recv端的分组发送(Packets dispatch),因此接收包的数据量很能反映对协议栈线程负载的影响。
[0048]发送字节数(Send Bytes):发送分组(Send Packets)由于受到Recv数据与连接亲和性关系的影响，也影响协议栈处理相关连接的Send负载。
[0049]图1是本发明实施例并行协议栈的处理方法流程图，图1的方法由协议栈系统执行。
[0050]101，监控用户态协议栈中每个协议栈对应的实例的运行状态。
[0051 ] 其中，一个该实例对应于该用户态协议栈中的一个协议栈。
[0052]应理解，本发明实施例中，实例可以是协议栈系统内的一个进程或一个线程。内核在创建进程/线程的时候，会为进程/线程创建相应的堆栈。每个进程/线程会有两个栈，一个用户栈，存在于用户空间，一个内核栈，存在于内核空间。
[0053]应理解，本发明实施例中，用户态协议栈用于表示存在于用户空间的所有协议栈。在用户态协议栈中，可包含一个或多个协议栈，每个协议栈与协议栈系统的一个实例形成一一对应的关系。
[0054]应理解，本发明实施例中，实例的运行状态包括实例的负载状态和存活状态。
[0055]应理解，实例的负载状态是指当前实例对系统资源的占用情况，通常情况下指该实例对CPU的资源利用率。
[0056]102，确定第一实例和第二实例。
[0057]其中，第一实例为运行状态异常的实例，第二实例该第二实例具备迁入该第一实例中至少一个待迁移负载的能力。
[0058]另外,一个该待迁移负载在该第一实例所对应的协议栈内对应于一个协议控制块PCB,该PCB在共享资源池中对应于一个存储着该待迁移负载的连接参数的PCB，该待迁移负载的连接参数能够用于重建该待迁移负载。
[0059]应理解，本发明实施例中，一个负载对应于一个PCB，一个负载在数据处理上等于一个PCB所对应的连接的数据处理量。
[0060]当一个实例被创建并初始化后，相应地会生成一个协议栈。如果实例内还不存在任何负载，则协议栈中也不会有PCB的信息。实例中有几个负载，其对应的协议栈中就会有相同个数的PCB。
[0061 ] 另外，本发明实施例中，协议栈只是存储着PCB的一些基本信息，例如PCB标识等。共享资源池中存储着PCB的关键数据结构，主要包括连接结构体信息，该连接结构体信息对快速响应恢复连接具有关键作用。
[0062]应理解，运行状态异常的实例，一般可包括存活状态异常的实例或负载状态异常的实例。
[0063]存活状态异常的实例可包括僵死或失效的实例。
[0064]负载状态异常的实例，可包括负载高位运行的实例。在判断实例是否是负载高位运行时，可通过比较一段时间内实例总负载均值与预定阈值的关系来确定实例是否处于负载高位运行状态。
[0065]103，根据该第一实例中至少一个待迁移负载在该共享资源池中所对应的协议控制块PCB在该第二实例中重建该至少一个待迁移负载。
[0066]本发明实施例中，根据异常实例中待迁移负载在共享资源池对应的PCB在具备迁入负载能力的实例中重建待迁移负载，能够克服协议栈共用一个分发模块带来的系统分发瓶颈，快速进行负载均衡和故障恢复，从而提高协议栈系统的性能。
[0067]图2是本发明实施例并行用户态协议栈的另一管理方法流程图。可选地，如图2所示，在步骤103之前，该方法还可包括步骤104:确定该第一实例中的至少一个待迁移负载。
[0068]可选地，步骤101具体可实现为:分别向该用户态协议栈中每个协议栈对应的实例发送心跳消息并监控该心跳消息响应时延，并监控该用户态协议栈中每个协议栈对应的实例在第一预定时间内的实例负载均值，以根据该心跳消息的响应时延和该实例负载均值确定该用户态协议栈中每个协议栈对应的实例的运行状态，其中，一条心跳消息对应于一个该实例；或者，分别轮询该用户态协议栈中每个协议栈对应的实例的实例标识，并监控该用户态协议栈中每个协议栈对应的实例在第一预定时间内的实例负载均值，以根据该实例标识和该实例负载均值确定该用户态协议栈中每个协议栈对应的实例的运行状态，其中，该实例标识用于表示实例的存活状态，该实例标识存储于共享内存区域或共享文件，一个该实例标识对应于一个该实例。
[0069]可选地，作为一个实施例，步骤102中确定第一实例具体实现为:确定距离发送心跳消息时刻达到第二预定时间后仍然未反馈心跳响应的实例为该第一实例；或者，确定第一预定时间内实例标识表示僵死或失效状态的实例为该第一实例。
[0070]在本实施例中，步骤102确定第二实例的过程具体可实现为:创建并确定新的实例为该第二实例。此时，步骤103具体实现为:根据该至少一个待迁移负载之第一负载在共享资源池中所对应的第一 PCB在该第二实例中实现该第一负载与该用户态协议栈的上层服务的对接，并将该第一负载在该第一实例中绑定的第一接收端扩展RSS队列重绑定到该第二实例的该第一负载中，其中，该至少一个待迁移负载包括该第一实例的所有负载。
[0071]可选地，作为另一实施例，步骤102中确定第一实例的过程具体实现为:确定第一预定时间内实例总负载均值大于第一预定阈值的实例为该第一实例。
[0072]可选地，在本实施例的一种具体实现方式中，步骤102中确定第二实例具体可实现为:如果存在第一预定时间内实例总负载均值低于第二预定阈值的实例，则确定预定时间内实例总负载均值低于第二预定阈值的一个或多个实例作为该第二实例，其中，迁入该第二实例的所有负载的负载值与该第二预定阈值之和小于该第一预定阈值。
[0073]进一步地，在当前的具体实现方式中，步骤103具体可实现为:根据该第一实例的至少一个待迁移负载之第二负载在该共享资源池中所对应的第二 PCB，将该第二负载在该第一实例中绑定的第二 RSS队列的绑定规则修改为绑定到该第二实例的第二负载中，以使得该第二实例实现从该第二 RSS队列进行数据包接收及处理的过程；或者，根据该第一实例的至少一个待迁移负载之第二负载在该共享资源池中所对应的第二 PCB，在该第一实例中解除该第二负载在该第一实例中绑定的第二 RSS队列，并在该第二实例中将该第二 RSS队列绑定到该第二负载中，以使得该第二实例实现从该第二 RSS队列进行数据包接收及处理的过程。
[0074]另外，在当前的具体实现方式中，步骤104具体可实现为:确定该第一实例中的第三负载为该第一实例的待迁移负载，该第三负载在该第一实例中所绑定的第三RSS队列满足以下条件:当该第三RSS队列绑定到该第二实例时该第二实例的连接数、接收字节数、发送字节数3个参数中至少有2个参数不大于该第一实例的相应参数。
[0075]可选地，在本实施例的一种具体实现方式中，步骤102中确定第二实例具体可实现为:如果不存在预定时间内实例总负载均值低于第二预定阈值的实例，则创建并确定新的实例为该第二实例。
[0076]进一步地，在当前的具体实现方式中，步骤103具体可实现为:根据该第一实例的至少一个待迁移负载之第二负载在该共享资源池中所对应的第二 PCB在该第二实例中实现该第二负载与该用户态协议栈的上层服务的对接以使得该第二实例实现与该第二负载对应的应用app的交互，并在该第一实例中解除该第二负载在该第一实例中绑定的第二RSS队列，在该第二实例中将该第二 RSS队列绑定到该第二负载中，以使得该第二实例实现从该第二 RSS队列进行数据包接收及处理的过程。
[0077]另外，在当前的具体实现方式下，步骤104具体可实现为:确定该第一实例中的第三负载为该第一实例的待迁移负载，该第三负载在该第一实例中所绑定的第三RSS队列满足以下条件:该第三RSS队列的连接数、接收字节数、发送字节数3个参数中都达到该第一实例的所有负载中对应参数的均值。
[0078]下面，将结合具体的实施例，对本发明实施例的方法作进一步的描述。下述具体实施例中，以协议栈线程作为用户态协议栈的实例进行描述。
[0079]图3是本发明实施例故障线程恢复的流程示意图。
[0080]在图3所示的场景中，用户态协议栈包含正在运行的应用所对应的多个协议栈。协议栈内协议控制块(Protocol Control Block, PCB)的关键数据结构存储于系统内存的共享资源池中。共享资源池在图3表现为协议控制块分配池(PCB Alloc)，存储着PCB的关键数据结构，主要包括连接结构体信息，可用于快速响应恢复连接。协议栈中，PCB作为表示连接的主要数据结构，因此可以将其作为协议栈工作负载的主要衡量指标。如图3所示，用户态协议栈可包括协议栈stackl、stack2和stack3。其中，stackl所对应的线程包括2个负载，其对应的PCB分别为PCBl和PCB4 ；