一种改善QUIC协议请求调度效率的方法与流程

本发明涉及一种网络请求调度技术，特别是涉及一种改善quic协议请求调度效率的方法。

背景技术

tcp协议是一个使用广泛的传输层协议，为上层应用提供了可靠的传输，tcp的连接通过源ip地址、源端口号、目的ip地址、目的端口号所构成的四元组确定一个连接，当客户端发生网络切换(例如从wi‐fi网络切换到4g网络)时该四元组必然会发生变更，这将导致tcp连接的重建，影响了通信的效率。而quic协议则是基于udp的应用层协议，相较于tcp通过四元组确定连接的方式，quic协议通过一个64‐bit的无符号整形值connectionid来确定一个连接。当客户端发送网络切换时，通过继续保持网络切换之前的connectionid，即可避免连接的重新建立，实现连接的平滑迁移，提高了通信的效率。目前移动网络设备使用广泛，网络切换的情况时有发生，连接平滑迁移的特性是极有意义的。

但是，由于实际应用中服务端常以服务器集群的形式存在，且服务器集群需要负载均衡设备将客户端请求调度到不同的服务器上，而目前正在被使用的软件地址转换负载均衡程序以ip地址的哈希结果作为调度的标准，使得网络切换前后的客户端请求极可能被调度到不同的服务器上进行处理，由于客户端与服务端的会话信息仅保留在具体处理请求的服务器上，因此该调度过程导致了quic协议连接平滑迁移的特性失效，这意味着该策略并不适用于quic协议的请求调度。

一种解决方案是全局同步并统一分配connectionid，但由于connectionid是一个需要频繁创建销毁的数据，该方案将造成较大的网络io开销，影响服务器集群的运行效率。另外，为了确保connectionid的唯一性，connectionid分配服务器也要缓存所有的已分配connectionid，并在分配前进行查找，分配时进行缓存，销毁时进行删除，由于整个服务器集群中connectionid数量较多，该过程所消耗的资源也较大。

另一种解决方案是给集群中每一台服务器分配一个静态的connectionid选择范围，通过保证该静态范围互不重叠来确保connectionid不发生冲突，但是由于服务端集群规模会动态变化，因而静态分配connectionid的选择范围会导致集群的可伸缩性受到影响。

技术实现要素：

本发明的目的在于克服现有技术存在的上述不足，提供了改善quic协议请求调度效率的方法。

本发明目的通过如下技术方案实现：

一种改善quic协议请求调度效率的方法，其方法具体包括如下步骤：

1)将范围为[0,2³²‐1]的整数集合构成一个一致哈希圆环空间，将服务器集群中的服务器以若干虚拟服务器节点的形式映射到该圆环上，每一个虚拟服务器节点的位置对应于圆环所表示范围中的一个整数点；

2)通过虚拟服务器节点在圆环的位置关系，确定虚拟服务器节点的动态有效控制范围；

3)通过服务器所对应的虚拟服务器的动态有效控制范围确定服务器的动态有效控制范围；

4)通过服务器的动态有效控制范围与connectionid的映射关系确定connectionid的动态选择范围；

5)对于任意请求，通过connectionid到圆环的逆向映射关系确定请求在圆环上的映射位置，在圆环上顺时针寻找具体处理请求的服务器，将请求调度到该服务器上。

进一步地，上述服务器集群具体是：一台以上的服务器主机通过网络通信实现的松散集成体，服务器集群协作完成计算工作，共同向客户端提供服务，以客户端的视角来看，其具体服务效果如同仅有单台主机在提供服务。

进一步地，上述范围为[0,2³²‐1]的整数集合构成一个圆环形状的空间具体是：设定一个圆环形状的空间，将范围为[0,2³²‐1]整数值在此圆环上按顺时针方向均匀递增分布，对于圆环上任意一点x+1必然为点x在顺时针方向上最临近的一个点，且点x+2与点x+1的距离必然和点x+1与x的距离相等，点2³²‐1的顺时针方向上最邻近的点为点0，且点2³²‐1与点0的距离和圆环上任意一点x+1与x的距离相等。

进一步地，上述通过虚拟服务器节点在圆环的位置关系，确定虚拟服务器节点的动态有效控制范围具体方法是：在[0,2³²‐1]的整数集合构成一个圆环形状的空间上，每一个虚拟服务器节点在其中占据一个圆环所表示范围中的一个整数点，对于任意虚拟服务器节点x，设其对应的整数值为nx，以其在圆环上的位置为起点，沿圆环逆时针方向移动，至遇到其他任一虚拟服务器节点y为止，设其点对应整数值为ny，则该虚拟服务器节点x的动态有效控制范围为(ny,nx]。

