CN111512611B

CN111512611B - Mptcp感知的负载均衡器的设计方法和使用该设计的负载均衡器

Info

Publication number: CN111512611B
Application number: CN201780097858.6A
Authority: CN
Inventors: M·M·布德希科特; 曾怿竞
Original assignee: Nokia Technologies Oy
Current assignee: Nokia Technologies Oy
Priority date: 2017-12-22
Filing date: 2017-12-22
Publication date: 2023-04-04
Anticipated expiration: 2037-12-22
Also published as: EP3729785B1; EP3729785B8; EP3729785A1; US20200389403A1; CN111512611A; US11223565B2; WO2019125483A1

Abstract

MPTCP连接及其对应的TCP子流由负载均衡器朝向后端路由。每个MPTCP连接被路由到单个后端并且能够包括主TCP子流和辅TCP子流。路由包括响应于建立MPTCP连接的主TCP子流而执行连接的负载均衡以选择用于连接的后端。MPTCP连接及其TCP子流由负载均衡器追踪以将MPTCP连接及其对应的TCP子流路由到对应的选定后端。后端确定客户端建立MPTCP连接的主TCP子流的请求是否已经包括用于生成令牌的密钥，该令牌被用于从其他MPTCP连接中唯一地标识MPTCP连接。后端基于密钥生成令牌。后端使用令牌来区分用于MPTCP连接的后续通信。

Description

MPTCP感知的负载均衡器的设计方法和使用该设计的负载均衡器

技术领域

本发明总体上涉及诸如移动网络等无线网络中的核心网，并且更具体地涉及核心网中的多径传输控制协议(MPTCP)。

背景技术

该部分旨在提供以下公开的发明的背景或上下文。本文中的描述可以包括可以追求的概念，但是不一定是先前已经构思、实现或描述的概念。因此，除非本文中另外明确指示，否则本部分中描述的内容不是本申请中的描述的现有技术，并且不会由于包括在本部分中而被承认是现有技术。下面，在具体实施方式部分的主要部分之后，定义了可以在说明书和/或附图中找到的缩写。

随着移动应用的激增，移动数据业务继续呈指数增长。根据思科的预测，到2021年，全球每月的移动数据业务将是当前数量的四倍，达到49艾字节，占IP总业务的20％。参见2017年3月的思科的“Cisco Visual Networking Index:Global Mobile Data TrafficForecast Update, 2016–2021White Paper”。尽管部分原因是设备数目的增长，但是主要因素仍然是每移动设备生成的业务量。

为了支持这种爆炸性的业务需求，研究人员已经在各个方向上投入了大量的精力。两个主要方向是蜂窝技术和WiFi(一种与基于IEEE 802.11标准的设备进行无线局域网联网的技术；Wi-Fi是Wi-Fi联盟的商标)技术，因为当今的移动设备通常具有蜂窝接口和WiFi接口两者。蜂窝技术的新热门话题包括大规模MIMO和毫米波；下一代 WiFi中将包括的有前途的技术包括上行链路MU-MIMO、OFDMA等。在这两个方向之上，实际上还有一个更重要的方向，即蜂窝网络和WiFi网络的融合。尽管距离将这两个网络统一在一起还很遥远，但是同时利用异构技术(例如，WiFi和蜂窝)而不是一次使用一个接口已经成为可能。

可以同时利用移动设备的多个接口的有前途的技术之一是多径 TCP(MPTCP)协议。尽管该协议最初是在数据中心环境中提出的，但是MPTCP协议非常适合于提高具有多个无线电的移动设备的聚合带宽。先前的工作表明，MPTCP协议可以聚合在不同频谱处工作的各种接口的带宽并且为移动客户端提供巨大的容量。参见2015年的 IEEE的2015IEEE国际研讨会的第82–93页的动态频谱接入网 (DySPAN)中的L.Hartung和M.Milind的“Policydriven multi-band spectrum aggregation for ultra-broadband wirelessnetworks”。

除了其良好的聚合性能，使MPTCP充满希望的另一原因是，其设计具有被广泛采用的潜力。在TCP/IP堆栈中，MPTCP位于普通 TCP协议之上并且在应用层的套接字接口之下。与多径有关的信令全部使用TCP选项字段来实现，并且MPTCP连接的每个子流只是普通的TCP流。当客户端与服务器之间的中间盒(例如，计算机系统) 不支持MPTCP时，该协议可以正常返回普通TCP。

然而，当前MPTCP协议仍然未被广泛部署。

发明内容

本部分旨在包括示例，而不旨在是限制性的。

在示例性实施例中，公开了一种方法，该方法包括由负载均衡器将多径传输控制协议(MPTCP)连接及其对应的传输控制协议(TCP) 子流朝向一个或多个选定后端路由，其中每个MPTCP连接被路由到多个后端中的单个后端并且能够至少包括主TCP子流和辅TCP子流，并且其中路由MPTCP连接包括响应于建立MPTCP连接的主TCP子流而执行MPTCP连接的负载均衡，以选择多个后端中的选择用于 MPTCP的选定的一个后端。该方法还包括由负载均衡器追踪MPTCP 连接及其对应的TCP子流以实现MPTCP连接及其对应的TCP子流到对应的选定后端的路由。

实施例的附加示例包括一种计算机程序，该计算机程序包括用于当计算机程序在处理器上运行时执行前述段落的方法的代码。根据该段落的计算机程序，其中计算机程序是包括计算机可读介质的计算机程序产品，计算机可读介质承载在其中被实施的计算机程序代码以供计算机使用。

一种装置的示例包括一个或多个处理器以及包括计算机程序代码的一个或多个存储器。一个或多个存储器和计算机程序代码被配置为与一个或多个处理器一起使该装置至少执行以下：由负载均衡器将多径传输控制协议(MPTCP)连接及其对应的传输控制协议(TCP) 子流朝向一个或多个选定后端路由，其中每个MPTCP连接被路由到多个后端中的单个后端并且能够至少包括主TCP子流和辅TCP子流，并且其中路由MPTCP连接包括响应于建立MPTCP连接的主TCP子流而执行MPTCP连接的负载均衡，以选择多个后端中的用于MPTCP连接的选定的一个后端；以及由负载均衡器追踪MPTCP连接及其对应的TCP子流以实现MPTCP连接及其对应的TCP子流到对应的选定后端的路由。

一种计算机程序产品的示例包括计算机可读存储介质，该计算机可读存储介质承载在其中被实施的计算机程序代码以供计算机使用。该计算机程序代码包括：用于通过负载均衡器将多径传输控制协议 (MPTCP)连接及其对应的传输控制协议(TCP)子流朝向一个或多个选定后端路由的代码，其中每个MPTCP连接被路由到多个后端中的单个后端并且能够至少包括主TCP子流和辅TCP子流，并且其中路由MPTCP连接包括响应于建立MPTCP连接的主TCP子流而执行 MPTCP连接的负载均衡，以选择多个后端中的用于MPTCP连接的选定的一个后端；以及用于通过负载均衡器追踪MPTCP连接及其对应的TCP子流以实现MPTCP连接及其对应的TCP子流到对应的选定后端的路由的代码。

在实施例的另一示例中，一种装置包括：用于通过负载均衡器将多径传输控制协议(MPTCP)连接及其对应的传输控制协议(TCP) 子流朝向一个或多个选定后端路由的部件，其中每个MPTCP连接被路由到多个后端中的单个后端并且能够至少包括主TCP子流和辅TCP子流，并且其中路由MPTCP连接包括响应于建立MPTCP连接的主TCP子流而执行MPTCP连接的负载均衡，以选择从多个后端中的用于MPTCP连接的选定的一个后端；以及用于通过负载均衡器追踪MPTCP连接及其对应的TCP子流以实现MPTCP连接及其对应的 TCP子流到对应的选定后端的路由的部件。

在实施例的示例中，公开了一种方法，该方法包括在通信系统中的后端处确定客户端建立多径TCP(MPTCP)连接的主传输控制协议(TCP)子流的请求是否已经包括用于生成令牌的密钥，该令牌被用于从其他MPTCP连接中唯一地标识MPTCP连接。该方法还包括由后端基于来自请求的密钥来生成令牌，以及由后端使用令牌来区分 MPTCP连接的后续通信。

一种装置的示例包括一个或多个处理器以及包括计算机程序代码的一个或多个存储器。一个或多个存储器和计算机程序代码被配置为与一个或多个处理器一起使该装置至少执行以下：在通信系统中的后端处确定客户端建立多径TCP(MPTCP)连接的主传输控制协议 (TCP)子流的请求是否已经包括用于生成令牌的密钥，该令牌被用于从其他MPTCP连接中唯一地标识MPTCP连接；由后端基于来自请求的密钥来生成令牌；以及由后端使用令牌来区分MPTCP连接的后续通信。

一种计算机程序产品的示例包括计算机可读存储介质，该计算机可读存储介质承载在其中被实施的计算机程序代码以供计算机使用。该计算机程序代码包括：用于在通信系统中的后端处确定客户端建立多径TCP(MPTCP)连接的主传输控制协议(TCP)子流的请求是否已经包括用于生成令牌的密钥的代码，该令牌被用于从其他MPTCP 连接中唯一地标识MPTCP连接；用于通过后端基于来自请求的密钥来生成令牌的代码；以及用于通过后端使用令牌来区分MPTCP连接的后续通信的代码。

在实施例的另一示例中，一种装置包括：用于在通信系统中的后端处确定客户端建立多径TCP(MPTCP)连接的主传输控制协议 (TCP)子流的请求是否已经包括用于生成令牌的密钥的部件，该令牌被用于从其他MPTCP连接中唯一地标识MPTCP连接；用于通过后端基于来自请求的密钥来生成令牌的部件；以及用于通过后端使用令牌来区分MPTCP连接的后续通信的部件。

