ACM通信
实践
TCP多路
信贷:自然
互联网严重依赖于两种协议。在网络层，IP提供了一种不可靠的数据报服务，确保任何主机都可以与任何其他主机交换数据包。自20世纪70年代创建以来，IP已经增加了一些特性，包括组播、IPsec (IP安全)和QoS。
最新版本IPv6支持16字节地址。
第二个主要协议是传输控制协议(TCP)，它在传输层运行，在IP之上提供可靠的字节流服务。自研究网络的第一次实验以来，TCP一直在不断发展。
尽管如此，TCP的一个早期设计决策仍然让许多用户感到沮丧。TCP和IP是独立的协议，但是网络和传输协议之间的分离并不完全。为了区分传入数据包中的各个数据流，接收端主机基于所谓的5元组(包括IP地址、端口号和协议标识符)对数据包进行多路复用。这意味着TCP连接在建立连接时被绑定到客户机和服务器上使用的IP地址。尽管移动节点(如智能手机和平板电脑)的重要性日益增长，但TCP连接不能从一个IP地址移动到另一个IP地址。当笔记本电脑从以太网切换到Wi-Fi时，它获得了另一个IP地址。必须拆除所有现有的TCP连接，并重新启动新的连接。
在过去的几年里，许多研究人员提出了解决这个问题的方案。第一种方法是在网络层解决问题。此类解决方案的例子包括移动IP、主机标识协议(HIP)和通过IPv6中介的站点多归属(Shim6)。这些网络层解决方案的一个显著缺点是，它们隐藏了对地址的所有更改，从而隐藏了TCP拥塞控制方案的路径。这是低效的，因为拥塞控制方案发送数据的路径可能会在没有通知的情况下改变。
另一个可能的解决方案是向传输层公开多个地址。这是流控制传输协议(SCTP)所选择的方法，17这是一种可选的传输协议，能够在每个连接中支持多个IP地址。SCTP的第一个版本在故障转移场景中使用多个地址，但最近的扩展使它能够支持同时使用多个路径。9
不幸的是，除了电话网络中的信令等小众应用程序之外，SCTP还没有得到广泛部署。一个原因是许多防火墙和网络地址转换(NAT)机无法处理SCTP包，因此直接丢弃它们。另一个原因是SCTP向应用程序公开了与套接字API不同的API。这两个因素导致了经典的先有鸡还是先有蛋的问题。网络制造商在其防火墙中不支持SCTP，因为没有应用程序使用该协议;应用程序开发人员不使用SCTP，因为防火墙会丢弃SCTP包。已经有人尝试通过将SCTP封装在UDP(用户数据报协议)之上并向应用程序公开套接字接口来打破这种恶性循环，但SCTP的广泛使用仍然难以实现。
多路径TCP (MPTCP)是考虑到这些问题而设计的。更具体地说，MPTCP的设计目标是:15
- 它应该能够为一个连接使用多个网络路径，
- 它必须能够使用可用的网络路径，至少和常规TCP一样好，但不会让TCP挨饿，
- 对于现有的应用程序，它必须和常规TCP一样可用
- 启用MPTCP不能阻止常规TCP工作的路径上的连接。
下面的部分描述了作为MPTCP基础的主要体系结构原则。在一个理想的网络中，这些简单的原则就足够了。不幸的是，考虑到中间盒的流行，这在今天的Internet中不是这样的，后面会解释。
体系结构原则
应用程序通过常规套接字API进行交互，MPTCP管理底层TCP连接(称为子流)6)，以携带实际数据。从体系结构的角度来看，MPTCP充当套接字接口和一个或多个TCP子流之间的垫片层，如图1．MPTCP需要在终端主机之间发送额外的信号。它通过使用TCP选项实现以下目标:
- 建立新的MPTCP连接。
- 向MPTCP连接中添加子流。
- 在MPTCP连接上传输数据。
MPTCP连接是通过使用三次握手与TCP选项协商其使用情况来建立的。的MP_CAPABLE选项表示客户端支持MPTCP协议。此选项还包含一个用于安全目的的随机密钥。如果服务器支持MPTCP，那么它响应一个SYN+ACK段，其中也包含MP_CAPABLE选择。该选项包含服务器选择的一个随机键。三次握手的第三个ACK还包括MP_CAPABLE选项确认MPTCP的使用情况，以及启用无状态服务器的键。
三次握手如图所示图2在一个接口上创建第一个TCP子流。要使用另一个接口，MPTCP使用三次握手在该接口上建立一个子流。向现有的MPTCP连接添加子流需要在每个端主机上唯一标识相应的MPTCP连接。对于常规的TCP, TCP连接总是通过使用元组来标识
不幸的是，由于存在NAT，在客户机上使用的地址和端口号可能与公开给服务器的不相同。尽管在每个主机上，4元组是每个TCP连接的唯一本地标识，但这个标识并不是全局唯一的。MPTCP需要能够将每个子流链接到现有的MPTCP连接。为此，MPTCP为每个连接分配一个本地唯一的令牌。当一个新的子流被添加到一个现有的MPTCP连接中时，MP_JOIN选项包含关联MPTCP连接的令牌。这在图3．
精明的读者可能已经注意到MP_CAPABLE选项不包含令牌。不过，要启用子流的建立，仍然需要令牌。缩短的长度MP_CAPABLE选项，并避免使用SYN段中所有有限的TCP选项空间(40字节)，MPTCP将令牌作为键的截断散列的结果派生。的第二个功能MP_JOIN选项是验证子流的添加。为此，客户端和服务器交换随机nonce，每个主机计算一个基于哈希的消息认证码(HMAC)，基于另一个主机选择的随机nonce和初始握手期间交换的密钥。
既然已经建立了子流，MPTCP就可以使用它们交换数据了。每个主机都可以通过任何已建立的子流发送数据。此外，在一个子流上传输的数据可以在另一个子流上重传，以从损失中恢复。这是通过使用两个级别的序列号来实现的。6常规的TCP序列号确保在每个子流上按顺序接收数据，并允许检测损失。在将数据传递给应用程序之前，MPTCP使用数据序列号对从不同子流接收到的数据进行重新排序。
从拥塞控制的角度来看，为一个连接使用几个子流会导致一个有趣的问题。对于普通的TCP，拥塞发生在发送方和接收方之间的一条路径上。MPTCP使用多条路径，两条路径通常会经历不同程度的拥塞。对于MPTCP中的拥塞问题，一个简单的解决方案是对每个子流使用标准的TCP拥塞控制方案。这很容易实现，但会导致常规TCP的不公平性。在网络中描述图4，两个客户端共享相同的瓶颈链路。如果启用mptcp的客户机使用两个子流，那么它将获得三分之二的共享瓶颈。这是不公平的，因为如果这个客户机使用常规TCP，它将只获得共享瓶颈的一半。
图5展示了使用标准TCP拥塞控制方案(Reno)跨共享瓶颈使用多达8个子流的效果。在这种情况下，MPTCP将使用高达85%的瓶颈容量，有效地饿死常规TCP。针对这一问题，设计了特定的MPTCP拥塞控制方案。10，18简单地说，他们测量每个子流的拥堵情况，并试图将交通从拥堵最严重的子流移开。为此，他们根据拥塞级别调整每个子流上的TCP拥塞窗口。此外，不同子流上的拥塞窗口是耦合的，以确保它们的聚合不会比单个TCP连接增长得更快。图5为OLIA拥塞控制方案10通过共享瓶颈保持常规TCP的公平性。
魔鬼在米德尔盒子里
今天的互联网与最初设计TCP的网络完全不同。这些网络遵循端到端原则，这意味着网络是由交换机和路由器组成的，它们转发数据包，但从不改变其内容。现在因特网除了这些路由器和交换机之外，还包含各种各样的中间箱。最近的一项调查显示，企业网络通常包含比普通路由器更多的中间盒。16这些中间箱不仅包括经典的防火墙和nat，还包括透明代理、虚拟专用网络网关、负载平衡器、深包检查器、入侵检测系统和广域网加速器等设备。许多这些设备处理并有时修改TCP头，甚至是通过的TCP段的有效负载。在设计MPTCP协议时，处理这些中间盒一直是最困难的挑战之一，如下面的示例所示。6，7，15
当接收到TCP子流上的数据时，接收端必须知道数据序列号，以便在将数据流传递给应用程序之前对其进行重新排序。一种简单的方法是在每个段内的TCP选项中包含数据序列号。不幸的是，这种干净的解决方案并不奏效。有部署的中间盒在因特网上分割段。特别是，所有现代网络接口卡(nic)在执行TCP分段卸载(TSO)时充当段分割的中间盒。这些网卡将单个段分割成更小的片段。在TSO的情况下，CPU周期从操作系统卸载到网卡，因为操作系统处理更少、更大的段，这些段被网卡分割为最大传输单元(MTU)大小的段。大段的TCP选项(包括MPTCP数据序列号)被复制到每个小段中。因此，接收端将收集到多个具有相同数据序列号的段，无法正确地重构数据流。MPTCP设计者通过在数据序列选项中放置映射来解决这个问题，该选项定义了数据序列号的开始(相对于子流序列号)和结束(指示映射的长度)。 MPTCP can thus correctly work across segment-splitting middleboxes and can be used with NICs that use TCP segmentation offloading to improve performance.
因此，数据序列选项精确地将子流序列空间中的每个字节映射到数据序列空间，允许接收方重构数据流。
在Linux内核中使用第一个MPTCP实现来执行度量，揭示了另一种类型的中间盒。由于该实现在实验室中工作良好，所以它被安装在远程服务器上。第一次实验令人失望。建立MPTCP连接，但不能传输任何数据。尽管如此，同样的内核在实验室中工作得很好，但没有人能理解为什么更长的延迟会阻止数据传输。罪魁祸首原来是一个本地防火墙，它改变了所有TCP段的序列号。该特性是几年前添加到防火墙的，以防止不使用随机初始序列号的主机出现安全问题。在某种意义上，防火墙正在修复旧TCP栈中的一个安全问题，但在试图解决这个问题时，它又产生了另一个问题。防火墙修改子流序列号到数据序列号的映射错误。处理步骤从那时起，data-sequence选项中的映射使用相对子流序列号与初始序列号进行比较，而不是使用绝对序列号。6
因此，数据序列选项精确地将子流序列空间中的每个字节映射到数据序列空间，允许接收方重构数据流。一些中间箱可能仍然会干扰这个过程:修改段有效负载的应用程序级网关。典型的例子是活动FTP。FTP使用几个TCP连接，通过在控制连接上交换ascii编码的IP地址作为命令参数发出信号。为了支持活动FTP, NAT盒必须修改客户端主机正在以ASCII格式发送的私有IP地址。这意味着不仅要修改有效负载的内容，有时还要修改其长度，因为NAT设备的公共IP地址在ASCII表示中可能具有不同的长度。有效载荷长度的这种变化将使从子流序列空间到数据序列空间的映射不正确。MPTCP甚至可以处理这样的中间盒，这要归功于保护每个映射的有效负载的校验和。如果应用程序级网关修改了有效负载，那么校验和将被损坏;MPTCP将能够检测有效负载的变化，并执行到常规TCP的无缝回退，以保持主机之间的连通性。
一些研究人员更详细地分析了这些中间盒的影响。一项研究使用了对100多个互联网路径的主动测量，以检测各种形式的中间盒的流行程度。8测量结果表明，协议设计者在设计TCP扩展时不能再假设Internet是透明的;任何TCP扩展都不能假设TCP报头的单个字段不经过任何修改就能到达目的地。TCP选项并不安全。其中一些选项可以在它们到达目的地的过程中进行修改。此外，一些中间层删除或复制TCP选项。尽管有这些困难，MPTCP仍然能够应付大多数的中间盒。7当面临中间盒干扰时，MPTCP总是试图保持连通性。在某些情况下，这是通过退回到常规TCP来实现的。6，7
用例
两个已经在文献中分析过的用例将用于说明MPTCP的可能应用。未来可能会出现其他用例。
MPTCP的智能手机都配有Wi-Fi和3G/4G接口，但通常一次只使用一个接口。尽管如此，当智能手机从一个无线网络切换到另一个无线网络时，用户还是希望他们的TCP连接能够继续存在。对于常规TCP，交换网络意味着更改本地IP地址，并导致所有已建立的TCP连接的终止。4有了MPTCP，这种情况可能会改变，因为它可以实现从Wi-Fi到3G/4G以及相反的无缝切换。13
不同类型的移交是可能的:
- 首先,先接后断如果智能手机可以预测一个接口将很快消失(例如，因为无线电信号减弱)，就可以使用切换。在这种情况下，新的子流将在第二个接口上初始化，数据将切换到这个接口。
- 与先断后通切换时，MPTCP可以通过启用另一个接口并在其上启动子流来应对一个接口上的故障。一旦创建了子流，由于第一个接口故障而丢失的数据就可以在新的子流上重新传输，连接将继续而不会中断。
- 第三种切换模式同时使用两个或多个接口。对于常规TCP，这将是一种能源浪费。使用MPTCP，数据可以通过两个接口传输，以加快数据传输速度。从能源的角度来看，启用两个无线电接口比启用一个无线电接口成本更高;然而，显示器通常比无线电接口消耗更多的能量。2当用户查看屏幕时(例如，在等待Web页面时)，通过组合两个界面来提高下载速度可以减少显示的使用，从而减少能源消耗。
作为一个例子，让我们分析MPTCP在真实Wi-Fi和3G网络中的操作。这个场景很简单，但代表了许多情况。用户通过Wi-Fi在建筑物内开始下载，然后移动到外面。Wi-Fi连接在用户移动时丢失，但由于MPTCP，数据传输不受影响。图6显示了使用3G和Wi-Fi收集的典型MPTCP跟踪。的x-axis显示数据传输开始以来的时间，而y-axis显示出方向报文序列号的变化。
对于这种传输，MPTCP被配置为同时使用Wi-Fi和3G，以最大化性能。蓝色曲线显示了在3G接口上TCP子流上TCP序列号的变化。3G子流开始以固定速率传输。在秒14到秒24之间，3G接口提供了较低的吞吐量。这可以解释为更高的拥塞或较弱的无线电信号，因为智能手机在这段时间移动到建筑物内。在这段短暂的时间之后，3G子流继续以恒定的速率传输。注意，TCP不会检测到3G接口上的任何丢失。黑色曲线表示的是Wi-Fi子流上TCP序列号的演变过程。红色的叉表示重传数据包。
比较3G和Wi-Fi的曲线可以发现，Wi-Fi通常比3G快，但数据包在Wi-Fi接口上丢失的频率更高。当智能手机移动时，Wi-Fi接口会在短时间内像黑洞一样活动。日志含义接口似乎处于激活状态，但没有报文正常发送。当单独使用Wi-Fi时，这段时间可能持续几秒钟，严重影响用户体验。使用MPTCP，在Wi-Fi接口上丢失的数据包会自动通过3G子流重传，MPTCP连接不会中断。
上面的灰色曲线显示了基于返回确认的MPTCP连接的演变。在最初的7秒内，MPTCP完美地聚合了Wi-Fi和3G接口。MPTCP吞吐量是两个接口的吞吐量之和。然后会有少量报文通过Wi-Fi接口丢失。灰色曲线上的第一个竖线对应于收回这些损失后收到的第一个确认。当Wi-Fi接口较弱时，MPTCP吞吐量随接口质量的变化而变化，但数据传输仍在继续。从性能的角度来看，这种快速利用可用接口的能力是MPTCP的一个关键好处。
使用MPTCP，既可以提高性能，又可以实现高可用性。
提高数据传输性能并不是MPTCP在智能手机上的唯一用例。13也可以只使用3G接口作为备份，而不是同时启用Wi-Fi和3G接口。当Wi-Fi接口处于激活状态时，所有数据都通过该接口发送。如果它变为非活动状态，MPTCP自动切换到3G接口继续数据传输，并在Wi-Fi接口恢复后立即停止使用它。
另一个可能的用例是802.11社区网络。许多城市现在都被大量的Wi-Fi接入点覆盖，许多用户都可以访问。3.这些接入点的密集使得移动缓慢的用户主要依靠Wi-Fi进行互联网访问，并在从一个接入点移动到另一个接入点时依靠MPTCP维持连接成为可能。
智能手机的使用情况促使苹果在iOS 7中实现MPTCP。在撰写本文时，MPTCP还不能通过iOS 7上的套接字API使用，它仅用于支持Siri语音识别应用程序。也可以在一些最近扎根的Android智能手机上使用MPTCP Linux内核http://multipath-tcp.org/)．
数据中心中的MPTCP．MPTCP的另一个重要用例在于数据中心。14今天，大多数服务器都配备了多个高速接口，可以将这些接口组合起来以实现更高的性能或更好的故障恢复能力。当两个或多个接口组合在一起以提高性能时，它们通常附加到同一个交换机上，如左侧所示图7．为了使TCP能够有效地使用这两个接口，它们通常表现为具有一个MAC地址和一个IP地址的单个逻辑接口。服务器上的绑定驱动程序将数据包分发到组合的接口上;现有几种负载平衡算法。4轮循系统允许数据包在不同的接口上有效地传播。但是，如果链接具有不同的延迟，则会导致重新排序，从而损害TCP性能。
大多数部署都选择基于哈希的负载平衡技术。以太网和IP和/或TCP头的一些字段被散列以选择出接口。由于这种散列，属于同一个TCP连接的数据包通过同一个接口发送，以防止重新排序，而属于不同连接的数据包分布在可用的接口上。当流量由大量的短TCP连接组成时，这种解决方案效果很好。然而，由于属于一个TCP连接的所有报文都通过同一个接口发送，单个TCP连接不能达到比它所使用的链路更高的吞吐量。这是一个主要的限制，因为长TCP连接在数据中心中非常频繁。1
在某些部署中，结合两个或多个接口来提高可用性。在这种情况下，每个接口附加到不同的交换机，如右侧所示图7．大多数部署都选择在两个接口上使用相同的MAC和IP地址。一个接口用于承载所有报文，另一个接口作为备份。选择该模式时，一次只使用一个接口承载报文。
使用MPTCP，既可以提高性能，又可以实现高可用性。典型的mptcp感知服务器设计将使用连接到不同交换机的两个接口，如中所示图8．每个接口都有自己的MAC和IP地址。一旦MPTCP连接通过一个接口发起，MPTCP将通过使用ADD_ADDR选项,6子流将在这些接口上建立。
一旦建立了这些子流，MPTCP拥塞控制方案将动态地将负载分散到可用的接口上。如果一个接口或任何中间交换机发生故障，MPTCP将自动切换到剩余的路径。
注意，与现有的负载均衡解决方案相比，MPTCP使用的接口不需要具有相同的带宽。这使得MPTCP可以通过将负载分配到所有接口来增加单个数据流的吞吐量。事实上，前面描述过的MPTCP的Linux内核实现11允许两台高端服务器之间的内存对内存传输，每个服务器都配备了6个10Gbps接口。MPTCP能够有效地使用六个接口的容量，单个连接达到53Gbps。12
在服务器端，大多数MPTCP实验都是用Linux MPTCP内核(可从http://multipath-tcp.org)．一个FreeBSD实现正在开发中，一个商用负载均衡器支持MPTCP。5
结论
MPTCP是TCP的主要扩展。通过将TCP与IP分离，TCP最终能够支持多主机。随着无线网络的日益重要，多主机正在成为常态而不是例外。智能手机和数据中心是MPTCP可以提供好处的第一个用例。
致谢
MPTCP的开发是许多研究人员的集体工作，包括Sébastien Barré、Gregory Detal、Fabien Duchene、Phil Eardley、Alan Ford、Mark Handley、Benjamin Hesmans和Costin Raiciu。这项工作得到了欧洲委员会FP7(第七个研究框架计划)项目三部曲、CHANGE和三部曲2的支持;谷歌的礼物;以及Bestcom的IAP。
相关文章
在queue.acm.org
被动测量TCP往返时间
斯蒂芬·d·散播
http://queue.acm.org/detail.cfm?id=2539132
你对网络性能一无所知
凯文·福尔，史蒂夫·麦卡恩
http://queue.acm.org/detail.cfm?id=1066069
TCP卸载到救援
安迪·克里德
http://queue.acm.org/detail.cfm?id=1005069
参考文献
1.Benson, T, Akella, A.和Maltz, d.野外数据中心的网络流量特征。在十人会议记录thACM网络测量SIGCOMM会议, 2010年。
2.卡罗尔，a .和Heiser, G.智能手机的功耗分析。在Usenix年度技术会议论文集, 2010年。
3.G. Castignani, Blanc, A. Lampropulos, A.和N. Montavont，移动用户的城市802.11社区网络:当前部署和展望。移动网络与应用6(2012)。796807.
4.戴维斯，T.等人。Linux以太网绑定驱动程序指南，2011;https://www.kernel.org/doc/Documentation/networking/bonding.txt．
5.MPTCP实现综述。工作进行中，2014年;http://tools.ietf.org/html/draft-eardley-mptcp-implementations-survey-02．
6.A. Ford, Raiciu, C. Handley, M.和Bonaventure .用于多地址多路径操作的TCP扩展。RFC6824, 2014;http://www.rfc-editor.org/rfc/rfc6824.txt．
7.Hesmans, B.， Duchene, F.， Paasch, C.， Detal, G.和Bonaventure, O. TCP扩展是中间盒防的吗?在2014年关于中间层和网络功能虚拟化的热点话题研讨会论文集．
8.本田，M.，西田，Y.， Raiciu, C.，格林哈尔，A.，汉德利，M.和德田，H.是否还有可能扩展TCP?在2011年ACM SIGCOMM互联网测量会议论文集．
9.Iyengar, j.r, Amer, P. D.和Stewart, R.在独立的端到端路径上使用SCTP多归属的并发多路径传输。《IEEE/ACM网络汇刊， 5(2006)， 951964。
10.R.哈利利，N.加斯特，M.波波维奇，U.乌帕德海伊和j .布德克。MPTCP不是帕累托最优的:性能问题和一个可能的解决方案。在八人会议记录thACM新兴网络实验与技术国际会议, 2012年。
11.C. Paasch, Barré， S.， Detal, G.和Duchene . Linux内核实现的多路径TCP, 2014;http://multipath-tcp.org．
12.C. Paasch, Detal, G.， Barré， S.， Duchene, F.和Bonaventure, O.使用多路径TCP的最快TCP连接，2014;http://multipath-tcp.org/pmwiki.php?n=Main.50Gbps．
13.C. Paasch, Detal, G.， Duchene, F.， Raiciu, C.和Bonaventure, O.探索使用多路径TCP的移动/Wi-Fi切换。在ACM SIGCOMM蜂窝网络研讨会论文集:操作、挑战和未来设计, 2012年。
14.Raiciu, Barré， S.， Pluntke, C.， Greenhalgh, A.， Wischik, D.和Handley, M.使用多路径TCP提高数据中心性能和鲁棒性。ACM SIGCOMM计算机通信评论， 4(2011)， 266277。
15.C. Raiciu, C. Paasch, Barré， S.，福特，A.，本田，M.，杜辰，F.，博纳旺蒂尔，O.和汉德利，M.，能有多难?设计和实现一个可部署的多路径TCP。在会议记录th网络化系统设计与实现研讨会, 2012年。
16.Sherry, J.， Hasan, S.， Scott, C. Krishnamurthy, A.， Ratnasamy, S.和Sekar, V.让中间盒成为别人的问题:作为云服务的网络处理。ACM SIGCOMM计算机通信评论， 4(2012)， 1324。
17.Stewart R.和谢Q。流控制传输协议:参考指南．addison - wesley, 2001年。
18.Wischik, D.， Raiciu, C. Greenhalgh, A.和Handley, M.多路径TCP拥塞控制的设计、实现和评估。在八人会议记录th网络系统设计与实现Usenix研讨会, 2011年。
©2014 0001 - 0782/14/04 ACM
允许为个人或课堂使用部分或全部作品制作数字或硬拷贝，但不得为盈利或商业利益而复制或分发，且副本在首页上附有本通知和完整的引用。除ACM外，本作品的其他组件的版权必须受到尊重。允许有信用的文摘。以其他方式复制、重新发布、在服务器上发布或重新分发到列表，都需要事先获得特定的许可和/或费用。请求发布的权限permissions@acm.org传真(212)869-0481。
数字图书馆是由计算机协会出版的。版权所有©2014 ACM, Inc.
没有发现记录