进一步地，上述通过服务器所对应的虚拟服务器的动态有效控制范围确定服务器的动态有效控制范围具体是：对于任意服务器s，设其在圆环上对应的虚拟服务器节点为s1、s2、……、sx，其中sn虚拟服务器节点的动态有效控制范围为rsn，则服务器s的动态有效控制范围为rs1∪rs2∪……∪rsx。

进一步地，上述通过服务器的动态有效控制范围与connectionid的映射关系确定connectionid的动态选择范围具体是：quic的connectionid为一个64‐bit长度的无符号整形值，取值范围为[0,2⁶⁴‐1]，对于圆环上的任意一点n，其可以映射出的connectionid的取值范围为[n×2³²,(n+1)×2³²‐1]，对于圆环上任意两点a、b且b>a，若服务器s的动态有效范围为[a,b]，则其对应的connectionid的动态选择范围为[a×2³²,(b+1)×2³²‐1]。

进一步地，上述通过connectionid到圆环的逆向映射关系确定请求在圆环上的映射位置，在圆环上顺时针寻找具体处理请求的服务器具体方法是：对于任意connectionid为c的连接而言，其在圆环上的映射点为(c+1)/2³²向下取整得出的结果，设该结果为n，则沿点n在圆环上的位置顺时针进行查找，遇到的第一个虚拟服务器节点所对应的服务器即为具体处理请求的服务器。

上述虚拟服务器节点具体是：服务器在一致哈希圆环上的映射点，一台服务器可以被映射为多个虚拟服务器节点，每一个虚拟服务器节点有且仅有一台服务器与之对应，对于任意服务器s而言，其在一致哈希圆环上映射出的虚拟服务器节点s1、s2、……、sn均可代表服务器s，也即被调度到某虚拟服务器节点上的请求由该虚拟服务器节点所对应的服务器进行处理。

与现有技术相比，本发明具有如下优点和技术效果：

1)本发明以connectionid为基准进行请求的调度，在服务端以服务器集群形式存在的情况下，确保了quic协议连接可以在客户端发生网络切换时平滑迁移。同时，本发明通过connectionid与一致哈希圆环范围的映射关系，动态确定了connectionid的选择范围，改善了quic协议请求调度效率。

2)相比于基于ip地址的哈希值进行quic请求调度的策略，本发明由于使用connectionid作为调度的基准，可以在服务端以服务器集群形式存在的情况下避免客户端网络切换时由于负载均衡调度的原因导致的连接平滑迁移失效的问题。

3)相比于通过某一台或某几台服务器对集群中所有服务器上的connectionid进行全局同步并统一分配的方法，在本发明中，connectionid仍然由具体处理请求的服务器负责创建、缓存和销毁，不会产生全局同步connectionid所造成的巨大网络io开销，也不会因为集中处理整个服务器集群中所有的connectionid所造成的性能压力。典型地，一次集群内部connectionid同步所造成的网络io的开销约为500000纳秒，而本地生成connectionid的开销仅约为100纳秒，相对该方案而言，本发明的connectionid选择方案能使请求的调度效率提升约500倍。

4)相比于通过给集群中每一台服务器分配一个静态的connectionid选择范围并由具体处理请求的服务器进行connectionid的创建、缓存和销毁的方法，在本发明中，connectionid的选择范围可以根据服务器集群的状态动态变化，避免了静态选择范围造成的对服务器集群可伸缩性的约束。

附图说明

图1为本发明所述一致哈希圆环的示意图；

图2为本发明确定connectionid选择范围的示意图；

图3为本发明中connectionid选择范围根据集群规模动态变化的示意图；

图4为本发明对客户端请求的调度示意图；

图5为本发明中负载均衡调度客户端请求的流程图；

图6为本发明服务器集群中实际处理请求的服务器处理请求的流程图。

具体实施方式

为更好地理解本发明，下面结合附图和实施方式对本发明作进一步的说明，但本发明的实施例方式不限如此。

为解决传统负载均衡设备导致的服务器集群环境下quic连接迁移失效的问题，同时避免由于connectionid全局同步分配造成的性能问题以及静态规定connectionid选择范围所造成的集群伸缩性受限的问题，以下提供一种改善quic协议请求调度效率的方法，通过connectionid到一致哈希圆环的映射以及服务器在一致哈希圆环上有效控制范围的到connectionid的映射实现了高效且动态地选择connectionid，并以此为基准进行请求的调度。