附图说明

在附图中：

图1示出了当今的数据中心中的典型的负载均衡场景；

图2示出了MPTCP连接建立过程；

图3(包括图3(a)、图3(b)和图3(c))示出了通过负载均衡器的MPTCP连接建立过程，其中仅示出了每个子流中的初始两分组交换(参见图1)，并且图3(a)示出了主流建立，图3(b)示出了在辅流到达相同的负载均衡器的情况下的辅流建立，图3(c)示出了在辅流到达不同的负载均衡器的情况下的辅流建立；

图4示出了使用一致性哈希的令牌空间划分的示例；

图5(分为图5(a)、图5(b)和图5(c))示出了在示例性实施例中使用以实现实现的三种类型的线程以及线程、物理端口和内核NIC接口(KNI)之间的连接，其中图5(a)示出了VIP匹配线程，图5(b)示出了直通线程，图5(c)示出了转发线程；

图6是包括示例性负载均衡器和适合与本文中的示例性实施例一起使用的后端的通信系统的一部分的框图；

图7(分为图7(a)和图7(b))是在示例性实施例中由示例性负载均衡器执行以实现MPTCP感知的逻辑流程图，并且示出了根据示例性实施例的一种或多种示例性方法的操作、被实施在计算机可读存储器上的计算机程序指令的执行结果、由以硬件实现的逻辑执行的功能、和/或用于执行功能的互连部件；以及

图8是在示例性实施例中由示例性后端执行以实现MPTCP感知的逻辑流程图，并且示出了根据示例性实施例的一种或多种示例性方法的操作、被实施在计算机可读存储器上的计算机程序指令的执行结果、由以硬件实现的逻辑执行的功能、和/或用于执行功能的互连部件。

具体实施方式

词语“示例性”在本文中用来表示“用作示例、实例或说明”。本文中描述为“示例性”的任何实施例不必被解释为比其他实施例优选或有利。在具体实施方式中描述的所有实施例是示例性实施例，提供这些示例性实施例是为了使得本领域技术人员能够制造或使用本发明，而不是限制由权利要求书限定的本发明的范围。

为了便于参考，本公开内容被分为多个部分。

1.引言

如上所述，当前MPTCP协议仍然未广泛部署。原因之一是，其数据中心中的服务提供商的负载均衡器不是MPTCP感知的。最新的负载均衡器设计基于流的5元组来独立地决定哪个TCP子流去往哪个后端，因此可以将同一MPTCP连接的多个TCP子流转发到不同后端。

相比之下，本文中的示例性设计包括MPTCP感知的负载均衡器。我们致力于每单位时间处理分组的数目和易于部署方面实现高性能。牢记这两个设计原则，我们将MPTCP连接标识符(例如，密钥/令牌) 的生成过程移动到负载均衡器，并且将最新的负载均衡器设计中的单个连接追踪表扩展为示例性实施例中的两个连接追踪表：一个表用于普通TCP，另一表用于MPTCP。这些确保负载均衡器可以将同一MPTCP连接的多个TCP子流转发到同一后端。当存在多个负载均衡器时，在示例性实施例中，使用一致性哈希来划分MPTCP令牌空间以保证令牌的唯一性，并且每一个负载均衡器也可以计算令牌空间划分的结果，使得该负载均衡器知道任何其他负载均衡器的令牌范围。当子流到达不同的负载均衡器时，我们还在负载均衡器之间转发分组，从而避免了全局状态同步。

本文中的一个示例性贡献是提出了一种高性能且易于部署的 MPTCP感知的负载均衡器设计。我们还标识了特定于MPTCP感知的负载均衡器的一些独特的实现挑战。

本公开的其余部分组织如下。在部分2中，我们将介绍当今数据中心和MPTCP连接建立过程中的负载均衡的附加背景信息。我们在部分3中介绍示例性的MPTCP感知的负载均衡器设计，并且在部分 4中介绍可能的实现示例，在部分5中给出了一些结论性意见。

2.附加背景

该部分提供有助于解释示例性实施例的附加背景。

2.1数据中心中的负载均衡

图1示出了当今的数据中心中的典型的负载均衡场景。边缘路由器135使用等价多径(ECMP)跨负载均衡器140均匀地分发业务，示出了其中的两个负载均衡器140-1和140-2。负载均衡器140使用一致性哈希和连接追踪表150来确定要将流路由到其的后端130。后端130是向客户端110提供某种类型的服务(诸如提供视频、应用或其他服务)的服务器。示出了四个后端130-1、130-2、130-3和130-4。客户端是用户设备110。用户设备110通过诸如互联网等网络与边缘路由器135通信。传入流115穿过边缘路由器135，并且在该示例中，到达负载均衡器140-1并且到达后端130-1。返回流120直接去往边缘均衡器140，而不经过负载均衡器140。路由通告125从两个负载均衡器140-1、140-2发送到边缘路由器135(例如，使用虚拟IP，即 VIP)。

服务提供商通常只有一个公共IP地址(每数据中心)(客户端通过DNS知道该公共IP地址)，该公共IP地址也称为服务的虚拟 IP(VIP)。然而，为了实现高可用性，大量后端130同时服务于传入流115。因此，负载均衡器140被配置在边缘路由器135与后端池之间。每个负载均衡器140向边缘路由器135通告(附图标记125) 具有相同成本的到VIP的路由，使得到该VIP的传入流115使用ECMP 跨所有负载均衡器135均匀地被分发。然后，负载均衡器决定传入流 115去往哪个后端并且将分组转发到所决定的后端130。对于由5元组175标识的新的传入流115，负载均衡器通常在5元组上使用一致性哈希以决定分组被转发到哪个后端并且向其连接追踪表150添加条目。在以下已知流的分组的情况下，将基于连接追踪表中的信息来转发分组。例如，负载均衡器140-1具有连接追踪表180-1，该连接追踪表180-1包括单个示例性条目<5元组175-1，后端id 170-1>，其示出了将传入流115路由到负载均衡器140-1以路由到后端130-1(具有后端id 170-1)。负载均衡器140-2具有连接追踪表180-2，该连接追踪表180-2包括单个示例性条目<5元组175-2，后端id 170-2>，其示出了将另一传入流115路由到负载均衡器140-2以路由到具有后端 id 170-2的后端130的另一可能性，尽管没有示出通过负载均衡器 140-2路由的流。对于返回业务，最新的设计通常支持直接服务器返回(DSR)，即，返回业务直接去往边缘路由器135，而无需通过负载均衡器140，这使得服务大量流成为可能。参见返回流120。在这种情况下，我们可以将负载均衡器视为层4路由器，它们不会拆分层 4连接。

2.2MPTCP连接建立

MPTCP是使用在RFC6824中标准化的TCP选项的TCP协议的扩展。参见2013年1月的RFC 6824的A.Ford、C.Raiciu、MJ Handley 和O.Bonaventure的“TCP Extensions forMultipath Operation with Multiple Addresses”。MPTCP连接通常包含若干子流，每个子流是普通TCP流。因此，MPTCP是层4协议，其位于TCP协议之上并且在应用层之下。

图2示出了利用多个TCP子流成功地在客户端/主机A110与服务器/主机B 210之间建立MPTCP连接的过程。为了易于说明，服务器/主机B 210可以被认为是后端130，并且边缘路由器135和负载均衡器140未示出。如下所述，使用3次握手来建立主流(参见附图标记250)并且交换64位密钥。使用4次握手完成认证过程以添加辅流 (参见附图标记260)。令牌B＝SHA-1(密钥B)在服务器侧(具有地址B 240)是唯一的以标识MPTCP连接。HMAC-A＝HMAC(密钥＝密钥A+密钥B，Msg＝R-A+R-B)，HMAC-B＝HMAC(密钥＝密钥 B+密钥A，Msg＝R-B+R-A)。R-A和R-B是随机数。

首先，经由具有MP_CAPABLE选项的3次握手建立主流，在此期间，交换两侧的64位密钥。3次握手如下：步骤1， SYN+MP_CAPABLE(密钥A)(例如，指示客户端110想要建立 TCP流并且支持MPTCP，并且指示要在客户端侧使用以创建令牌的密钥密钥A)；步骤2，SYN/ACK+MP-CAPABLE(密钥B)(例如，指示服务器210准备建立MPTCP连接，并且指示要在后端侧使用以创建TCP应当与之相关联的令牌的密钥)；以及步骤3， ACK+MP_CAPABLE(密钥A，密钥B)。注意，这些地址用于主机 A/客户端110的地址A1 220-1，并且主机B/服务器的地址为地址B240。然后，为了向该MPTCP连接添加辅流，客户端110发送(参见步骤4)具有令牌b的SYN MP_JOIN分组。令牌B是密钥B上的SHA1 哈希的最高有效32位，并且它在服务器侧唯一地标识该MPTCP连接。之后，又有三个分组以完成认证过程以建立辅流。具体地，传送以下信息：步骤5，SYN/ACK+MP_(HMAC-B，R-B)；步骤6， ACK+MP_JOIN(HMAC-A)；步骤7，ACK+MP_JOIN(HMAC-A)。

在数据中心的上下文中，相同的MPTCP连接的所有TCP子流都需要去往相同的后端，以便充分利用MPTCP。但是，很明显，在第 2.1部分的负载均衡器设计中不能保证满足该要求。

3.MPTCP感知的负载均衡器设计示例

在该部分中，我们提出了MPTCP感知的负载均衡器的示例性设计。我们从设计原则、假定和约束开始。接下来，我们考虑只有一个负载均衡器的简单情况，然后将设计扩展到我们具有多个负载均衡器的情况。最后，我们解决一些特殊问题，并且总结设计的优缺点。

