PDF多路径 TCP
与 IP 解耦后，TCP 终于能够支持多宿主主机。
Christoph Paasch 和 Olivier Bonaventure，UCL
互联网在很大程度上依赖于两种协议。在网络层，IP（互联网协议）提供不可靠的数据报服务，并确保任何主机都可以与任何其他主机交换数据包。自 20 世纪 70 年代创建以来，IP 已经增加了几个功能，包括多播、IPsec（IP 安全）和 QoS（服务质量）。最新的修订版 IPv6（IP 版本 6）支持 16 字节地址。
第二大主要协议是 TCP（传输控制协议），它在传输层运行，并在 IP 之上提供可靠的字节流服务。自研究网络中的首次实验以来，TCP 一直在不断发展。
然而，TCP 早期的一个设计决策仍然让许多用户感到沮丧。TCP 和 IP 是独立的协议，但网络和传输协议之间的分离并不完全。为了区分传入数据包中的各个数据流，接收端主机根据所谓的 5 元组对数据包进行解复用，其中包括 IP 地址、端口号和协议标识符。这意味着 TCP 连接绑定到连接建立时客户端和服务器上使用的 IP 地址。尽管智能手机和平板电脑等移动节点的重要性日益增加，但 TCP 连接无法从一个 IP 地址移动到另一个 IP 地址。当笔记本电脑从以太网切换到 Wi-Fi 时，它会获得另一个 IP 地址。所有现有的 TCP 连接都必须被拆除，并重新启动新的连接。
在过去的几年中，各种研究人员提出了解决此问题的方案。第一种方法是在网络层解决问题。此类解决方案的示例包括 Mobile IP、HIP（主机身份协议）和 Shim6（通过 IPv6 中介实现站点多宿主）。这些网络层解决方案的一个显着缺点是，它们隐藏了地址的所有更改，从而隐藏了 TCP 拥塞控制方案的路径更改。这是低效的，因为拥塞控制方案通过可能会在没有通知的情况下更改的路径发送数据。
另一种可能的解决方案是将多个地址暴露给传输层。这是为 SCTP（流控制传输协议）选择的方法。17 SCTP 是一种备用传输协议，能够支持每个连接多个 IP 地址。SCTP 的第一个版本在故障转移场景中使用了多个地址，但最近的扩展使其能够支持同时使用多个路径。9
不幸的是，除了电话网络中的信令等利基应用外，SCTP 尚未得到广泛部署。原因之一是许多防火墙和 NAT（网络地址转换）盒无法处理 SCTP 数据包，因此只是简单地丢弃它们。另一个原因是 SCTP 向应用程序公开了与套接字 API 不同的 API。这两个因素导致了经典的鸡和蛋问题。网络制造商不在其防火墙中支持 SCTP，因为没有应用程序使用此协议；而应用程序开发人员不使用 SCTP，因为防火墙丢弃 SCTP 数据包。有人试图通过在 UDP（用户数据报协议）之上封装 SCTP 并向应用程序公开套接字接口来打破这种恶性循环，但 SCTP 的广泛使用仍然难以实现。
MPTCP（多路径 TCP）的设计考虑到了这些问题。更具体地说，MPTCP 的设计目标是：15
* 它应该能够为单个连接使用多条网络路径。
* 它必须能够至少与常规 TCP 一样好地使用可用的网络路径，但不会使 TCP 资源匮乏。
* 对于现有应用程序，它必须像常规 TCP 一样可用。
* 启用 MPTCP 不得阻止在常规 TCP 可以工作的路径上的连接。
以下部分描述了 MPTCP 的主要架构原则。在理想的网络中，这些简单的原则应该就足够了。不幸的是，鉴于中间盒子的普遍存在，在今天的互联网中情况并非如此，稍后将对此进行解释。
架构原则
应用程序通过常规套接字 API 进行交互，MPTCP 管理用于传输实际数据的底层 TCP 连接（称为子流6）。从架构的角度来看，MPTCP 充当套接字接口和一个或多个 TCP 子流之间的垫片层，如图 1 所示。MPTCP 需要端主机之间进行额外的信令。它通过使用 TCP 选项来实现以下目标
* 建立新的 MPTCP 连接。
* 向 MPTCP 连接添加子流。
* 在 MPTCP 连接上传输数据。
MPTCP 连接是通过使用带有 TCP 选项的三次握手来协商其使用而建立的。在 SYN 段中的MP_CAPABLE选项指示客户端支持 MPTCP。此选项还包含用于安全目的的随机密钥。如果服务器支持 MPTCP，则它会回复一个 SYN+ACK 段，该段也包含MP_CAPABLE选项。此选项包含服务器选择的随机密钥。三次握手的第三个 ACK 也包含MP_CAPABLE选项，以确认 MPTCP 的使用以及启用无状态服务器的密钥。
图 2 中所示的三次握手在一个接口上创建了第一个 TCP 子流。为了使用另一个接口，MPTCP 使用三次握手在该接口上建立一个子流。向现有 MPTCP 连接添加子流需要对应的 MPTCP 连接在每个端主机上都是唯一标识的。对于常规 TCP，TCP 连接始终使用元组<源 IP 地址, 目标 IP 地址, 源端口, 目标端口>.
不幸的是，由于 NAT 的存在，客户端上使用的地址和端口号可能与暴露给服务器的地址和端口号不同。尽管在每台主机上，4 元组都是每个 TCP 连接的唯一本地标识，但此标识并非全局唯一。MPTCP 需要能够将每个子流链接到现有的 MPTCP 连接。为此，MPTCP 为每个连接分配一个本地唯一令牌。当向现有 MPTCP 连接添加新子流时，SYN 段的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）的效果。在这种情况下，MPTCP 将使用高达瓶颈容量的 85%，从而有效地使常规 TCP 资源匮乏。已经设计了特定的 MPTCP 拥塞控制方案来解决此问题。10,18 简而言之，它们测量每个子流上的拥塞，并尝试将流量从拥塞最严重的子流移开。为此，它们根据拥塞程度调整每个子流上的 TCP 拥塞窗口。此外，不同子流上的拥塞窗口是耦合的，以确保它们的聚合增长速度不超过单个 TCP 连接。图 5 显示，OLIA 拥塞控制方案10 在共享瓶颈上保持了与常规 TCP 的公平性。
魔鬼在细节中：中间盒子
今天的互联网与最初设计 TCP 的网络完全不同。这些网络遵守端到端原则，这意味着网络由交换机和路由器组成，它们转发数据包，但从不更改其内容。现在，除了这些路由器和交换机之外，互联网还包含各种中间盒子。最近的一项调查显示，企业网络通常包含比常规路由器更多的中间盒子。16 这些中间盒子不仅包括经典的防火墙和 NAT，还包括透明代理、虚拟专用网络网关、负载均衡器、深度包检测器、入侵检测系统和 WAN 加速器等设备。许多这些设备处理，有时甚至修改 TCP 标头，甚至通过 TCP 段的有效负载。处理这些中间盒子一直是设计 MPTCP 协议中最困难的挑战之一，以下示例说明了这一点。6,7,15
接收端在 TCP 子流上接收到数据后，必须知道数据序列号才能在将数据流传递给应用程序之前对其进行重新排序。一种简单的方法是在每个段内的 TCP 选项中包含数据序列号。不幸的是，这种干净的解决方案不起作用。互联网上部署了一些分割段的中间盒子。特别是，所有现代 NIC（网络接口卡）在执行 TSO（TCP 分段卸载）时都充当段分割中间盒子。这些 NIC 将单个段分割成更小的片段。在 TSO 的情况下，CPU 周期从操作系统卸载到 NIC，因为操作系统处理更少、更大的段，这些段由 NIC 分割成 MTU（最大传输单元）大小的段。大型段的 TCP 选项（包括 MPTCP 数据序列号）被复制到每个较小的段中。因此，接收端将收集多个具有相同数据序列号的段，并且无法正确重建数据流。MPTCP 设计人员通过在数据序列选项中放置一个映射来解决此问题，该映射定义了数据序列号的开始（相对于子流序列号）和结束（指示映射的长度）。因此，MPTCP 可以跨段分割中间盒子正确工作，并且可以与使用 TCP 分段卸载以提高性能的 NIC 一起使用。
在 Linux 内核中使用第一个 MPTCP 实现进行测量时，揭示了另一种类型的中间盒子。由于该实现实验室中运行良好，因此已将其安装在远程服务器上。第一个实验令人失望。MPTCP 连接已建立，但无法传输任何数据。相同的内核在实验室中运行完美，但没有人能理解为什么更长的延迟会阻止数据传输。罪魁祸首原来是一个本地防火墙，它正在更改所有 TCP 段的序列号。几年前，在防火墙中添加了此功能，以防止不使用随机初始序列号的主机出现安全问题。从某种意义上说，防火墙正在修复旧 TCP 堆栈中的安全问题，但在尝试解决此问题的过程中，它又创建了另一个问题。从子流序列号到数据序列号的映射是错误的，因为防火墙修改了前者。从那时起，数据序列选项中的映射使用相对于初始序列号的相对子流序列号，而不是使用绝对序列号。6
因此，数据序列选项准确地将子流序列空间中的每个字节映射到数据序列空间，从而允许接收端重建数据流。某些中间盒子可能仍然会干扰此过程：修改段有效负载的应用程序级网关。规范的例子是主动 FTP。FTP 使用多个 TCP 连接，这些连接通过在控制连接上交换 ASCII 编码的 IP 地址作为命令参数来发出信号。为了支持主动 FTP，NAT（网络地址转换）盒必须修改客户端主机以 ASCII 格式发送的私有 IP 地址。这意味着不仅要修改有效负载的内容，有时还要修改其长度，因为 NAT 设备的公共 IP 地址可能具有不同的 ASCII 表示形式长度。有效负载长度的这种变化将使从子流序列空间到数据序列空间的映射不正确。MPTCP 甚至可以处理此类中间盒子，这要归功于保护每个映射有效负载的校验和。如果应用程序级网关修改了有效负载，则校验和将被破坏；MPTCP 将能够检测到有效负载更改，并无缝回退到常规 TCP，以保持主机之间的连接。
几位研究人员更详细地分析了这些中间盒子的影响。一项研究使用超过 100 条互联网路径的活动测量来检测各种形式的中间盒子的普遍程度。8 测量结果表明，协议设计者在设计 TCP 扩展时不能再假设互联网是透明的；并且没有任何 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 当用户看着屏幕时（例如，在等待网页时），通过组合两个接口来提高下载速度可以减少显示屏的使用，从而降低能耗。
作为说明，让我们分析 MPTCP 在真实 Wi-Fi 和 3G 网络中的运行情况。该场景很简单，但代表了许多情况。用户在建筑物内通过 Wi-Fi 开始下载，然后移动到室外。当用户移动时，Wi-Fi 连接丢失，但由于 MPTCP，数据传输不受影响。图 6 显示了使用 3G 和 Wi-Fi 收集的典型 MPTCP 跟踪。x 轴显示自数据传输开始以来的时间，而 y 轴显示传出数据包的序列号的演变。
对于此传输，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 连接的演变。在前七秒钟内，MPTCP 完美地聚合了 Wi-Fi 和 3G 接口。MPTCP 吞吐量是两个接口吞吐量的总和。然后，一些数据包在 Wi-Fi 接口上丢失。灰色曲线上的第一个垂直条对应于在恢复这些丢失之后接收到的第一个确认。当 Wi-Fi 接口较弱时，MPTCP 吞吐量随接口质量而变化，但数据传输继续进行。从性能的角度来看，这种快速利用可用接口的能力是 MPTCP 的一个主要优势。
提高数据传输性能不是智能手机上 MPTCP 的唯一用例。13 也可以仅使用 3G 接口作为备份，而不是同时启用 Wi-Fi 和 3G 接口。当 Wi-Fi 接口处于活动状态时，所有数据都通过它发送。如果它变为非活动状态，MPTCP 会自动切换到 3G 接口以继续数据传输，并在 Wi-Fi 接口恢复后立即停止使用它。
另一个可能的用例是 802.11 社区网络。许多城市现在都覆盖着大量用户可访问的 Wi-Fi 接入点。3 这些接入点的密度使得慢速移动的用户可以主要依靠 Wi-Fi 进行互联网访问，并依靠 MPTCP 在从一个接入点移动到另一个接入点时保持连接。
智能手机用例促使 Apple 在 iOS 7 中实现了 MPTCP。在撰写本文时，MPTCP 在 iOS 7 上尚不可通过套接字 API 使用，仅用于支持 Siri 语音识别应用程序。也可以在某些最新的已 root 的 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 向远程主机宣告其他可用的 IP 地址，并且将在这些接口上建立子流。
一旦建立这些子流，MPTCP 拥塞控制方案将动态地将负载分散在可用接口上。如果一个接口或任何中间交换机发生故障，MPTCP 会自动切换到其余路径。
请注意，与现有的负载均衡解决方案相比，MPTCP 使用的接口不需要具有相同的带宽。这使得 MPTCP 即使对于单个数据流，也可以通过将负载分布在所有接口上来提高吞吐量。实际上，前面描述的 MPTCP Linux 内核实现11 允许在两台高端服务器之间进行内存到内存传输，每台服务器都配备了六个 10 Gbps 接口。MPTCP 能够有效地利用六个接口的容量，并为单个连接实现了 53 Gbps 的速度。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（第七个研究框架计划）项目 Trilogy、CHANGE 和 Trilogy 2；Google 的捐赠；以及 Bestcom IAP 的支持。
参考文献
1. Benson, T., Akella, A., Maltz, D. A. 2010. Network traffic characteristics of data centers in the wild. In Proceedings of the 10th SIGCOMM Conference on Internet Measurement (IMC).
2. Carroll, A., Heiser, G. 2010. An analysis of power consumption in a smartphone. In Proceedings of the Usenix Annual Technical Conference (USENIXATC).
3. Castignani, G., Blanc, A., Lampropulos, A., Montavont, N. 2012. Urban 802.11 community networks for mobile users: current deployments and prospectives. Mobile Networks and Applications 17(6): 796-807.
4. Davis, T., et al. 2011. Linux Ethernet bonding driver how-to; https://linuxkernel.org.cn/doc/Documentation/networking/bonding.txt.
5. Eardley, P. 2013. Survey of MPTCP implementations. Internet draft, work in progress; http://tools.ietf.org/html/draft-eardley-mptcp-implementations-survey-02.
6. Ford, A., Raiciu, C., Handley, M., Bonaventure, O. 2013. TCP extensions for multipath operation with multiple addresses. RFC6824; http://www.rfc-editor.org/rfc/rfc6824.txt.
7. Hesmans, B., Duchene, F., Paasch, C., Detal, G., Bonaventure, O. 2013. Are TCP extensions middlebox-proof? In Proceedings of the 2013 Workshop on Hot Topics in Middleboxes and Network Function Virtualization (Hot-Middlebox).
8. Honda, M., Nishida, Y., Raiciu, C., Greenhalgh, A., Handley, M., Tokuda, H. 2011. Is it still possible to extend TCP? In Proceedings of the SIGCOMM Internet Measurement Conference (IMC).
9. Iyengar, J. R., Amer, P. D., Stewart, R. 2006. Concurrent multipath transfer using SCTP multihoming over independent end-to-end paths. IEEE/ Transactions on Networking 14(5): 951-964.
10. Khalili, R., Gast, N., Popovic, M., Upadhyay, U., Le Boudec, J.-Y. 2012. MPTCP is not Pareto-optimal: performance issues and a possible solution. In Proceedings of the 8th International Conference on Emerging Networking Experiments and Technologies (CoNEXT).
11. Paasch, C., Barré, S., Detal, G., Duchene, F. 2014. Linux kernel implementation of Multipath TCP; http://multipath-tcp.org.
12. Paasch, C., Detal, G., Barré, S., Duchene, F., Bonaventure, O. 2013. The fastest TCP connection with MultiPath TCP; http://multipath-tcp.org/pmwiki.php?n=Main.50Gbps.
13. Paasch, C., Detal, G., Duchene, F., Raiciu, C., Bonaventure, O. 2012. Exploring mobile/Wi-Fi handover with Multipath TCP. In Proceedings of the SIGCOMM workshop on Cellular Networks: Operations, Challenges, and Future Design (CellNet).
14. Raiciu, C., Barré, S., Pluntke, C., Greenhalgh, A., Wischik, D., Handley, M. 2011. 通过多路径 TCP 提高数据中心性能和鲁棒性。《 SIGCOMM 计算机通信评论》41(4): 266-277。
15. Raiciu, C., Paasch, C., Barré, S., Ford, A., Honda, M., Duchene, F., Bonaventure, O., Handley, M. 2012. 有多难？设计和部署可部署的多路径 TCP。载于第 9 届网络系统设计与实现研讨会 (NSDI) 会议论文集。
16. Sherry, J., Hasan, S., Scott, C. Krishnamurthy, A., Ratnasamy, S., Sekar, V. 2012. 将中间盒变成别人的问题：作为云服务的网络处理。《 SIGCOMM 计算机通信评论》42(4): 13-24。
17. Stewart, R. Xie, Q. 2001. 流控制传输协议 (SCTP)：参考指南。 Addison-Wesley 出版社。
18. Wischik, D., Raiciu, C. Greenhalgh, A., Handley, M. 2011. 多路径 TCP 的拥塞控制的设计、实现和评估。载于第 8 届 Usenix 网络系统设计与实现研讨会 (NSDI) 会议论文集。
喜欢还是讨厌？请告诉我们
Christoph Paasch 是天主教鲁汶大学（比利时鲁汶-拉讷夫）的博士生，他在那里领导 Linux 内核中多路径 TCP 的开发。
Olivier Bonaventure 是天主教鲁汶大学（比利时鲁汶-拉讷夫）的教授，他在那里领导网络研究小组。他的研究重点是互联网协议。他撰写了一本开源网络教科书，并且是 SIGCOMM 的教育主管。
© 2014 1542-7730/14/0200 $10.00
最初发表于 Queue vol. 12, no. 2—
在 数字图书馆 中评论本文
更多相关文章
David Collier-Brown - 你不了解带宽
当您的员工或客户说他们的互联网性能很差时，带宽可能不是问题。一旦他们拥有大约 50 到 100 Mbps 的带宽，问题就变成了延迟，即 ISP 的路由器处理他们的流量需要多长时间。如果您是一家 ISP，并且所有客户都讨厌您，请振作起来。现在，由于一群致力于此的个人，这个问题已经可以解决了，他们找到了问题，解决了问题，然后在家庭路由器中验证了他们的解决方案。
Geoffrey H. Cooper - 使用 FDO 和非信任安装程序模型的设备入职
设备的自动入职是处理正在安装的越来越多的“边缘”和 IoT 设备的重要技术。设备的入职与大多数设备管理功能不同，因为设备的信任从工厂和供应链转移到目标应用程序。为了通过自动入职来加速该过程，供应链中的信任关系必须在设备中正式化，以允许自动化过渡。
Brian Eaton, Jeff Stewart, Jon Tedesco, N. Cihan Tas - 通过关键路径跟踪进行分布式延迟分析
低延迟是许多 Google 应用程序（例如搜索）的重要功能，而延迟分析工具在维持大规模低延迟方面起着至关重要的作用。对于复杂的分布式系统（包括功能和数据不断发展的服务），将总体延迟保持在最低水平是一项具有挑战性的任务。在大型、真实的分布式系统中，现有的工具（例如 RPC 遥测、CPU 性能分析和分布式跟踪）对于理解整个系统的子组件很有价值，但不足以在实践中执行端到端延迟分析。
David Crawshaw - 一切 VPN 焕然一新
VPN（虚拟专用网络）已有 24 年的历史。这个概念是为与我们今天所知的互联网截然不同的互联网而创建的。随着互联网的增长和变化，VPN 用户和应用程序也随之发展。在 2000 年代的互联网中，VPN 经历了尴尬的青春期，与其他广泛流行的抽象概念交互不良。在过去的十年中，互联网再次发生了变化，而这个新的互联网为 VPN 提供了新的用途。一种全新的协议 WireGuard 的开发为构建这些新 VPN 提供了技术基础。
© 保留所有权利。