如图1所示，将范围为[0,2³²‐1]的整数集合中构成一个一致哈希圆环空间，集合中所有整数在圆环上沿顺时针方向按序排放，首位相连，均匀分布。对于任意n∈[0,2³²‐1)，其必出现于圆环的某个位置上，且n+1也必出现于圆环的某个位置上，且以n所在的位置为起点沿圆环顺时针方向查找遇到的第一个点必为n+1在圆环上的位置，且n所在的位置与n+1所在的位置之间的距离与0所在位置和1所在位置之间的距离相等。

如图2所示，假设服务器集群由s1、s2、s3三台服务器构成，每一台服务器分别对应范围为[0,2³²‐1]范围的一致哈希圆环上的三个虚拟服务器节点，虚拟服务器节点即服务器在一致哈希圆环上的映射点，一台服务器可以被映射为多个虚拟服务器节点，每一个虚拟服务器节点有且仅有一台服务器与之对应，对于任意服务器s而言，其在一致哈希圆环上映射出的虚拟服务器节点s1、s2、……、sn均可代表服务器s，也即被调度到某虚拟服务器节点上的请求由该虚拟服务器节点所对应的服务器进行处理。以服务器s2为例，其对应的虚拟服务器分别为s2_0、s2_1、s2_2，而这三个虚拟服务器节点的在圆环上的映射位置分别为n2_0、n2_1、n2_2，其对应的前一个虚拟服务器的位置分别为n1_0、n1_1、n1_2，那么，以n2_1位置的虚拟服务器为例，其在圆环上的有效控制范围为[n1_1+1,n2_1]，也就是说，被映射到这个范围内的请求会被交给s2处理。显然，对于服务器s2而言，其在圆环上的有效控制范围(在图中加粗的圆环区域)为：

ranges2＝[n1_0+1,2³²–1]∪[0,n2_0]∪[n1_1+1,n2_1]∪[n1_2+1,n2_2]

图2右侧为圆环的局部放大图，由于整个圆环上的每一个映射点都是取值范围为[0,2³²–1]的整数，且connectionid本身是一个64‐bit的无符号整形值，也就是取值范围为[0,2⁶⁴–1]，因此，对于圆环上的任意一点nx，它可以被映射为一个[nx×2³²,(nx+1)×2³²–1]的connectionid取值范围。对于虚拟服务器s2_1而言，其在圆环上的有效控制范围映射出的connectionid选择范围为[(n1_1+1)×2³²,(n2_1+1)×2³²–1]。显然，对于服务器s2而言，其在圆环上的有效控制范围映射出的connectionid选择范围为：

cidranges2＝[(n1_0+1)×2³²,2⁶⁴–1]∪[0,(n2_0+1)×2³²–1]∪

[(n1_1+1)×2³²,(n2_1+1)×2³²–1]∪[(n1_2+1)×2³²,(n2_2+1)×2³²–1]

由于每个服务器的有效控制范围是互不重叠的，显然，这种选择算法可以保证选择出来的connectionid的唯一性。而当一个新的服务器被添加进集群时，该服务器将以虚拟服务器的形式被映射到圆环上，而该映射将通过动态调整圆环上的虚拟服务器的有效控制范围达到动态调整connectionid的选择范围的目的。

如图3所示，当虚拟服务器节点sx_1被映射到圆环上时，其顺时针方向所遇到的第一个虚拟服务器节点(s2_1)的有效控制范围受到影响，从(n1_1,n2_1]缩减为(nx_1,n2_1]，相应地，s2_1的connectionid选择范围也从[(n1_1+1)×2³²,(n2_1+1)×2³²–1]缩减为[(nx_1+1)×2³²,(n2_1+1)×2³²–1]，s2_1对应的服务器s2上属于[(n1_1+1)×2³²,(nx_1+1)×2³²–1]范围的connectionid及其相关数据被迁移到sx_1对应的服务器sx上。此时，s2_1新的有效控制范围所映射出的connectionid选择区间上的所有connectionid都会被正确调度到对应服务器s2上而不会与sx_1的有效控制范围冲突。与虚拟服务器节点增加所造成的影响对应，当虚拟服务器节点sx被从圆环上删除时，s2_1将逆时针查找圆环上的虚拟服务器节点，当发现第一个虚拟服务器节点(s1_1)时，其connectionid选择范围将重新扩展为[(n1_1+1)×2³²,(n2_1+1)×2³²–1]。

如图4所示，当负载均衡设备接收到来自客户端的请求时，负载均衡设备将提取请求的connectionid并将请求映射到一致哈希圆环上。请求被映射到圆环上后，沿圆环顺时针方向移动，所遇到的第一个虚拟服务器节点所对应的服务器即为具体处理请求的服务器，负载均衡设备将该请求调度到该服务器上。

该调度流程具体如图5所示：