3.1原理、假定和约束

设计原理：在示例性设计中，我们旨在实现高分组处理速度和部署便利。

设计假定：我们假定客户端具有多个接口/IP地址并且服务提供商每客户端已知的服务仅具有一个VIP地址和端口号。

约束：基于这些设计原理和假定，我们对设计空间具有以下约束。我们的设计不能修改传统的TCP协议，只能对MPTCP协议进行最小修改。然而，对客户端的配置没有任何限制，但是仅对服务提供商的网络配置进行最小的修改是可能的。我们还需要支持DSR和多个负载均衡器。最后，当后端或负载均衡器增加或减少时，只有很小的中断是可以容忍的。

3.2仅一个负载均衡器的情况

我们通过解决以下三个问题来提出示例性设计。在不失去我们的设计通用性的前提下，下文中我们仅考虑(MP)TCP业务。

1)谁生成密钥B/令牌B？在不考虑负载均衡器的情况下，后端生成密钥B/令牌B。但是，由于令牌用于标识MPTCP连接，鉴于后端数目通常很大，因此在负载均衡器处更容易保证其唯一性。此外，在DSR中，如果后端生成具有密钥B的SYN/ACK，则负载均衡器无法看到它，这会引入大量开销。具体地，将需要机制来确保负载均衡器在正常操作期间以及在发生故障时始终针对所有MPTCP会话一致地接收/提取密钥B。因此，我们将密钥/令牌生成功能移动到负载均衡器。该方法的一个示例性优点是，它不会引入任何新的选项字段，诸如MPTCP选项字段。

2)如何向后端通知选定密钥B？回想一下，用于建立主流的3 次握手中的第三分组是具有密钥A和密钥B两者的ACK MP_CAPABLE分组。因此，我们决定将由负载均衡器选择的密钥B 背载到类似于ACK MP_CAPABLE分组的MP_CAPABLE选项字段中。如前所述，该方法不会引入任何新的MPTCP选项字段。注意到，该方法需要对MPTCP服务器侧代码进行少量修改以提取密钥B，并且负载均衡器需要重新计算TCP报头校验和。

3)如何确保辅子流去往相同的后端？在示例性实施例中，我们保持两个连接追踪表，一个用于普通TCP连接，另一个用于MPTCP 连接。普通TCP连接追踪表定义为<5元组，(后端id，令牌B)>，而MPTCP连接追踪表定义为<令牌B，(后端id，密钥B)>。当主流到达时，我们分配唯一的密钥/令牌，并且通过在主流的5元组上使用一致性哈希来决定主流去往哪个后端。在示例性实施例中，我们向每个表添加一个条目以记录必要的信息。然后，当辅流到达时，我们使用SYN MP_JOIN分组中的令牌来查找MPTCP连接追踪表，以找到辅流去往的后端，并且向普通TCP连接追踪表添加条目以记录这个决定。

图3(包括图3(a)、图3(b)和图3(c))示出了用于MPTCP 建立、路由和追踪的示例性过程。图3(a)示出了主流建立。图3(b) 示出了在辅流到达相同的负载均衡器的情况下的辅流建立。下面参考多个负载均衡器的情况描述图3(c)。在这些图中，负载均衡器340 是负载均衡器340-1和340-2，并且为简单起见，边缘路由器135未示出，但是预期其在大多数系统中。在图3(a)中，客户端110向负载均衡器340-1发送(步骤10)SYN MP_CAPABLE(密钥A)分组，作为建立传入流115的请求。作为响应，负载均衡器340-1创建TCP 表(tbl)380，该TCP表380具有与主流115相对应的单个条目381-1，其包括5元组1 375-1(例如，唯一地标识该TCP子流)、后端130-1 (backend_1 370-1)的ID 370-1、和令牌b 392-1。负载均衡器340-1 还创建具有单个条目391的MPTCP表390，其包括令牌b 392-1、后端130-1(backend_1 370-1)的ID 370-1、和密钥b 391。条目391对应于MPTCP连接321，此时它仅包括子流115(对应于条目381-1)。在步骤11中，负载均衡器340-1将SYN+MP_CAPABLE(密钥A，密钥B)的分组作为传入流115的一部分发送到后端130-1。在步骤 12中，后端130-1直接向客户端110发送返回流(例如，使用DSR) 120。

对于图3(b)，该图示出了在辅流请求到达相同的负载均衡器的情况下的辅流建立。在该示例中，辅流116源自地址A1 220-2，并且客户端向负载均衡器340-1发送(步骤13)SYN+MP_JOIN(令牌B， R-A)分组(建立辅子流的请求)，负载均衡器340-1在步骤14中利用子流116向后端130-1发送SYN+MP_JOIN(令牌B，R-A)分组。响应于该分组，负载均衡器340在TCP表380中创建条目381-2，包括5元组2 375-2(例如，唯一地标识该TCP子流)、backend_1ID 370-1 和令牌b 392-1。在步骤15中，后端130-1使用SYN/ACK+MP_JOIN (HMAC-B，R-B)分组来响应于客户端110。MPTCP连接321包括子流115(对应于条目381-1)和子流116(对应于条目381-2)。

对于主流115或辅流116的以下分组，即，在初始主流115或辅流116被建立之后，负载均衡器140-1查找普通TCP连接追踪表380 以获取后端id 370-1和令牌b 392-1，然后仅出于更新该条目的上次使用时间的目的而使用令牌392-1来查找MPTCP连接追踪表390。下面描述使用时间来执行该更新的示例。

3.3多个负载均衡器的情况

单个负载均衡器的示例性设计可以扩展为支持多个负载均衡器。在图3(c)的一个示例中示出了多个负载均衡器的情况。也就是说，图3还包括图3(c)，图3(c)示出了在辅流到达不同的负载均衡器的情况下的辅流建立。在这种情况下，辅流116对应于客户端110 的地址A2，并且客户端110向负载均衡器340-2发送SYN+MP_JOIN (令牌B，R-A)。负载均衡器340-2然后创建具有单个条目311的 TCP表310，包括5元组2 275-2、负载均衡器340-1的ID315(例如， MAC地址或IP地址)、loadbalancer_1 315和空320条目。

与以上描述类似，通过解决三个问题来提出该设计。

1)负载均衡器是否需要知道其他负载均衡器生成的密钥/令牌？如果所分配的密钥/令牌信息可用于所有负载均衡器，则生成唯一的新密钥/令牌的过程非常简单。例如，可以简单地随机生成密钥并且检查其对应令牌是否在MPTCP连接追踪表中，例如在图3中的表390中。然而，使所分配的密钥/令牌信息可用于所有负载均衡器实际上可能会非常昂贵，因为它需要全局同步。先前工作的经验表明，应当避免全局同步。参见以下内容：2013年的ACM的ACM SIGCOMM计算机通信评论的第43卷的第207-218页中的P.Patel等人的“Ananta:Cloud scale load balancing”；以及2016年的NSDI的第523-535页的D.E. Eisenbud等人的“Maglev:A fast and reliable software network load balancer”。因此，在示例性实施例中，负载均衡器不知道在我们的设计中其他人分配了哪个密钥/那些令牌(尽管负载均衡将知道指派给其他负载均衡器但未由其分配的令牌范围)。

2)如何确保所生成的密钥/令牌在多个负载均衡器之间是唯一的？在不知道其他负载均衡器的所分配的密钥/令牌的情况下，在示例性实施例中，我们仍然可以通过将令牌空间划分为非重叠子空间来保证唯一性，并且每个负载均衡器只能生成其对应令牌落入其自身子空间中的密钥。为了在负载均衡器增加或减少时具有最小中断，我们仍然可以应用一致性哈希的思想来划分令牌空间。例如，我们可以在负载均衡器340的IP地址上使用哈希函数来将它们映射到令牌空间上，并且要求每个只能生成落入其右侧的令牌。

图4示出了该思想，并且示出了使用一致性哈希的令牌空间划分的示例。本示例具有三个负载均衡器(LB)340：LB1 340-1；LB2 340-2；以及LB3 340-3。每个负载均衡器340只能生成其对应令牌落入其自己的子空间中的密钥，例如，在该图中每个LB的右侧。注意到，如果密钥不满足要求并且生成有效密钥的平均尝试次数大约等于负载均衡器的数目，则负载均衡器340需要重新生成密钥。

更具体地，图4示出了在多个负载均衡器340之间的令牌空间的划分(例如，图2中的密钥密钥B的SHA_1哈希的32位)。由于，令牌在该示例中可以仅为32位，因此(2³²-1)是最大值，并且所以0 到(2³²-1)指示MPTCP令牌号空间。当您有多个负载均衡器时，需要在那些多个负载均衡器之间划分令牌空间，其中每个LB 340仅处理令牌子集。

这里是一种示例方式。假定负载均衡器LB₁，LB₂...LB_n具有IP地址IP₁，IP₂，...，IP_n。将这些地址哈希为范围R＝(0 to(2³²-1))上的值 key₁，key₂，key₃，...，key_n。因此LB_i的地址为IP_i。hash_32(IP_i)＝key_i。将key_i映射到圆。现在，指派给LB_i的范围R的子范围如下：如果您站在key_i上，看向圆的中心，则在观察者的右边并且直到其右手侧上的最近邻的的所有值被指派给与key_i相对应的负载均衡器。

在图4所示的示例中，每个LB 340将获取连续的子范围。利用该方案，指派给每个LB的连续子范围具有不同长度，并且可能不均匀。例如，LB₁ 340-1具有子范围420-1，并且已经生成由位置1 410-1 和4 410-4表示的实际令牌值，LB₂ 340-2具有子范围420-2，并且已经生成由位置2 410-2和5 410-5表示的实际令牌值，并且LB₃ 340-3 具有子范围420-3，并且已经生成由位置3 410-3和6 410-6表示的实际令牌值。还存在可以使范围均匀，并且如果需要的话也可以使范围不连续的其他一致性哈希方案。

此外，注意到在图4中，圆圈在整个令牌空间上的位置410表示实际令牌值。圆圈中的数字1-6(410-1至410-6)从全局视图中示出了所生成的令牌的顺序。

3)如何确保到达不同负载均衡器的子流去往相同的后端？假定如图3(a)所示建立主流。然后，负载均衡器1 340-1知道该MPTCP 连接(主子流115)去往哪个后端，并且令牌b392-1位于负载均衡器1的令牌子空间内。如果辅子流116如图3(c)所示去往负载均衡器2，则负载均衡器2 340-2基于该令牌b 392-1不知道该MPTCP连接去往哪个后端，但是负载均衡器2 340-2知道负载均衡器1 340-1 负责该令牌b 392-1(例如，通过使用以上参考图4描述的技术)。因此，负载均衡器2 340-2将该辅流116转发到负载均衡器1，并且负载均衡器1340-1可以将流转发到正确的后端(在该示例中为130-1)。负载均衡器2 340-2还向其普通TCP连接追踪表390添加条目391<5元组2，(负载均衡器1，空)>以记录该决定。注意，“空”表示无效令牌，并且负载均衡器可以被视为一组特殊后端。也就是说，后端是专用于同一服务的一组服务器。将负载均衡视为服务，并且因此负载均衡器是该服务的“后端”。

3.4需要注意的特殊分组

本部分描述了可能需要特别注意的某些分组。

关于重复的SYN MP_CAPABLE分组，可以从同一客户端接收重复的SYN MP_CAPABLE分组。在这种情况下，我们不应当分配新的密钥/令牌。相反，我们应当使用先前分配的相同密钥。这是我们将密钥b字段395保留在MPTCP连接追踪表390中的原因之一。

对于具有无效令牌的SYN MP_JOIN，在RFC6824(参见2013年 1月的RFC 6824的A.Ford等人的“TCP Extensions for Multipath Operation with Multiple Addresses”)中，如果服务器接收到具有无效令牌的SYN MP_JOIN分组，则服务器将RST分组发送回客户端。然而，如果负载均衡器接收到其令牌在其令牌子空间内但在MPTCP连接追踪表390中找不到的SYN MP_JOIN分组，则我们决定静默地丢弃该分组以减轻负载均衡器的负担。

关于普通SYN分组，从先前已经尝试建立MPTCP连接的客户端 110接收普通SYN分组是可能的。在这种情况下，每个连接追踪表 380/390中仍然存在具有有效令牌390的条目。因此，我们应当检索该令牌392，将TCP连接追踪表中的条目的令牌字段修改为“空”并且去除MPTCP连接追踪表390中的条目391。

关于FIN、RST、MP_FASTCLOSE、MP_FAIL分组，FIN、RST、 MP_FASTCLOSE分组标记(MP)TCP连接的结束，并且MP_FAIL 分组表示建立MPTCP连接的失败并且客户端110恢复到普通TCP协议。使用不同的机制在负载均衡器340处处理这些分组以去除两个连接追踪表380/390中的过时条目是可能的。然而，在示例性实施例中，这些分组没有被不同地对待，因为我们可能不能保证从负载均衡器340到后端130的传输将是可靠的。相反，在示例性实施例中，我们使用计时器来使两个连接追踪表380、390中的条目超时。作为示例，可以在将项的条目输入到表中时设置计时器。每次访问项时，计时器都会重置。关闭表中的项的指令会导致计时器停止使用。另一方面，如果计时器在没有这样的指令的情况下超时(例如，到期)，则表示可以将与MPTCP连接及其对应的TCP子流相对应的(多个)项从(多个)表中去除。

对于具有之前未见的5元组的Non-SYN分组，当TCP连接追踪表380变满时，或者当负载均衡器340增加或减少并且ECMP未在每连接的基础上使用一致性哈希实现(这导致了大量业务洗牌(shuffle)) 时，可能会发生这种情况。由于我们在5元组上使用一致性哈希来指派后端130，因此这确保了主流115仍将有很高的概率找到正确的后端。然而，我们主张为连接表380/390保留足够的空间，并且在每连接的基础上使用一致性哈希以在边缘路由器135处实现ECMP。

关于之前看到的5元组的ACK MP_CAPABLE和ACK MP_JOIN，在普通TCP流3次握手中，如果服务器接收到ACK分组，则认为建立了连接。然而，如图2所示，在服务器在未仔细解析选项字段的情况下接收到ACK MP_CAPABLE或ACK MP_JOIN的情况下假定正确建立了MPTCP连接是不安全的。特别地，对于ACK MP_JOIN，可能是如下情况：从客户端接收的HMAC-A与预期 HMAC-A不匹配，这可能是因为，客户端是恶意客户端或中间盒(例如，客户端与服务器之间的设备)重写分组。在这两种情况下，MPTCP 连接由于该认证失败而未能成功建立，并且到普通TCP的故障转移过程将在图2的步骤7中开始。类似地，对于ACK MP_CAPABLE，可能是如下情况，在步骤1中接收的密钥A与在步骤3中接收的密钥 A不匹配，或者在步骤3中接收的密钥B与负载均衡器生成的密钥B 不匹配。因此，如果要使用类似于在前面引用的ACM SIGCOMM计算机通信评论中的“Ananta:Cloud scale load balancing”的单独的表来处理可信和不可信流，则这两种分组需要特别注意。

3.5优势、技术效果和其他考虑因素

在不以任何方式限制下面出现的权利要求的范围、解释或应用的情况下，示例性实施例的一些示例性优点和技术效果包括以下中的一项或多项。据信，示例性设计可以实现高分组处理速度，例如，因为不存在需要在所有负载均衡器或后端之间紧密同步的状态信息。另外，由于可以使用一致性哈希将令牌空间划分为非重叠的子空间，因此当负载均衡器增加或减少时，可能只有很小的中断。而且，因为可以在5元组上使用一致性哈希来使主流115决定MPTCP连接去往哪个后端130，所以即使存在大量业务洗牌，负载均衡器340仍然可以以高概率找到正确的后端130以用于主流115。附加地，该设计不会引入任何新的IP选项、TCP选项或MPTCP子选项。

其他考虑因素如下。某些示例性设计是有状态的，并且使用两个连接追踪表。因此，在这些示例性实施例中，我们必须在负载均衡器上为两个表而不是为一个表保留更多的存储器。然而，对于我们的负载均衡器的软件实现，我们并不认为存储器需要成为主要的成本或复杂性问题，而由此带来的优势(例如，无需全局同步)远远超过了额外的存储器需求。此外，当有多个负载均衡器时，可能需要尝试若干次才能获取有效的新密钥/令牌，这需要大量的计算。尽管生成密钥/ 令牌可能会占用大量计算资源，并且在负载均衡器之间重定向分组会引入附加延迟，但它仍然远远小于使用全局同步机制引入的延迟。此外，当存在大量业务洗牌时，辅流116可能无法以高概率找到正确的后端。然而，利用正确的ECMP实现，应当不会造成大量业务洗牌。最后，由于如果流到达的负载均衡器与主流不同，我们会在负载均衡器之间重定向辅流116，因此我们向辅流增加了附加延迟。然而，我们认为，带来的延迟是微不足道的，因为该延迟表示传统IP路由中的附加转发跳。

4.可能的实现示例

在本部分中描述关于实现的附加考虑因素和实现的一些示例。

4.1附加考虑因素和实现方面。

以下是在先前的工作中没有明确说明或特定于这些示例性的 MPTCP感知的负载均衡器设计的考虑因素。

关于内核与内核旁路，先前的工作已经表明，就其每单位时间可以处理的分组数目而言，与使用Linux内核相比，使用内核旁路可以显著提高负载均衡器的性能。参见2016年的NSDI中的第523-535页的D.E.Eisenbud等人的“Maglev:A fast and reliablesoftware network load balancer”。内核旁路处理用户空间处的层2分组，并且与以太网接口的驱动器通信，而无需通过内核。因此，一种可能的实现可以使用由英特尔和其他公司提供的被称为数据平面开发套件(DPDK) 的开源内核旁路平台。参见数据平面开发套件，网址为 www.dpdk.org/。然而，可能还需要利用内核来处理某些控制平面业务，例如VIP路由通告。另一示例是，并非所有负载均衡器和后端都在同一内联网中。这可能需要我们实现层3转发而不是层2转发。在这种情况下，负载均衡器还管理路由表和ARP表两者，如果仅通过内核旁路来实现这些功能，则可能导致行头阻塞。幸运的是，DPDK提供了内核NIC接口以将层2分组从用户空间发送回内核。

关于连接追踪表条目到期，普通负载均衡器设计不要求连接追踪表中的条目及时到期，因为如果表变满，这几乎没有负面影响。因此，可以通过最近最少使用(LRU)哈希表来实现连接追踪表。在LRU 哈希表中，存在固定数目的桶，并且每个桶可以支持固定数目的密钥。在查找密钥或添加新密钥时，该桶中的条目将重新排序，以便该顺序反映最近使用过的条目。因此，仅当将新密钥添加到已达到其最大密钥数的同一桶时，该条目才会被去除，并且该条目是最近最少使用条目。然而，LRU哈希表可能无法支持MPTCP连接追踪表。假定MPTCP 连接追踪表足够大，并且可以在运行足够长的时间后无需检索就分配负载均衡器的子空间中的所有密钥。这表示，该表不再支持新的 MPTCP连接。因此，可以使用可扩展哈希表来代替及时的条目超时支持。例如，如果在给定时间量内未查找表中的条目，则我们会将其标记为无效(例如，到期)。注意到，尽管我们使用及时条目到期支持，但实际上，调用表条目到期函数的频率明显小于表查找的频率。