步骤501：负载均衡设备获取quic连接的请求数据；

步骤502：负载均衡设备通过quic包头中的connectionid项解析出请求的connectionid；

步骤503：负载均衡设备判断该请求是否为quic协议中的chlo(clienthello，客户端握手)报文，在quic协议中，connectionid在客户端与服务端握手前由客户端随机选择，在握手时服务端可以选择将其替换，为了确保connectionid在服务端的唯一性，服务端必须生成一个服务端中唯一的connectionid。在此处判断是否为chlo报文，可以判断该请求的connectionid是否为服务端生成；

步骤504：若请求为chlo报文，说明该请求的connectionid由客户端生成，为了避免客户端的恶意请求或是客户端的错误实现导致请求被集中调度到部分主机上，此处将请求随机映射到圆环上的任意一点；

步骤505：若请求不为chlo报文，说明该connectionid由服务端生成，根据connectionid的值逆向映射到圆环上。该逆向映射的具体为：设请求的connectionid为c，那么其在圆环上的对应点为也即对(c+1)/2³²的结果向下取整，这样的结果可以确保在圆环上找到对应的点。对于任意一个被调度到服务器s上的请求，由于其在圆环上的映射位置必然属于服务器s所对应的某个虚拟服务器节点的有效控制范围，而服务器s选择connectionid的范围也是在该范围内，确保了本次连接的connectionid更新后，该客户端的请求仍然能正确被调度到服务器s上；

步骤506：负载均衡设备确定请求在圆环上的位置后，沿顺时针方向查找虚拟服务器节点，选择第一个遇到的虚拟服务器节点，并将请求调度到该服务器上。

服务器集群中实际处理请求的服务器处理请求的流程如图6所示：

步骤601：服务器判断请求是否为chlo，根据请求是否为chlo，服务器可以判断一个请求的connectionid是否由服务器生成；

步骤602：若请求为chlo，说明connectionid由客户端生成，为确保connectionid在服务器的唯一性，需要由服务器生成一个在服务器唯一的connectionid，根据服务器对应的虚拟服务器节点在圆环上的有效控制范围的并集确定服务器的有效控制范围，根据服务器的有效控制范围映射出connectionid的选择范围，服务器在该范围内随机选择新的connectionid；

步骤603：为确保connectionid在服务器的唯一性，需要比对已经缓存的connectionid，若connectionid已经存在，需要重新生成；

步骤604：为确保connectionid在服务器的唯一性，本地缓存刚刚生成的connectionid，供之后查找；

步骤605：向客户端回送新的connectionid，在本次连接中，客户端后续的请求必须使用该新的connectionid；

步骤606：若请求不是chlo，说明connectionid由服务器生成，需要查找缓存中的connectionid，并确定与之对应的会话信息，以认证该connectionid的合法性并继续会话，若缓存中没有该connectionid，说明该connectionid已经失效，需要拒绝请求；

步骤607：会话结束后，需要从缓存中删除该connectionid，确保connectionid可以被之后的请求复用。

由上可见，本发明能够实现具有同样connectionid的quic协议客户端的请求被调度到同一台服务器上，确保了quic协议连接可以在客户端发生网络切换时平滑迁移。同时，本发明通过connectionid与一致哈希圆环范围的映射关系，动态确定了connectionid的选择范围，改善了quic协议请求调度效率。相比于通过某一台或某几台服务器对集群中所有服务器上的connectionid进行全局同步并统一分配的方法，在本发明中，connectionid仍然由具体处理请求的服务器负责创建、缓存和销毁，不会产生全局同步connectionid所造成的巨大网络io开销，也不会因为集中处理整个服务器集群中所有的connectionid所造成的性能压力。典型地，一次集群内部connectionid同步所造成的网络io的开销约为500000纳秒，而本地生成connectionid的开销仅约为100纳秒，相对该方案而言，本发明的connectionid选择方案能使请求的调度效率提升约500倍。相比于通过给集群中每一台服务器分配一个静态的connectionid选择范围并由具体处理请求的服务器进行connectionid的创建、缓存和销毁的方法，在本发明中，connectionid的选择范围可以根据服务器集群的状态动态变化，避免了静态选择范围造成的对服务器集群可伸缩性的约束，当服务器集群的规模扩张时，圆环上的虚拟服务器节点数量增加，动态缩减了圆环上已有虚拟服务器节点的有效控制范围，因而其对应服务器的connectionid的选择范围也动态减小，反之，当服务器集群的规模缩小时，圆环上的虚拟服务器节点数量减少，动态增加了圆环上剩余虚拟服务器节点的有效控制范围，因而其对应服务器的connectionid的选择范围也动态增大。