对于在处理混合业务时表条目的优先级，在非MPTCP感知的负载均衡器设计中，连接追踪表条目的优先级大致相同。即使表已满， 5元组上的一致性哈希也可以保证负载均衡器仍然可以以较高概率找到正确的后端。然而，在示例性的MPTCP感知的负载均衡器设计中，我们认为，当处理普通TCP和MPTCP业务以及甚至其他类型业务(例如，UDP、SCTP)的混合时，即使在普通TCP连接追踪表中，与 MPTCP相关的条目也具有更高优先级。例如，如果普通TCP连接追踪表380已满，则当新的MPTCP主流到达时，分配新的密钥/令牌并且向MPTCP连接追踪表390成功添加条目，但是无法向普通TCP连接追踪表380添加条目是可能的。在这种情况下，尽管我们仍然可以保证主流115很有可能去往正确的后端，但是我们无法更新MPTCP连接追踪表390中的对应条目的最后有效时间，这导致即使后端仍在使用该密钥/令牌，也会去除该条目。也就是说，在查找条目时，条目的最后有效时间会更新。由于无法向TCP表添加条目，因此您无法从TCP表条目中获取令牌以查找MPTCP表。因此，永远不会查找 MPTCP表中的条目，并且无法更新最后的有效时间。负载均衡器与后端之间的这种不匹配可能会导致密钥/令牌冲突。解决该问题的一种方法是针对TCP表和MPTCP表中的一者或两者在固定大小的哈希表之上使用可扩展哈希表。

关于与多个负载均衡器相比的多个转发线程，多个转发线程对于非MPTCP感知的负载均衡器在概念上等效于多个负载均衡器。因此，以前的工作(参见2016年的NSDI的第523-535页的D.E.Eisenbud 等人的“Maglev:A fast and reliable software networkload balancer”) 利用多个转发线程来使每实例的性能最大化，并且使用多个实例来扩展负载均衡服务而没有任何困难。然而，对于MPTCP感知的负载均衡器设计，不会保持这种等效性。如果我们等效地对待多个转发线程和多个负载均衡器，则负载均衡器的令牌子空间可能是不连续的。如果负载均衡器340仅知道其他实例是否增加或减少而不知道特定实例内部的转发线程是被创建还是被杀死，则当负载均衡器内部的转发线程被创建或被杀死时，可能会有很大的中断。因此，在示例性实施例中，我们可以使用一致性哈希来实现层2令牌空间划分。在顶层，我们在多个负载均衡器之间划分令牌空间，而在底层，我们将负载均衡器的每个子空间分配给多个转发线程。

4.2附加实现方面

如上所述，连接追踪表380/390的实现可以使用及时的条目超时支持。原因是，如果不支持及时的条目超时，则在运行足够长的时间后，可能会分配负载均衡器的子空间中的所有令牌，而无需在MPTCP 连接追踪表390中进行检索。这表示，表390可能不再支持新的MPTCP连接。因此，如前所述的计时器可以用来去除(多个)表中被认为不再适用于有效的TCP子流或MPTCP连接的条目。

图5示出了用于实现示例性实施例的三种类型的线程以及线程、物理端口和内核NIC接口(KNI)之间的连接。图5(a)示出了VIP 匹配线程570-1，图5(b)示出了直通线程570-2，图5(c)示出了转发线程570-3。VIP匹配线程570-1从物理端口(端口RXQ 510) 的RX队列接收分组，并且对传入业务解复用，以便发往(多个)VIP 的分组经由软件队列SWQ 560去往转发线程570-3并且其他分组去往KNI(例如，KNI RXQ 520)。直通线程570-2从KNI接收分组，例如，VIP路由通告(参见KNI TXQ 520)，并且将其直接写入物理端口(例如，端口TXQ540)的TX队列。转发线程570-3经由软件队列SWQ 530接收分组，并且将分组发送到物理端口(例如，端口 TXQ 540)的TX队列(并且可能在发送之前对其修改)。

例如，在转发线程570-3中实现上述MPTCP感知的负载均衡逻辑示例。为了使每实例的性能趋向于或达到最大化，我们可以利用多个转发线程570-3。在这种情况下，如前所述，我们使用一致性哈希实现层2令牌空间划分。在顶层，我们在多个负载均衡器之间划分令牌空间，而在底层，我们将负载均衡器的每个子空间分配给多个转发线程。这个层2令牌空间划分的原因是，负载均衡器可能只能知道其他实例是否增加或减少而不知道特定实例内部的转发线程是被创建还是被杀死。结果是，如果我们等效地对待多个转发线程和多个负载均衡器，则在创建或杀死负载均衡器内部的转发线程时可能会造成很大的中断。

参考图6，图6是根据示例性实施例的包括示例性负载均衡器340 和后端130的通信系统的部分600的框图。负载均衡器340包括通过一个或多个总线657互连的一个或多个处理器652、一个或多个存储器655和一个或多个网络接口(N/W I/F)661。一个或多个存储器655 包括计算机程序代码653和表380/390。负载均衡器340包括负载均衡(LB)模块150，负载均衡(LB)模块150包括部分650-1和/或 650-2中的一者或两者，其可以以多种方式实现。LB模块650可以以硬件实现为LB模块650-1，诸如被实现为一个或多个处理器652的一部分。LB模块650-1还可以被实现为集成电路或通过诸如可编程门阵列等其他硬件来实现。在另一示例中，LB模块650可以被实现为LB模块650-2，LB模块650-2被实现为计算机程序代码653并且由一个或多个处理器652执行。例如，一个或多个存储器655和计算机程序代码653被配置为与一个或多个处理器652一起使负载均衡器 340执行本文中描述的一个或多个操作。一个或多个网络接口661诸如经由链路676和631通过网络进行通信。负载均衡器340经由链路 676与客户端110和边缘路由器135通信。负载均衡器340经由链路 631与后端(BE)130通信，其中示出了单个后端130。链路676和 631可以是有线的或无线的或两者，尽管通常使用有线来支持所需要的速度，并且可以实现适当的接口。一个或多个总线657可以是地址、数据或控制总线，并且可以包括任何互连机制，诸如母板或集成电路上的一系列线路、光纤或其他光通信设备、无线信道等。

后端130包括通过一个或多个总线617互连的一个或多个处理器 612、一个或多个存储器615和一个或多个网络接口(N/W I/F)621。存储器615包括计算机程序代码613、一个或多个密钥(例如，密钥 b 395)和一个或多个令牌(例如，令牌b 392)。后端130包括MPTCP模块610，MPTCP模块610包括部分610-1和/或610-2中的一者或两者，其可以以多种方式来实现。MPTCP模块610可以以硬件实现为 MPTCP模块610-1，诸如被实现为一个或多个处理器612的一部分。 MPTCP模块610-1也可以被实现为集成电路或通过诸如可编程门阵列等其他硬件来实现。在另一示例中，MPTCP模块610可以被实现为LB模块610-2，LB模块610-2被实现为计算机程序代码613并且由一个或多个处理器612执行。例如，一个或多个存储器615和计算机程序代码613被配置为与一个或多个处理器612一起使后端130执行本文中描述的一个或多个操作。一个或多个网络接口621诸如经由链路631通过网络进行通信。负载均衡器340经由链路676与客户端 110和边缘路由器135通信。一个或多个总线617可以是地址、数据或控制总线，并且可以包括任何互连机制，诸如母板或集成电路上的一系列线路、光纤或其他光通信设备、无线信道等。

参考图7，包括图7(a)和图7(b)，图7是在示例性实施例中由示例性负载均衡器执行以实现MPTCP感知的逻辑流程图。该图示出了根据示例性实施例的一种或多种示例性方法的操作、被实施在计算机可读存储器上的计算机程序指令的执行结果、由以硬件实现的逻辑执行的功能、和/或用于执行功能的互连部件。图7中的框被假定为至少部分由负载均衡器340在LB模块650的控制下执行。图7中的操作还部分地对应于已经在图3中示出的那些。例如，图7(a)示出了由图3(a)中的负载均衡器340-1执行的操作，图7(b)示出了由图3(b)中的负载均衡器340-1和图3(c)中的负载均衡器340-2执行的操作。

注意到，尽管在附图中，包括在图7中，仅描述了一个辅TCP 子流，但是可以有多个辅TCP子流。同样，可能存在没有MPTCP的“普通”TCP流，但是这些流在图7中未描述。为了保持一致性，还使用MPTCP下的TCP流的术语“子流”，因为MPTCP被认为是“流”，而TCP流是MPTCP连接321下的子流。根据先前附图中，负载均衡器340可以是负载均衡器340-1或负载均衡器340-2(或其他未示出的负载均衡器，但为简单起见，仅考虑这两个负载均衡器)。

框705和更高级别涉及主TCP子流或辅TCP子流和对应MPTCP 连接的初始建立、路由和追踪。一旦建立了TCP子流，并且还建立了TCP和MPTCP表，则根据TCP和MPTCP表来路由TCP子流的任何后续通信，诸如从负载均衡器340路由到对应后端130或者从一个负载均衡器路由到另一负载均衡器。例如，在框702中，负载均衡器340接收用于主TCP子流或辅TCP子流的通信。如果通信是针对当前已知的TCP子流(例如，在TCP和MPTCP表中)(框703＝现有流)，则在框704中，负载均衡器340根据TCP表380和MPTCP 表390将TCP子流路由到对应后端130或另一负载均衡器(LB)。对于主流，可以使用5元组(例如，唯一地标识TCP子流)来标识它是否是新的请求。对于辅流，可以使用令牌(例如，令牌b)。图 3还示出了针对新的TCP子流的请求的该路由，如图7的框747、770 和780一样。一旦建立了TCP子流，这些附图和框对于TCP子流 115/116的通信将是相似的。

还应当注意，虽然TCP表380和MPTCP表390是这样描述的，但是如果需要，可以将它们组合或以某种其他格式存储，诸如存储在存储器中的另一种类型的数据结构。

如果TCP子流的通信是对当前未知(例如，不在TCP或MPTCP 表中)的子流的新请求(框703＝新请求)，则流程图进行到框705，其中负载均衡器340接收对主或辅TCP流的请求。在框710中，负载均衡器340确定该请求是针对主TCP子流315还是辅TCP子流316。如果该请求针对主TCP子流115(框710＝主)，则流程图进行到框 715。如果该请求是针对辅TCP子流116(框710＝辅)，则流程图进行到框750。

图7(a) 中的框715至747示出了由图3(a)中的负载均衡器340-1 执行的操作，也可以参考图3(a)。在框715中，负载均衡器340 从客户端110接收建立TCP子流的请求，并且接收关于客户端支持 MPTCP的指示(例如，用于建立主TCP子流的3次握手的一部分)。还参见图3(a)中的步骤10。框720中的负载均衡器340执行负载均衡算法并且从多个后端130中选择后端。在框730中，负载均衡器 340将子流的唯一标识符(例如，5元组375)和选定后端以及为“空”的令牌(例如，当前为无效)插入TCP表380中。在表插入之前选择后端的一个原因是，无论该逻辑有什么问题(例如，TCP表中没有足够的空间)，都应当执行后端选择。在框735中，负载均衡器340 生成用于创建令牌(例如，令牌b 392-1)的密钥(例如，密钥b 395)，该令牌从其他MPTCP连接中唯一地标识MPTCP连接321。

在框740中，负载均衡器340使用密钥生成唯一令牌(例如，令牌b 392-1)并且将令牌与选定后端340和密钥395一起插入MPTCP 表中(框745)。在框745中，负载均衡器340将令牌与选定后端以及可能的密钥一起插入TCP表中。在流程的这一部分末尾更新TCP 表条目的令牌字段的一个原因是，如果密钥/令牌分配中存在错误，例如MPTCP表中没有足够的空间，则可以跳过更新TCP表条目的令牌字段。

在框747中，执行3次握手的(多个)附加部分以帮助与选定后端130-1建立主TCP子流315。参见例如图3(a)的步骤11。注意到，假定这结束流程图的这一部分。

如果请求是针对辅TCP子流116(框710＝辅)，则流程图进行到框750，如图7(b) 所示。图7

(b)中的框750至780示出了由图3(b) 和图3(c)中的负载均衡器340-1和340-2执行的操作，也可以参考这些图。

框750、755和760对应于两个图3(a)和图3(b)。在框750 中，负载均衡器340从客户端110接收建立辅TCP子流116的请求，并且接收对应MPTCP连接321的指示(例如，令牌B)。分别参见图3(b)或图3(c)的步骤13和16。在框755中，负载均衡器340 通过使用令牌空间划分(例如，使用一致性哈希)来确定该MPTCP 连接321是由该负载均衡器340还是由另一负载均衡器340来处理。参考图4和可能的令牌空间划分技术的对应文本。如果MPTCP连接321由该负载均衡器340处理(框760＝该LB)，则流程图进行到框 765，而如果MPTCP连接321由不同的负载均衡器340处理(框760＝不同的LB)，则流程图进行到框775。

如果MPTCP连接321在该负载均衡器340上(框760＝该LB)，则其对应于图3(b)以及框763、765和770。框763中的负载均衡器340使用令牌392在其MPTCP表390中查找并且获取该MPTCP 连接321的后端。在框765中，负载均衡器340将唯一地标识辅TCP 子流316(例如，5元组2 375-2)、标识后端(例如，backend_1 370-1) 以及唯一地标识MPTCP连接331(例如，令牌b 392-1)的信息插入到TCP表380(例如，参见条目381-2)中。在框770中，负载均衡器340将请求路由到所标识的后端，在这种情况下，为使用标识符 backend_1 370-1而确定的后端130-1。这包括执行4次握手的附加部分，以帮助与所标识的后端建立辅TCP子流。还参见图3(b)的步骤14。流程图的这一部分结束。

如果MPTCP连接321在不同的负载均衡器340上(框760＝不同 LB)，则流程图进行到框775。框775和780对应于图3(c)。在框 775中，负载均衡器340将唯一地标识辅TCP子流116、标识处理辅子流116的负载均衡器(例如，loadbalancer_1 315)、以及为空的信息插入到TCP表310中。在框780中，负载均衡器340将请求路由到处理辅子流116的负载均衡器，在图3(a)的示例中为负载均衡器 340-1。参见例如图3(c)的步骤7。流程图的这部分结束，但是假定负载均衡器340-1将在框705处接收请求，然后进行到框765和770。

参考图8，该图是在示例性实施例中由示例性后端130执行以实现MPTCP感知的逻辑流程图。该图还示出了根据示例性实施例的一种或多种示例性方法的操作、被实施在计算机可读存储器上的计算机程序指令的执行结果、由以硬件实现的逻辑执行的功能、和/或用于执行功能的互连部件。图8中的框被假定为由后端130执行，例如至少部分在MPTCP模块610的控制下。

在框805中，后端130经由负载均衡器340从客户端接收通信。后端130确定(框810)来自客户端的通信是否是用于与客户端建立 MPTCP连接321的主TCP子流115的3次握手的一部分。参见例如图1的步骤1或图3(a)的步骤11。如果通信不是3次握手的一部分(框815＝不是3次握手的一部分)，则后端130进行到框820，如下所述。

如果通信是3次握手的一部分(框815＝3次握手的一部分)，则流程图进行到框825。在框825中，后端确定通信是否包含来自客户端和负载均衡器两者的密钥。参见图2中的步骤1与图3(a)中的步骤11之间的区别。如果仅从客户端110接收到一个密钥(框830＝仅来自客户端的一个密钥)，则在框835中，后端130执行其正常的3 次握手处理，以在框835中生成密钥(例如，图2中的密钥B)并且基于该密钥生成令牌(例如，令牌b)(框835)，在框845中存储密钥和令牌(例如，在后续通信中使用令牌来识别该MPTCP连接的通信)，并且完成3次握手(框850)。也参见图1中的步骤2。另一方面，如果通信包含来自客户端和负载均衡器两者的密钥(框830＝两者)，则后端130不会生成密钥，因为负载均衡器340已经这样做。相反，执行框840，并且根据在请求中提供的密钥来生成令牌，在框 845中，存储密钥和令牌，并且完成3次握手(框850)。参见图3 (a)的步骤12。流程进行到框820。

在框820中，后端130执行正常处理。这样的操作可以包括在框 855中描述的那些操作，其中后续通信使用所存储的令牌以识别该 MPTCP连接，诸如在4次握手中，以建立辅流或将数据传送给客户端以用于MPTCP连接的主TCP流或辅TCP流。例如，将从客户端接收的令牌与所存储的令牌进行比较，以确定TCP子流和MPTCP连接状态并且相应地执行动作。

5.结论意见

在本文档中，我们介绍了MPTCP感知的负载均衡器的示例性设计，我们认为其具有高性能和可广泛部署的能力。结合MPTCP协议本身的向后兼容性和中间盒感知的设计，相信MPTCP将成为超宽带、超可靠、超低延迟5G移动和固定接入的关键技术。

以下是附加示例。

示例1.一种方法，包括：由负载均衡器将多径传输控制协议 (MPTCP)连接及其对应的传输控制协议(TCP)子流朝向一个或多个选定后端路由，其中每个MPTCP连接被路由到多个后端中的单个后端并且能够至少包括主TCP子流和辅TCP子流，并且其中路由 MPTCP连接包括响应于建立MPTCP连接的主TCP子流，而执行 MPTCP连接的负载均衡，以选择多个后端中的用于MPTCP连接的选定的一个后端；以及由负载均衡器追踪MPTCP连接及其对应的TCP 子流以实现MPTCP连接及其对应的TCP子流到对应的选定后端的路由。

示例2.根据示例1的方法，其中追踪还包括：对于到达负载均衡器的、针对MPTCP连接的辅TCP子流的请求，确定辅TCP子流正在由负载均衡器处理，并且将请求路由到与MPTCP连接相对应的选定后端。

示例3.根据示例1的方法，其中追踪还包括：对于到达负载均衡器的、针对MPTCP连接的辅TCP子流的请求，确定辅TCP子流正在由另一负载均衡器处理，并且将请求路由到另一负载均衡器。

示例4.根据示例1至3中任一项的方法，其中追踪包括：使用第一表来追踪TCP子流，并且使用第二表来追踪MPTCP连接。

示例5.根据示例1至4中任一项的方法，其中：方法还包括：响应于在负载均衡器处并且从客户端接收到用以建立用于MPTCP连接的主TCP子流的请求和对客户端支持MPTCP的指示，由负载均衡器生成要用于生成从其他MPTCP连接中唯一地标识MPTCP连接的令牌的密钥，以及使用密钥来生成令牌；并且追踪MPTCP连接及其对应的TCP子流还包括将以下项插入存储器中：密钥、唯一地标识主TCP子流的信息、用于TCP子流到后端的后续路由的指定的后端的对应标识、和令牌。

示例6.根据示例5的方法，其中使用密钥生成令牌由负载均衡器执行，使得令牌空间使用一致性哈希被划分以保证令牌的唯一性，并且还使得多个负载均衡器中的每一个负载均衡器能够计算令牌空间划分的结果，使得负载均衡器知道任何其他负载均衡器的令牌范围。

示例7.根据示例6的方法，还包括响应于所生成的密钥不满足与密钥相对应的令牌不落入负载均衡器的令牌范围的要求而重新生成密钥。

示例8.根据示例6的方法，其中：负载均衡器LB₁，LB₂...LB_n具有IP地址IP₁，IP₂，...，IP_n；方法还包括将IP地址哈希为范围 R＝(0to(2³²-1))上的值key₁，key₂，key₃，...，key_n；负载均衡器LB_i具有地址IP_i，并且hash_32(IP_i)＝key_i；并且方法还包括如下将key_i映射到范围R的圆并且将范围R的子范围指派给负载均衡器LB_i：从key_i看向圆的中心时，在右边并且直到右手侧上的负载均衡器LB_i的最近邻的所有值被指派给负载均衡器LB_i。

示例9.根据示例5的方法，其中唯一地标识主TCP子流的信息包括5元组。

示例10.根据示例5的方法，其中插入存储器中响应于以下而执行：根据唯一地标识用于请求的主TCP子流的第一信息与唯一地标识存储器中包含的其他主TCP子流的第二信息的比较而接收到当前没有被存储在存储器中的、用于MPTCP连接的主TCP子流，以及确定在第一信息与第二信息之间不存在匹配。

示例11.根据示例5的方法，其中追踪MPTCP连接及其对应的 TCP子流还包括：响应于接收到用于MPTCP连接的辅TCP子流而将以下插入存储器中：唯一地标识辅TCP子流的信息、标识所指定的后端的信息、以及从其他MPTCP连接中唯一地标识TCP子流是其一部分的MPTCP连接的令牌。

示例12.根据示例1至11中任一项的方法，还包括：使用计时器来确定MPTCP连接或MPTCP连接的一个或多个TCP子流，针对所述MPTCP连接或MPTCP连接的一个或多个TCP子流，在一个或多个时间段期间没有分组被接收到，以及在一个或多个时间段之后响应于对应的计时器到期而去除MPTCP连接及其对应的TCP子流或者去除MPTCP连接的一个或多个子流。

示例13.一种装置，包括：用于通过负载均衡器将多径传输控制协议(MPTCP)连接及其对应的传输控制协议(TCP)子流朝向一个或多个选定后端路由的部件，其中每个MPTCP连接被路由到多个后端中的单个后端并且能够至少包括主TCP子流和辅TCP子流，并且其中路由MPTCP连接包括响应于建立MPTCP连接的主TCP子流，而执行MPTCP连接的负载均衡，以选择多个后端中的用于MPTCP 连接的选定的一个后端；以及用于由负载均衡器追踪MPTCP连接及其对应的TCP子流，以实现MPTCP连接及其对应的TCP子流到对应的选定后端的路由的部件。

示例14.根据示例13的装置，还包括用于执行根据示例2至12 中任一项的方法的部件。

示例15.一种负载均衡器，包括根据示例13或14中任一项的装置。

示例16.一种方法，包括：在通信系统中的后端处确定客户端建立多径TCP(MPTCP)连接的主传输控制协议(TCP)子流的请求是否已经包括用于生成用于从其他MPTCP连接中唯一地标识MPTCP 连接的令牌的密钥；由后端基于来自请求的密钥来生成令牌；以及由后端使用令牌来区分用于MPTCP连接的后续通信。

示例17.根据示例16的方法，其中由后端使用令牌来区分用于 MPTCP连接的后续通信还包括使用令牌来向客户端传送用于MPTCP 连接的数据。

示例18.根据示例16至17中任一项的方法，其中由后端使用令牌来区分MPTCP连接的后续通信还包括使用令牌来建立MPTCP连接的辅TCP子流。

示例19.根据示例18的方法，还包括使用所接收的元组来区分主TCP子流与辅TCP子流。

示例20.一种装置，包括：在通信系统中的后端处的用于确定客户端建立多径TCP(MPTCP)连接的主传输控制协议(TCP)子流的请求是否已经包括用于生成用于从其他MPTCP连接中唯一地标识 MPTCP连接的令牌的密钥的部件；用于由后端基于来自请求的密钥来生成令牌的部件；以及用于由后端使用令牌来区分MPTCP连接的后续通信的部件。

示例21.根据示例20的装置，还包括用于执行根据示例17至19 中任一项的方法的部件。

示例22.一种后端，包括根据示例20或21中任一项的装置。

示例23.一种系统，包括根据示例13或14中任一项的装置以及根据示例20或21中任一项的装置。

示例24.一种计算机程序，包括用于在计算机程序在处理器上被运行时，执行根据示例1至12或16至19中任一项的方法的代码。

示例25.根据示例24的计算机程序，其中计算机程序是包括计算机可读介质的计算机程序产品，计算机可读介质承载在其中被实施的计算机程序代码以供计算机使用。

本文中的实施例可以以软件(由一个或多个处理器执行)、硬件 (例如，专用集成电路)或软件和硬件的组合来实现。在示例实施例中，软件(例如，应用逻辑、指令集)被保持在各种传统计算机可读介质中的任何一种上。在本文档的上下文中，“计算机可读介质”可以是可以包含、存储、传送、传播或传输由指令执行系统、装置或设备使用或与其结合使用的指令的任何介质或部件，诸如计算机，计算机的一个示例例如在图6中描述和描绘。计算机可读介质可以包括计算机可读存储介质(例如，存储器655或其他设备)，该计算机可读存储介质可以是可以包含、存储和/或传输由指令执行系统、装置或设备使用或与其结合使用的指令的任何介质或部件，诸如计算机。计算机可读存储介质不包括传播信号。

如果需要，本文中讨论的不同功能可以以不同的顺序和/或彼此同时地执行。此外，如果需要，上述功能中的一个或多个可以是可选的或者可以进行组合。

尽管在独立权利要求中陈述了本发明的各个方面，但是本发明的其他方面包括来自所描述的实施例和/或从属权利要求的特征与独立权利要求的特征的其他组合，而不仅仅是在权利要求中明确列出的这些组合。

本文中还应当注意，尽管以上描述了本发明的示例实施例，但是这些描述不应当以限制性的意义来理解。而是，在不脱离所附权利要求书中限定的本发明的范围的情况下，可以进行若干变型和修改。

在说明书和/或附图中可以找到的以下缩写定义如下：

ACK 确认

ARP 地址解析协议

BE 后端

DNS 域名系统

DPDK 数据平面开发套件

DSR 直接服务器返回

ECMP 等价多路径

eNB(或eNodeB) 演进型节点B(例如，LTE基站)

HMAC 哈希消息认证码

id或ID 标识

I/F 接口

IP 互联网协议

KNI 内核NIC接口

LB 负载均衡

LRU 最近最少使用

LTE 长期演进

MAC 媒体访问控制

MIMO 多输入多输出

MU-MIMO 多用户MIMO

MPTCP 多径TCP

MME 移动性管理实体

NCE 网络控制元件

NIC 网络接口控制器

N/W 网络

OFDMA 正交频分多址

Rx 接收器

SCTP 流控制传输协议

SF 子流

SGW 服务网关

SYN 同步

tbl 表

TCP 传输控制协议

TCP/IP 传输控制协议/互联网协议

Tx 传输器

UDP 用户数据报协议

UE 用户设备(例如，无线设备，通常是移动设备)

VIP 虚拟IP。

Claims

1.一种通信方法，包括：

由负载均衡器将多径传输控制协议(MPTCP)连接及其对应的传输控制协议(TCP)子流朝向一个或多个选定后端路由，其中每个MPTCP连接被路由到多个后端中的单个后端并且能够至少包括主TCP子流和辅TCP子流，并且其中路由所述MPTCP连接包括响应于建立MPTCP连接的主TCP子流，而执行所述MPTCP连接的负载均衡，以选择所述多个后端中的用于所述MPTCP连接的选定的一个后端；以及

由所述负载均衡器追踪所述MPTCP连接及其对应的TCP子流，以实现所述MPTCP连接及其对应的TCP子流到对应的所述选定后端的路由，并且

其中所述追踪还包括：对于到达所述负载均衡器的、针对MPTCP连接的辅TCP子流的请求，确定所述辅TCP子流正在由另一负载均衡器处理，并且将所述请求路由到所述另一负载均衡器。

2.根据权利要求1所述的方法，其中所述追踪还包括：对于到达所述负载均衡器的、针对MPTCP连接的辅TCP子流的请求，确定所述辅TCP子流正在由所述负载均衡器处理，并且将所述请求路由到与所述MPTCP连接相对应的选定后端。

3.根据权利要求1至2中任一项所述的方法，其中追踪包括：使用第一表来追踪TCP子流，并且使用第二表来追踪MPTCP连接。

4.根据权利要求1至2中任一项所述的方法，其中：

所述方法还包括：响应于在所述负载均衡器处并且从客户端接收到用以建立用于MPTCP连接的主TCP子流的请求和对所述客户端支持MPTCP的指示，由所述负载均衡器生成密钥，所述密钥将被用于生成令牌，所述令牌从其他MPTCP连接中唯一地标识所述MPTCP连接，以及使用所述密钥来生成所述令牌；并且

追踪所述MPTCP连接及其对应的TCP子流还包括将以下项插入存储器中：所述密钥、唯一地标识所述主TCP子流的信息、用于所述TCP子流到所述后端的后续路由的指定的后端的对应标识、以及所述令牌。

5.根据权利要求4所述的方法，其中使用所述密钥生成所述令牌由所述负载均衡器执行，使得令牌空间使用一致性哈希被划分以保证所述令牌的唯一性，并且还使得多个负载均衡器中的每一个负载均衡器能够计算令牌空间划分的结果，使得所述负载均衡器知道任何其他负载均衡器的令牌范围。

6.根据权利要求5所述的方法，还包括响应于所生成的所述密钥不满足以下要求而重新生成所述密钥：与所述密钥相对应的令牌不落入所述负载均衡器的令牌范围。

7.根据权利要求5所述的方法，其中：

负载均衡器LB₁，LB₂...LB_n具有IP地址IP₁，IP₂，...，IP_n；

所述方法还包括将所述IP地址哈希为范围R＝(0to(2³²-1))上的值key₁，key₂，key₃，...，key_n；

所述负载均衡器LB_i具有地址IP_i，并且hash_32(IP_i)＝key_i；并且

所述方法还包括如下将key_i映射到范围R的圆并且将范围R的子范围指派给所述负载均衡器LB_i：从所述key_i看向所述圆的中心时，在右边并且直到右手侧上的所述负载均衡器LB_i的最近邻的所有值被指派给所述负载均衡器LB_i。

8.根据权利要求4所述的方法，其中唯一地标识所述主TCP子流的所述信息包括5元组。

9.根据权利要求4所述的方法，其中所述插入所述存储器中响应于以下而被执行：根据第一信息与第二信息的比较而接收当前没有被存储在所述存储器中的、用于MPTCP连接的主TCP子流，所述第一信息唯一地标识用于所述请求的所述主TCP子流，所述第二信息唯一地标识在所述存储器中包含的其他主TCP子流，以及确定在所述第一信息与所述第二信息之间不存在匹配。

10.根据权利要求4所述的方法，其中追踪所述MPTCP连接及其对应的TCP子流还包括：响应于接收到用于MPTCP连接的辅TCP子流，而将以下插入所述存储器中：唯一地标识所述辅TCP子流的信息、标识所述指定的后端的信息、以及从其他MPTCP连接中唯一地标识所述TCP子流是其一部分的所述MPTCP连接的所述令牌。

11.根据权利要求1至2中任一项所述的方法，还包括：使用计时器来确定MPTCP连接或MPTCP连接的一个或多个TCP子流，针对所述MPTCP连接或MPTCP连接的一个或多个TCP子流，在一个或多个时间段期间没有分组被接收到，以及在所述一个或多个时间段之后响应于对应的计时器到期而去除所述MPTCP连接及其对应的TCP子流或者去除MPTCP连接的一个或多个子流。

12.一种用于通信的装置，包括：

用于通过负载均衡器将多径传输控制协议(MPTCP)连接及其对应的传输控制协议(TCP)子流朝向一个或多个选定后端路由的部件，其中每个MPTCP连接被路由到多个后端中的单个后端并且能够至少包括主TCP子流和辅TCP子流，并且其中路由所述MPTCP连接包括响应于建立MPTCP连接的主TCP子流，而执行所述MPTCP连接的负载均衡，以选择所述多个后端中的用于所述MPTCP连接的选定的一个后端；以及

用于由所述负载均衡器追踪所述MPTCP连接及其对应的TCP子流，以实现所述MPTCP连接及其对应的TCP子流到对应的所述选定后端的路由的部件，并且

其中用于追踪的所述部件还包括：用于对于到达所述负载均衡器的、针对MPTCP连接的辅TCP子流的请求、确定所述辅TCP子流正在由另一负载均衡器处理的部件，以及用于将所述请求路由到所述另一负载均衡器的部件。

13.根据权利要求12所述的装置，其中用于所述追踪的所述部件还包括：用于对于到达所述负载均衡器的、针对MPTCP连接的辅TCP子流的请求、确定所述辅TCP子流正在由所述负载均衡器处理的部件，以及用于将所述请求路由到与所述MPTCP连接相对应的选定后端的部件。

14.根据权利要求12至13任一项所述的装置，其中用于追踪的所述部件包括：用于使用第一表来追踪TCP子流的部件，以及用于使用第二表来追踪MPTCP连接的部件。

15.根据权利要求12至13中任一项所述的装置，其中：

所述装置还包括：用于响应于在所述负载均衡器处并且从客户端接收到用以建立用于MPTCP连接的主TCP子流的请求和对所述客户端支持MPTCP的指示而由所述负载均衡器生成密钥的部件，所述密钥将被用于生成令牌，所述令牌从其他MPTCP连接中唯一地标识所述MPTCP连接，以及使用所述密钥来生成所述令牌；并且

用于追踪所述MPTCP连接及其对应的TCP子流的所述部件还包括用于将以下项插入存储器中的部件：所述密钥、唯一地标识所述主TCP子流的信息、用于所述TCP子流到所述后端的后续路由的指定的后端的对应标识、以及所述令牌。

16.根据权利要求15所述的装置，其中使用所述密钥生成所述令牌由所述负载均衡器执行，使得令牌空间使用一致性哈希被划分以保证所述令牌的唯一性，并且还使得多个负载均衡器中的每一个负载均衡器能够计算令牌空间划分的结果，使得所述负载均衡器知道任何其他负载均衡器的令牌范围。

17.根据权利要求16所述的装置，还包括用于响应于所生成的所述密钥不满足以下要求而重新生成所述密钥的部件：与所述密钥相对应的令牌不落入所述负载均衡器的令牌范围。

18.根据权利要求16所述的装置，其中：

负载均衡器LB₁，LB₂...LB_n具有IP地址IP₁，IP₂，...，IP_n；

所述装置还包括用于将所述IP地址哈希为范围R＝(0to(2³²-1))上的值key₁，key₂，key₃，...，key_n的部件；

所述装置还包括用于如下将key_i映射到范围R的圆并且将范围R的子范围指派给所述负载均衡器LB_i的部件：从所述key_i看向所述圆的中心时，在右边并且直到右手侧上的所述负载均衡器LB_i的最近邻的所有值被指派给所述负载均衡器LB_i。

19.根据权利要求15所述的装置，其中唯一地标识所述主TCP子流的所述信息包括5元组。

20.根据权利要求15所述的装置，其中所述插入所述存储器中响应于以下而被执行：根据第一信息与第二信息的比较而接收当前没有被存储在所述存储器中的、用于MPTCP连接的主TCP子流，所述第一信息唯一地标识用于所述请求的所述主TCP子流，所述第二信息唯一地标识在所述存储器中包含的其他主TCP子流，以及确定在所述第一信息与所述第二信息之间不存在匹配。

21.根据权利要求15所述的装置，其中用于追踪所述MPTCP连接及其对应的TCP子流的所述部件还包括：用于响应于接收到用于MPTCP连接的辅TCP子流而将以下插入所述存储器中的部件：唯一地标识所述辅TCP子流的信息、标识所述指定的后端的信息、以及从其他MPTCP连接中唯一地标识所述TCP子流是其一部分的所述MPTCP连接的所述令牌。

22.根据权利要求12至13中任一项所述的装置，还包括：用于使用计时器来确定MPTCP连接或MPTCP连接的一个或多个TCP子流的部件，针对所述MPTCP连接或MPTCP连接的一个或多个TCP子流，在一个或多个时间段期间没有分组被接收到，以及用于在所述一个或多个时间段之后响应于对应的计时器到期而去除所述MPTCP连接及其对应的TCP子流或者去除MPTCP连接的一个或多个子流的部件。

23.一种通信方法，包括：

在通信系统中的后端处确定客户端建立多径TCP(MPTCP)连接的主传输控制协议(TCP)子流的请求是否已经包括密钥，所述密钥被用于生成令牌，所述令牌被用于从其他MPTCP连接中唯一地标识所述MPTCP连接；

由所述后端基于来自所述请求的所述密钥来生成所述令牌；以及

由所述后端使用所述令牌来区分用于所述MPTCP连接的后续通信，并且

其中由所述后端使用所述令牌来区分用于所述MPTCP连接的后续通信还包括：使用所述令牌来向所述客户端传送用于所述MPTCP连接的数据。

24.根据权利要求23所述的方法，其中由所述后端使用所述令牌来区分用于所述MPTCP连接的后续通信还包括：使用所述令牌来建立所述MPTCP连接的辅TCP子流。

25.根据权利要求24所述的方法，还包括使用所接收的元组来区分主TCP子流与所述辅TCP子流。

26.一种用于通信的装置，包括：

在通信系统中的后端处的用于确定客户端建立多径TCP(MPTCP)连接的主传输控制协议(TCP)子流的请求是否已经包括密钥的部件，所述密钥被用于生成令牌，所述令牌被用于从其他MPTCP连接中唯一地标识所述MPTCP连接；

用于由所述后端基于来自所述请求的所述密钥来生成所述令牌的部件；以及

用于由所述后端使用所述令牌来区分用于所述MPTCP连接的后续通信的部件，并且

其中用于由所述后端使用所述令牌来区分用于所述MPTCP连接的后续通信的所述部件还包括：用于使用所述令牌来向所述客户端传送用于所述MPTCP连接的数据的部件。

27.根据权利要求26所述的装置，其中用于由所述后端使用所述令牌来区分用于所述MPTCP连接的后续通信的所述部件还包括：用于使用所述令牌来建立所述MPTCP连接的辅TCP子流的部件。

28.根据权利要求27所述的装置，还包括用于使用所接收的元组来区分主TCP子流与所述辅TCP子流的部件。

29.一种计算机可读介质，承载在其中被实施的计算程序代码，以用于执行根据权利要求1至11或23至25中任一项所述的方法的代码。