千兆TCP拥塞控制算法分析
作者：Geoff Huston，APNIC
回顾30多年来的互联网从业经验，我发现：促使互联网协议套件成功地成为全球通信系统首选技术的关键，是互联网协议（IP）本身。作为一种重叠协 议，它能够支持几乎任何类型的通信介质。但是我还想指出IP中另外一个重要的角色，即位于IP之上的可靠传输协议－－传输控制协议（TCP）。我之所以认 为它如此重要，是因为TCP所采用的端到端速率自适应控制算法，与同时代的其他类似协议所使用的可靠网关间虚拟电路流控制系统存在着真正的、根本性的差 异。另一点需要指出的是，TCP并没有针对任何特定的速度而设计，但是它支持一种能够平等地使用网络路径上所有可用网络容量的速度。TCP流控制算法的基 本特点在于，它试图在提供最大限度的效率的同时，保持最大限度的公平性。
关于这个主题，此前发表的文章“TCP性能”[12]和“TCP的未来”[13]主要着眼于TCP的设计原理和性能特征。TCP的核心特征是，它试 图与其他并发进程建立起一种动态的平衡，并且尽量利用各种机会，充分使用所有可用的网络容量。为此，它所采用的手段包括：不断地调节流特性；不断地检测网 络，看其能否支持更高的速度；同时随时准备在收到的网络信号发生拥塞时，立即降低当前的发送速率。
在今天的世界中，网络基础设施的容量和复杂性与网络成本息息相关，而所发送的数据则关系到网络收入，而TCP仍然可以很好地满足人们在两方面的要 求。因为TCP对于网络组件的功能要求最低，所以让人们能够利用简便的传输功能和交换系统构建网络。“简便”往往意味着低价和便于扩展，而这里也不例外。 TCP还试图通过自适应的端到端流速率控制和谨慎的重发事件管理，最大限度地提高数据传输效率。换句话说，TCP是供应商和消费者获得更加廉价的网络的重 要手段。对于消费者而言，快速廉价的通信服务将会极大地促进他们对于互联网服务的需求；而这一直是推动互联网本身进一步普及的主要动力――其作用远远超出 其他因素。“廉价”在当今世界也具有极为重要的作用，而TCP肯定有助于提高数据通信的效率和降低通信成本。
尽管TCP在很多网络环境中具有很高的效率，但是这并不意味着它在每个环境中都是如此。例如：
- 在那些存在严重无线噪声的无线环境中，TCP可能会将因为基于射频的信号中断与相应的分组丢弃而造成的后果与网络拥塞造成的后果相混淆，导致TCP会话过早、过久地降低发送速率。
- 在网络路由器的缓冲空间不足时，TCP也会过早地降低速率。这种影响较为隐蔽，但是它关系到TCP算法 的粗糙性和TCP分组队列的突发性。这些两倍于网络容量速率的突发流量可以通过网络缓冲得到缓解。如果网络内部的缓冲被消耗殆尽，将会导致分组丢弃，为当 前的TCP信号产生一个中断信号，进而使其发送速率降低一半，或者――在最差情况下――重设会话状态和重新启动分组交换。特别是在广域网中，端到端的延迟 －带宽产品成为了一个重要的影响因素，因而TCP会利用网络缓冲保持与可用网络容量相符的稳定吞吐率。如果内部缓冲容量不足，就无法保持TCP队列的平稳 传输，也不能让数据以可用数据速率连续地流过受限节点。
- TCP还需要它的终端主机拥有与转发和反向路径上的可用网络容量相等的本地容量。原因是，TCP不会在远端发出可靠的确认消息之前丢弃数据，因此发送主机必须在发送数据和远端发出相应的确认期间，保持数据的一个复本。
即使考虑到这些限制，我们仍然可以肯定地说：TCP在大部分环境中都能发挥重要的作用。虽然如此，我们发现TCP在一个领域面临着相当艰巨的挑战，那就是广域的、超高速的数据传输。
超高速 TCP
目前，终端计算机――即使是笔记本电脑――通常都配备 了千兆以太网接口，并且具有GB级的内存，以及能够在内存和网络接口之间每秒传输千兆级数据的内部数据通道。目前的IP网络是利用千兆级通道，高容量交换 机和路由器（假定这两种分组交换设备之间存在着定量的区别）等构建而成的。如果终端主机和网络都能够支持千兆传输，那么TCP会话就应当能够端到端地以每 秒千兆数据的速度运行，在千兆速度下获得与百兆速度下相同的效率――是这样吗？
事实并非如此！
这个结论并不明显，特别是在考虑到当今的TCP陆地速度最高记录时：在3万公里的网络距离内，达到大约7Gbps。那么，事实到底怎样呢？
下面，让我们根据TCP的基本原理，了解超高速TCP所带来的一些变化。TCP工作在两种状态之下：缓慢启动和拥塞避免。
- 与“重启”模式一样，缓慢启动模式是TCP在任何会话中的初始工作模式。在这种模式下，TCP会针对推动发送端窗 口的每个ACK分组，发送两个分组。简而言之（即使是对于延迟ACK），这种模式让TCP能够在每次连续的无丢包往返时间（RTT）间隔中，将发送速率提 升一倍。速率的提升是指数式的，会在每个RTT间隔中有效地增加一倍；速率提升也是突发性的，可以在此期间以两倍的瓶颈容量将数据发送到网络。
之所以能够以两倍的瓶颈数据速度将数据发送到网络，是因为TCP的“ACK时钟”特性。暂且不考虑复杂的TCP延迟ACK机制，TCP接收端每次在 收到一个分组时会产生一个新的ACK分组。ACK的发送速率实际上与数据分组的接收速率相同。假定采用单向的数据传输方式（以确保反向的ACK分组保持最 小的尺寸），而且从接收端到发送端的反向路径的抖动最小，那么ACK到达发送端的速率与数据分组到达接收端的速率相当。换句话说，ACK的返回速率与从发 送端到接收端的前向网络路径的瓶颈容量相当。因此，通过在每收到一个ACK时发送两个分组，就能够有效地以两倍的瓶颈容量向网络发送分组。在瓶颈点，交换 设备在一段时间内所收到的数据量，将是它能够向输出设备发送的数据量的两倍。这些数据量将取决于瓶颈链路的延迟－带宽特性。因此可以得出这样的结论： TCP是一种突发性的协议，尤其是在启动时。因此，在那些具有充足内存，或者为每个输出端口都设有与该端口所连接链路的延迟－带宽特性大约对应的缓冲容量 的网络交换设备上，TCP可以发挥出更高的效率。
- 另外一种工作模式是拥塞避免。在这种模式下，TCP会在每个无丢包的往返时间间隔发送一段额外的数据。这种提升是附加的，而不是指数式的，会以每个RTT间隔增加一个衡定数据段的方式，提高发送端的传输速率。
图 1 ： TCP行为
缓慢启动（在每个RTT间隔中将速率提升一倍）
队列饱和点
在速率超过可用容量时开始排序
拥塞避免（在每个RTT间隔中以一个固定的幅度提升速率）
时间
但是，如果两个位于大陆两端的系统之间存在一条高速的路径，会发生什么情况？单个TCP会话需要多长时间才能达到10Gbps的传输速率？单个会话能否持续地以10Gbps的速率运行？
下面让我们来看看这样一个情况：网络路径从位于澳大利亚大陆东侧的布里斯班延伸到位于西侧的珀斯。网线实际上沿着澳大利亚大陆的南海岸铺设，因此 RTT延迟为70ms。这意味着每秒存在14.3个往返间隔。假定所使用的分组大小为1500字节，即12000比特，而且TCP初始窗口的大小为单个分 组。另外，假定布里斯班到珀斯的主机间瓶颈容量为10Gbps。
在简单的缓慢启动模式下，发送速率每70ms提升一倍，因此在17个RTT间隔之后（期间发送速率每经过一个间隔就增加一倍），或者在大约1.2秒 钟之后，传输速度就会达到11.2Gbps（假定这个主机拥有足够快的硬件组件，足够快的内部数据路径，以及充足的内存）。在这个阶段，假定发送速率超过 了网络路径的瓶颈点的缓冲容量。这时将会发生丢包，因为网络路径中的缓冲已经达到了饱和。
在收到一个表示分组丢失的ACK序列时，TCP发送端的拥塞窗口将会减小一半，TCP发送速率也会降低一半，同时TCP将切换到拥塞避免模式。在拥 塞避免模式下，速率提升幅度为每个RTT增加一个数据段，相当于每个RTT增加12kb；或者，根据上面设定的会话参数，就相当于每个RTT间速率增加 171kbps。那么，TCP将需要多长时间来恢复正常，将发送速率增加到10Gbps呢？
那么，我们的10Gbps连接怎么样呢？首先要估计的是交换组件中的可用缓冲容量。假定在队列达到饱和之前，网络路径上的可用队列容量为 256MB，那么工作在拥塞避免模式下的TCP会话将会在达到最高传输速率（即10Gbps）之后的大约590个RTT间隔（或者大约41秒之后）发生丢 包。这时，处于拥塞避免模式下的TCP的发送速率为10.1Gbps。在实用情况下，TCP拥塞避免模式会在5.0Gbps到10.1Gbps之间，导致 这种理想的TCP会话产生锯齿式振荡。单个锯齿振荡周期长为2062秒，即34分钟22秒。这意味着网络必须在几十分钟内（或者在传输数十亿个分组期 间），在网络路径上稳定地保持无丢包运行，而且相应的传输比特错误率低于10-14。它还意味着这种方式能够传输庞大的数据集，因为在一个TCP拥塞避免 周期中传输的数据量高达1.95TB（即1.95×1012字节）。这也表明，TCP会话无法充分地利用可用的网络带宽，因为在这些情况下的平均数据传输 速率为7.55Gbps，而不是10Gbps（参见图2）。
图 2 ： 高速时的TCP行为
TCP拥塞参数（RTT 700ms，1500 MSS，10Gbps，256Mb队列）
速率（Gbps） 缓慢启动（1.2s）
拥塞避免周期（34分钟）
时间（小时）
显然，在这种情况下会出现一些意外，因为要用数据填满一条远程的、高容量的线路看起来肯定是一项困难的、漫长的任务，而且TCP无法发挥预期的作用。尽管寻找TCP的传输极限本身是一个有趣的研究领域，但是这种高速传输的确产生了很多实际的问题。
一个经常被人提及的、令人影响深刻的例子是CERN建造的大型强子对撞机。
“位于瑞士日内瓦的CERN粒子物理实验室成功地在欧洲的七个国家和美国之间，连续十天以平均每秒600M字节的速度传输一个数据流。它是我们对在 CERN建设的大型强子对撞机进行的一项重要的计算基础设施测试。LHC将成为有史以来建设的、数据量最大的物理仪器，它会在10年或者更长的时间里，每 秒钟产生1500MB的数据。”
―― 新科学人杂志， 2005 年 4 月 30 日
TCP 和陆地速度记录
TCP 陆地速度纪录最初是一项为了在IP网络中实现破纪录的TCP传输速度而开展的非正式项目。在20世纪80年代末和90年代初，人们取得了很多值得关注的里 程碑式成果，特别是Van Jacobson曾经设法实现了持续的10Mbps和45Mbps TCP传输速度。
这个项目已经被加入到了Internet2计划之中。该计划为TCP陆地速度的测试制定了一些正式的规则。特别需要指出的是，这些规则现在确定了时 间、距离和TCP限制，而且要求使用实际网络。最近几年这个纪录被频频打破。截止到2006年5月，IPv4单数据流传输的最高纪录是一个在长达3万公里 的光纤路径上，连续30分钟保持7.21Gbps速率的TCP会话。
TCP的陆地速度纪录表明，让TCP在很高的速度下保持持续的间隔肯定是可能的，但是这里必须要注意一些细节。要想创造一个新的纪录，必须满足一些前提条件：
- 首先，将所有网络路径归您个人使用是相当必要的――实际上可以说是非常重要。任何形式的丢包都可能产生严重的影响，因此，确保不丢失任何分组的最佳途径是让整个网络路径完全归您个人使用。
- 其次，保持固定的延时也是相当必要的――也可以说是非常重要。如果测试的目标是为了达到稳定的数据传输状态，那么延迟的任何变化――特别是延迟的减少――都可能会导致在一段时间内发送过多的数据，这可能造成丢包的危险。因此，务必尽可能地保持网络的稳定性。
- 第三，在底层传输介质中保持极低的比特错误率相当必要――这一点实际上也非常重要。数据受损会导致校验和错误，进而造成丢包。
- 最后，必须提前获知往返延时和可用带宽。
接下来，您可以将这两个数字（即RTT和带宽）相乘，除以分组尺寸，向下舍入，再让发送TCP会话将该值设为缓冲尺寸，而接收端设置较大的缓冲值。之后，就可以启动会话。
这样做的目的是让TCP在发送端用完缓冲空间之前使用缓慢启动。一旦缓冲空间用完，只要发送端、接收端和网络路径全部处于稳定状态，TCP将继续保 持这种缓冲速度。对于使用70ms RTT的10Gbps系统而言，如果将缓冲极限设为11.6万个分组，那么TCP会话将以9.94Gbps的速度运行。只要延时保持稳定（即没有抖动）， 而且没有比特错误和不存在其他的交叉流量，那么在理论上这样的发送速率将能够无限地保持下去，并具有稳定的数据分组流和稳定的ACK分组流。
当然，这种情况会受到很多实际条件的限制。TCP协议面临的实际问题是，它与很多其他的会话共享网络路径的方式和它占据可用网络容量的能力。换句话 说，人们希望看到的是一个高速、高容量的TCP版本，它应当能够在网络上与其他类型的流量共存。人们更希望，高速的TCP版本能够在平等地与其他流量会话 共享网络资源的同时，最大限度地利用网络资源。TCP目前存在的问题是，在运行于高速的跨大陆级网络路径中时，它为了恢复持续的运行操作而在定量递增模式 （即拥塞避免模式）下花费了过长的时间。如果我们想要获得高效率的超高速TCP，就需要设法改变TCP的高速运行方式。
高速 TCP
目前，可以通过两种方法实现高速TCP：现有TCP的并行化，或者通过改变TCP特性，在单个TCP流中允许更快的加速速率。
利用并行TCP流提高TCP性能的方法已经存在了相当长的时间。例如，最初的HTTP规范允许使用并行的TCP会话下载网页的各个部分（不过 HTTP 1.1改用了连续下载模式，因为在这种情况下，会话启动的开销似乎超过了并行TCP会话所带来的好处）。另外一种通过并行化实现高速文件传输的方法是网格 FTP（GRID FTP）。它的基本原理是将通信载荷分解为大量独立的部分，并同时发送所有这些部分。每个传输部分可以位于两个终端之间（例如网格FTP），也可以分散在 多个终端之间（例如BitTorrent）。
但是，为了让并行TCP正确运行，我们需要事先汇总所有数据（或者至少知道所有数据部分所在的位置）。在实时产生大量数据的情况下（例如天文台或者 粒子对撞机），只能将数据集视为一个连续的数据流，并利用一个高速的传输协议来分发它。这时的任务将是调节TCP的基本控制算法，让其不仅能够以高速运 行，还能够“公平地”在一个存在多种流量的高速网络中运行。
并行 TCP
利用并行技术提高速度是一种常见的计算技术，并且存在于 很多超级计算机架构之中。它也可以用于数据传输，即将一个数据集划分为大量较小的数据块，每个数据块通过单独的TCP会话发送。这时的基本机制是，在使用 一定数量（例如N个）并行TCP会话时，单个丢包事件很可能会导致N个会话中最快会话的速率降低一半，这是因为最快的会话在网络中传输的数据较多，因而最 有可能受到丢包事件的影响。该会话随后将利用拥塞避免速率提升方法来进行恢复，这意味着单个丢包事件会导致发送速率最高降低1/(2N)。例如，在使用五 个并行会话时，单个丢包事件会导致总发送速率降低1/(2×5)，即1/10；相比之下，在使用单个TCP会话时，单个丢包事件会将发送速率降低1/2。
图3显示了在一个10Gbps会话中模拟五个并行会话的情况。
图 3 ： 并行TCP模拟：单个与多个数据流的对比
速率（Gbps） 并行数据流的总和
单个数据流
各个数据流
时间（小时）
汇总数据流的本质特征是，在无丢包情况下，N个并行会话的数据流的速率提升速度会比处于拥塞避免模式的单个会话高N倍。对于孤立丢包事件的响应为单 个数据流的速率降低一半，因此在理想条件下的总体数据流速率介于R和R×（2N-1）/2N之间，或者长期平均吞吐率为R×（2N-1）/2N。对于理想 的10Gbps连接，可能会实际工作在9.9Gbps。
当然，实践与理论存在偏差。人们已经对并行TCP在不同条件下的性能进行了大量的研究，尝试采用最大限度提高吞吐率和选择最有效的并行有效数据流数 量等手段进行优化。一部分问题在于，尽管简单的模拟――例如用以生成图4的模拟――可能会通过均分每个并行会话来获得最大限度的吞吐率，但是各个会话很有 可能是自动同步的。因为并行会话存在类似的窗口尺寸范围，所以在某个特定的时间点，每个数据流在网络路径中发送的分组数可能会十分接近。如果丢包事件是一 个多包丢失事件，例如一个尾部丢弃队列，那么很有可能发生多个并行数据流同时丢包的情况，这样数据流可能会变得同步。
图4显示了两种极端情况――多个数据流完全均分和严格同步。同步的并行数据流的平均吞吐率与单个数据流在模拟期间的平均吞吐率相同，但是两者都远远低于一组均分的并行数据流。
图 4 ： 并行TCP的对比：同步和均分的数据流
速率（Gbps） 均分并行数据流的汇总
同步并行数据流的汇总 单个数据流
时间（小时）
解决这个问题的方法之一是重新将这些并行数据流汇集成一个受控的数据流，而且这个数据流具有与等分的并行数据流相同的特性。下一节将探讨这种名为MulTCP的方法。
如果上面这些对并行TCP流的讨论有些偏理论化，似乎与今天的网络缺乏联系，那么有必要指出，很多互联网服务供应商（ISP）目前都将 BitTorrent流量视为他们的最高量应用。BitTorrent是一种点对点应用，利用一种高度并行的传输技术进行数据集的传输。在 BitTorrent中，原始的数据集会被分解为多个数据块，每个数据块都能够并行下载。它的独特之处在于，各个会话并不需要具有相同的来源，而主机能够 同时从多个不同的来源获取“种子”，以及将其自身作为它已经下载的数据块的供应点。这种机制充分发挥了这些网络在点对点方面的潜力，不仅能够通过并行 TCP会话提高速度，还能够借助不同的数据路径和数据源，避免单个路径发生拥塞。考虑到BitTorrent在最大限度提高高量数据集传输速度方面的效 率，以及它在真正发掘点对点网络潜力方面所取得的成功，以及人们对BitTorrent的广泛接受和它的普及，BitTorrent可能很值得我们进行进 一步的研究，但是我们将在一篇单独的文章中加以探讨。
超高速串行 TCP
另外一种通用的方法是重新分析现有的TCP控制算 法，看看能否通过修改参数或者算法，让TCP在这些高容量、长延迟的网络路径中获得更高的速率。这样做的目的是实现一种出色的拥塞处理算法，它不仅不会加 剧持续故障区域的暂时拥塞，而且还能够支持高速的数据传输，从而有效地使用所有可用的网络容量。
我们还希望TCP能够在面临其他TCP会话时采取适当的对策，从而平等地与其他TCP会话共享网络资源。
MulTCP
第一种这样的方法是MulTCP，即采用行为类似于N个并行TCP会话的单个TCP数据 流。它通过均分虚拟会话，实现最优的吞吐率。它对TCP的实质改动体现在拥塞避免模式和丢包事件的处理方面。在拥塞避免模式下，MulTCP会以每个 RTT增加N个数据段的方式扩大拥塞窗口，而不是像缺省设置那样只增加单个数据段。在发生丢包时，MulTCP会将它的窗口缩小W/(2N)，而不是缺省 的W/2。MulTCP采用的缓慢启动模式也与缺省模式有所不同――它会在每收到一个ACK时为窗口增加三个数据段，而不是缺省的两个。
MulTCP只对TCP进行了简单的改动，并没有彻底地改变TCP的拥塞控制算法。当然，选择最佳的N值时，对网络特性 有所了解将会有所帮助。如果N值过高，MulTCP会话可能会占据过高的网络容量；但是如果该值过低，该会话可能就无法充分利用可用的网络容量。图5对比 了同等数量的并行TCP数据流和单个TCP数据流的速率（在这个模拟中，N=5）。
图 5 ： MulTCP
MulTCP模拟（N=5）
速率（Gbps） MulTCP 单个TCP数据流
时间（小时）
尽管如此，我们仍然会觉得存在进一步改进的空间：最好不需要设置虚拟并行会话的数量；最好能在多种带宽上，在与其他并发TCP会话竞争时支持公平的资源分配；最好能够拥有丰富的扩展属性。
目前在为满足这些需要而调节TCP的不同特性方面，存在着多种不同的手段――从修改TCP的速率控制机制，到将网络负荷视为功率谱问题。
高速 TCP
“针对大型拥塞窗口的高速TCP”[2]一文提出的另外一种方法是从TCP速率机制的角度解决这个问题。这种方法是由ICIR的Sally Floyd发明的。
当TCP以平均每个RTT传输W个分组的速度工作于拥塞避免模式时，每个RTT的分组数会在(2/3)W和(4/3)W之间波动。因为每个周期包含 (2/3)W个RTT间隔，所以每个周期的分组数就为(2/3)W2个分组。这个结果意味着只要丢包率为每个周期丢失一个分组，那么速率就能保持为每个 RTT W个分组，即丢包率
。求解这个公式中的W，就能达到每个RTT的平均分组速率为：
。因此，TCP的通用速率公式为：
，其中MSS是TCP分组的尺寸。
对N个并行数据流采取同样的速率公式，会得到什么结果？理想的结果是，在丢包率相同的情况下，并行数据流的速度要快N倍；或者，用速率公式表示每个RTT的分组数WN，那么可以得到：
，而每个TCP周期缩短为一个值为
的间隔。
但 是，用户所需要的可能并不是将TCP的速率提升固定的倍数（N）――就像MulTCP所做的那样，而是在丢包率下降时，通过提高N值自动地提高发送速率。 高速TCP的目的是利用一个TCP响应函数，保持发送速率的对数与丢包率的对数之间的固定关系，但是改变函数的斜率，以便让TCP能够在丢包率下降时提高 它的拥塞避免增量。图6显示了这种关系，它对比了发送速率的对数和丢包率的对数。MulTCP在发送速率的对数和丢包率的对数之间保持了相同的关系，但是 改变了函数的截距；不过，丢包率指数值的变化会在速率等式中产生不同的斜率。
图 6 ： TCP响应函数
发送速率，每秒分组数
高速TCP
丢包率 高速TCP方案的工作机理类似于引擎中的涡轮增压器；引擎的运转速度越快，涡轮增压器对引擎正常性能的提升幅度越高。在某个特定的阈值以下，TCP拥塞避 免函数不会发生变化。但是当丢包率降低到某个特定阈值以下时，就会调用速度更快的拥塞避免算法。高速TCP方案所提出的高速数据等式建立在以下基础上：以 1000万个分组丢失一个分组的丢包率，在100ms延迟路径上实现10Gbps的传输速率。通过这些参数逆推，可以得到W（即每个RTT间隔的分组数） 的速率等式：
，其效果近似等于一个并行会话数量（N）随着TCP速率提升而增加的MulTCP会话。二分提升拥塞控制（BIC）[4]采用了一种独特的方法，即假定TCP在主动搜索一个处于丢包触发阈值上的分组发送速率，再利用一个二分搜索算法有效地达到这个速率。
在BIC因为发生丢包事件而缩小窗口时，它会遵循以前的最大窗口尺寸和当前的窗口设置。在每个无丢包RTT周期中， BIC都会试图用当前窗口尺寸和过去最大窗口尺寸之间差额的一半，扩充拥塞窗口。通过这种方式，BIC能够迅速地从此前缩小的窗口尺寸进行恢复。当BIC 接近原先的最大值时，它会减慢窗口扩充速度，在每个RTT中将窗口扩充速率降低一半。这个过程并不像听起来那样剧烈，因为BIC还采用了一个最大扩充常数 来限制速率在任何一个RTT间隔中的变化幅度。这样做的结果是，最终的响应兼具线性和非线性特征，即在窗口缩小之后进行的初步窗口扩充是线性增长；但是当 窗口尺寸达到此前发生丢包时的尺寸时，窗口扩充速率就会减缓。在当前窗口尺寸超过以前发生丢包时的尺寸时，BIC会利用补充的方法扩充窗口。起初，窗口扩 充幅度较小，窗口扩充幅度值会在每个RTT中增加一倍，达到一个限值；在超过该限值时，窗口扩充将更加线性化。
在低RTT网络和低速环境中，BIC可能会过于“积极”，因而人们对BIC进行了进一步的改进，即CUBIC[5]。 CUBIC采用了一个三次多项式函数来支配窗口扩充算法，而不是像BIC那样使用指数函数。三次函数中将从上次缩小窗口以来经过的时间作为变量，而不是像 BIC那样使用一个RTT计数器，这样CUBIC能够在存在多个具有不同RTT的数据流时产生更加公平的结果。CUBIC还会为任何一个RTT间隔中可以 进行的窗口调节幅度设置一个上限，这样在窗口缩小之后进行的窗口尺寸调整将是线性的。在这里，新的窗口尺寸W的计算方法为：
。其中，C是一个恒定扩展参数，t是从上次窗口缩小事件到当前经过的时间；Wmax 表示最近一次缩小前的窗口尺寸。K的计算公式为：
。当窗口尺寸接近过去的窗口尺寸Wmax 时，这个函数会变得更加稳定。在调整窗口尺寸时使用时间间隔而不是RTT计数器的目的是让CUBIC对当前TCP会话更加敏感，特别是在RTT较短的环境中。
图9对比了在相同时间内BIC和CUBIC的调整幅度。这两种算法之间的实质区别在图中表现得非常明显：CUBIC算法在接近过去发生丢包事件的值时，试图减小窗口尺寸的变化幅度。
图 9 ： BIC和CUBIC的窗口调节幅度
窗口尺寸 时间
Westwood
TCP操作的“稳定状态”模式的一个重要特征是速率振荡的“锯齿”模式。加法递增方法的目的是在寻找可行的发送速率的同时，避免因为过快地提高发送速率而导致暂时拥塞事件。TCP在发生丢包事件时采用的倍数递减方法则可以避免在发送路径上发生网络拥塞。
BIC和CUBIC的调整手段都集中于速率提升函数，试图在TCP会话收敛到某个长期可用的发送速率的过程中提供更高的稳定性。另外一个手段是改进倍数递减函数，研究能否让TCP会话利用进一步的信息修改速率递减函数。
Westwood[6]所采取的方法和一种相应的改进方法Westwood+[7]则试图在发生丢包事件（表现为三个重 复的ACK）时，将TCP的拥塞窗口减小一半。通过观察发现，返回的ACK分组流实际上表明了网络路径的当前瓶颈容量。这个结论可以改进传统TCP算法对 拥塞窗口减小一半的方法，并且不断地调整网络路径中的最小RTT。Westwood算法会通过跟踪TCP确认值和ACK分组到达时间间隔，估计网络带宽， 进而估计当前网络路径的瓶颈带宽。这种技术类似于“分组对”方法，在TCP Vegas中得到了应用。就Westwood方法而言，对带宽的估计建立在接收ACK速率的基础上，可以被用于设置拥塞窗口，而不是TCP发送窗口。 Westwood发送端会跟踪最小的RTT间隔，以及根据返回的ACK数据流预测出的带宽。在发生丢包事件时，Westwood不会将拥塞窗口缩减一半， 而是会将其设为估计带宽与最低RTT值的乘积。
如果当前RTT等于最小RTT，那么就意味着整个网络路径上不存在队列延迟，因而发送速率就会被设置为网络路径的带宽。如果当前RTT大于最小RTT，那么发送速率就会被设置为一个低于估计带宽的值，并允许在发生丢包时通过加法递增寻找发送速率阈值。
这里存在的一个重要问题是，ACK间隔时间可能会发生变化，但是Westwood会利用所有可用的数据和ACK对提高对 当前带宽的预测精度。该方法还采用了一个低通滤波器，确保估计带宽在一段时间内保持相对的稳定性。实际的结果是，接收端可能会发生某种形式的ACK失真 （例如延迟的ACK响应），而网络路径会在正向和反向含有抖动组件，这样ACK队列在抵达发送端时，ACK间隔时间存在较大的波动。Westwood+利 用最低测量间隔（选取RTT或者50毫秒之间的较大者）进一步改进了这项技术，以解决因为ACK压缩而导致估计带宽过高的问题。
这样做的目的是确保TCP在缩小拥塞窗口时不会矫枉过正，从而使得与窗口的缓冲扩充速率有关的问题不会影响总体的TCP 性能。这里的关键在于过滤技术，即获取一个存在噪声的测量样本序列，先后用一个抗锯齿滤波器和一个低通离散时间滤波器对该数据流进行滤波，从而得到足够精 确的带宽估计值。这个估计值可以与最小RTT测量值结合，在检测到丢包和对数据流进行快速重发时，设置TCP拥塞窗口尺寸的下限。如果丢包是由网络拥塞导 致的，那么新的设置将低于带宽阈值（按照比例RTTmin/RTTcurrent缩小），以便新的发送速率可以清理在路径上排序的累积流量。如果丢包是因 为介质受损而引起的，那么RTT值将接近最小RTT值。在这种情况下，TCP会话速率的降低幅度就会较小，以便迅速地恢复到以前的数据速率。
但是，这种方法在频繁发生比特级损坏的环境中（例如经常连接无线系统）具有重要的作用。它还适用于长延迟的、高速的 TCP环境。TCP Westwood的速率降低幅度取决于RTTmin/RTTcurrent比例，而不是像传统TCP那样直接降低一半，或者像MulTCP那样采用一个固 定的比例，这使得TCP会话可以使其发送速率达到更加接近可实现带宽的水平，而不是针对每个丢包事件进行影响相对较大的速率降低操作。
H-TCP
H-TCP[9]支持者们发现，通过调整TCP行为，缩短拥塞事 件之间的时间间隔，能够提高TCP在高速网络上的性能。拥塞事件标志着TCP已经用完了它的可用带宽。通过提高这些事件的频率，TCP将能够更加准确地跟 踪这个资源指标。为了实现这种跟踪，H-TCP的支持者认为窗口扩充和缩小函数都可以进行修改，但是在决定以何种方式修改这些函数方面，他们认为关键在于 对其他并发网络数据流的敏感程度，以及向不同的并发数据流稳定分配资源的能力。
“虽然这些改动看起来比较简单，但是实践表明，它们往往会对TCP数据流的网络行为产生不利的影响。高速TCP和BIC -TCP会在网络扰动――例如启动新的数据流――之后表现出极低的收敛速度；可扩展TCP采取了一种倍数递增、倍数递减的策略，因此它在尾部丢弃网络中无 法进行公平的收敛。”
正在开展的工作：draft-leith-tcp-htcp-01.txt
H-TCP主张对窗口控制函数进行最低限度的改动。它认为，为了实现公平性，具有较大拥塞窗口的数据流缩减窗口的绝对幅度应当大于窗口较小的数据流，从而在已经建立的TCP数据流和进入同一条网络路径的新数据流之间建立起动态的平衡。
H-TCP为窗口扩充提出了一种基于计时器的响应函数，即在初期保持现有值（即每个RTT递增一个数据段），但是之后，扩充函数将变为一个二次多项式函数，将从最近一次拥塞事件到当前的时间作为变量。其中，每个RTT间隔的窗口增量的计算公式为：
，其中T表示从最近一次丢包事件到当前的时间。这个公式可以利用当前窗口缩减系数
进行进一步的改进，即：
。
窗口缩减倍数
建立在RTT间隔的变化幅度的基础上。如果RTT的变化幅度不超过20%，那么
的值就被设为上个拥塞周期的RTTmin/RTTmax，否则
设为1/2。
H-TCP在TCP的改进方面又向前迈进了一步。它采用了高速TCP的自适应窗口扩充函数，像可扩展TCP那样将经过的时间作为一个控制参数，并将RTT比例作为修改窗口缩减值的基础（这种做法与Westwood类似）。
FAST
FAST[10]是实现高速TCP的另外一种方法。FAST的作用可以通过比较不同高速TCP方法的每分组响应得到充分的体现，如下面的控制和响应表所示：
|
类型 |
控制方法 |
触发器 |
响应 |
|
TCP |
AIMD(1,0.5) |
ACK 响应 |
W = W + 1/W |
|
MulTCP |
AIMD(N,1/2N) |
ACK 响应 |
W = W + N/W |
|
高速TCP |
AIMD(a(w), b(w)) |
ACK 响应 |
W = W + a(W)/W |
|
可扩展 TCP |
MIMD(1/100, 1/8) |
ACK 响应 |
W = W + 1/100 |
|
FAST |
RTT 波动 |
RTT |
W = W × (基本 RTT/RTT) + |
所有这些方法都具有相同的窗口调整结构，其中发送端的窗口根据一个控制函数和数据流增益进行调节。TCP、 MulTCP、高速TCP、可扩展TCP、BIC、CUBIC、WestWood和H-TCP都采用了基于ACK时钟和丢包触发器的拥塞处理措施。在这些 模式下发生的情况是，网络路径的瓶颈点达到了一定程度的饱和，使得瓶颈队列排满和发生丢包。值得一提的是，在丢包之前建立队列会对RTT产生不利的影响。
这种情况使得FAST得出了这样的判断：另外一种拥塞信令方法可以建立在RTT波动或者累计队列延迟波动的基础上。FAST建立在后一种拥塞信令方法的基础上。
FAST试图在调整窗口的基础上，在稳定分组流的同时保持队列延迟的稳定，从而保持发送速率的稳定。这样，RTT间隔也 可以保持稳定。窗口响应函数建立在按照当前RTT与平均RTT测量值的偏差，调节窗口尺寸的基础上。如果当前RTT低于平均值，那么窗口尺寸就会增大；如 果当前RTT高于平均值，窗口尺寸就会减小。窗口调整幅度通过将两数值之差乘以一定系数得到，这将使得FAST以指数方式收敛到基本的RTT数据流状态。 相比之下，传统TCP不存在收敛状态，而是会在发生丢包的速率和某个较低速率之间保持振荡（参见图10）。
图 10 ： TCP的响应函数和FAST
队列延迟 TCP速率振荡 丢包
延迟
窗口尺寸
FAST会记录一个指数加权平均RTT测试值，并根据当前RTT测量值与加权平均RTT测量值的差值，按比例地调节窗口尺寸。与其他TCP方法相比，FAST的模拟图较难获得。我们已经从一些使用FAST的实验中获得了具有指导意义的资料。
XCP―― 端到端和网络扩展
借 助网络路径上的路由器，还可以为分组标记与当前拥塞等级相关的信令信息。这种方法最初以ECN（即明确拥塞通知）的概念提出，现在已经发展成为一种名为 XCP的传输流控制协议[11]。通过路由器根据相对可持续负荷等级提供的明确信号，可以得到与网络负荷相关的反馈信息。有趣的是，这种方式不同于TCP 的原始设计方法，即TCP信令是有效地通过与最终系统交换一个心跳信号而建立的，而TCP流控制流程则是通过分析这个心跳信号因为网络环境而发生的变化进 行。
XCP促成了一种新的设计方法，即网络交换组件可以通过有效地向终端系统通报网络路径上的当前可用容量，在端到端流控制 中扮演一个重要的角色。这种方式使得终端系统能够通过将分组速率提升到路径中的路由表宣布没有任何可用容量时的水平，迅速地响应可用容量；或者在路径中的 路由表宣布发生暂时拥塞时，降低发送速率。
但是，至于这种利用明确的路由－终端主机信号的方法能否有效地实现高速的传输协议，目前还没有一个明确的结论。
下一步
现在我们面临的基本问题是，我们是否对基于窗口的TCP拥塞控制协议进行了某种最根本的限制，或者基于窗口的控制系统能否在这些速度和距离上继续保持效用，而且这种控制信令将会继续适应这种环境中不断扩大的速度范围。
FAST所使用的、基于速率的调整幅度肯定有助于解决寻求“安全的”窗口扩充和缩减幅度的问题，但是在是否有必要使用一 个窗口扩充和缩减算法，或者是否应当转向其他方向（例如速率控制，RTT稳定性控制，或者在高速控制环中加入网络生成的其他信息）方面，目前还没有肯定的 答案。基于路由器的明确信令（如XCP所采用的方法）可以对TCP会话进行相当准确的控制，但是它不具备在任何现有网络上部署控制系统的适应能力。
但是，对于所有这些方法，基本的TCP目标仍然是一样的：我们需要的是一个能够尽可能有效地――快速地――利用可用网络容量的传输协议，最大限度地减少重发次数和提高有效的数据吞吐率。
我们还需要一种能够适应其他网络用户要求，与其他应用平等分配网络资源的协议。
到目前为止，我们研究的所有方法都是针对实际应用所做的某种形式的妥协。在试图优化即时传输速率时，拥塞控制算法可能无 法响应同一条路径上同时发生的其他传输会话。或者，在试图加强与其他并发会话的公平关系时，控制算法可能会无法响应可用的网络路径容量。控制算法可能会无 法响应会话期间因为网络路径的路由变化而产生的RTT动态变化。至于在一个混合性的网络环境中，哪些TCP性能指标最为重要，我们还没有从这些不同领域的 研究工作中得到一个明确的共识。
但是，我们已经了解到了很多关于TCP的信息。在此基础上，我们可以考虑TCP在这个超高速时代的发展方向时，制定出几个设计原则：
- 第一个原则是，TCP在保持总体网络性能和确保各方的公平性方面相当有效，因为每个人使用的都是某种形式的 TCP，它们都具有类似的响应特性。如果我们全部都选择在我们的TCP协议中使用截然不同的控制方式，那么我们的网络很可能会陷入混乱之中，网络可能会产 生严重的过载和极低的使用效率。
- 第二个原则是，传输协议并不需要解决介质等级或者应用问题。最通用的传输协议不应当依赖于特定介质的特征，而是应当使用来自于协议堆栈较低层的响应，正确地发挥传输系统的作用。
- 第三个关于TCP的原则是，传输协议可以保持出色的一致性，在原先设计时没有考虑的环境中使用。这样，任何方案都应当审慎地进行设计，以便允许各种不同的使用条件。
- 最后一个原则是，传输协议需要在竞争中保持公平的健壮性。协议能否在面临其他并发传输流对资源的要求时，平等地分享低层网络资源？
在所有这些结论中，第一个原则是最重要的，也可能是最难以付诸实践的。互联网之所以能够像今天这样正常工作，是因为我们都使用了相同的传输控制协 议。如果我们希望为了在增加延迟的同时实现高速的数据传输而对该控制协议进行一些改进，那么就有必要考虑，是否存在一种让我们都能使用的、统一的控制结构 和协议。
因此，为在高速互联网中实现高速传输选择一种统一的方法可能是整个改进计划中最关键的一环。虽然我们能够在一个千兆网络上，支持一组使用不同控制方 法的、速率为每秒数Mb的分组流，但是如果在同一个千兆网络上使用各种不同类型的、速率为每秒数Gb的分组流，可能会产生非常严重的混乱和破坏。如果我们 不能在如何选择统一的高速TCP控制算法方面取得共识，那么所有这些方法可能都无法在高度多样化的、高速的网络环境中有效地发挥作用。
致谢
Larry Dunn耐心地、反复地阅读了本文，纠正了一些文字错误，并对我的一些不够严谨的论断提出了质疑。在此致以我诚挚的谢意。
但是，无论本文中存在什么错误，无疑都是我个人的责任。
深入阅读
围绕这个问题，目前有很多可供阅读的资料。您可以通过任 何一个正式的搜索引擎找到这些资料。但是，如果您对这个问题很感兴趣，而且希望找到一个以非常详细的、有组织的方式探讨这一问题的文献，我愿意向您推荐下 面这两个资料来源。您可以借助它们研究这个问题，了解这个领域目前的发展状况：
- “HighSpeed TCP for Large Congestion Windows,” S. Floyd, RFC 3649, December 2003.
Floyd在文中深入、全面、准确地探讨了这个问题。希望所有的RFC都能达到这样的写作质量。
- 关于适用于快速远程网络的协议的研讨会文集
这些研讨会的网址分别是：
2003:http://datatag.web.cern.ch/datatag/pfldnet2003/
2004:http://www-didc.lbl.gov/PFLDnet2004/program.htm
2005: http://www.ens-lyon.fr/LIP/RESO/pfldnet2005/
参考文献
[1] “Differentiated End-to-End Internet Services Using a Weighted Proportional Fair Sharing TCP,” J. Crowroft and P. Oechcslin, ACM SIGCOMM Computer Communication Review, Volume 28, No. 3, pp. 53–69, July 1998.
[2] “HighSpeed TCP for Large Congestion Windows,” S. Floyd, RFC 3649, December 2003.
[3] “Scalable TCP: Improving Performance in High-Speed Wide Area Networks,” T. Kelly, ACM SIGCOMM Computer Communication Review, Volume 33, No. 2, pp. 83–91, April 2003.
[4] “Binary Increase Congestion Control (BIC) for Fast Long-Distance Networks,” L. Xu, K. Harfoush, and I. Rhee, Proceedings of IEEE INFOCOMM 2004, March 2004.
[5] “CUBIC: A New TCP-Friendly High-Speed TCP Variant,” I. Rhee, L. Xu, http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/ cubic-paper.pdf, February 2005.
[6] “TCP Westwood: Congestion Window Control Using Bandwidth Estimation,” M. Gerla, M. Y. Sanadidi, R. Wang, A. Zanella, C. Casetti, and S. Mascolo, Proceedings of IEEE Globecom 2001, Volume 3, pp. 1698–1702, November 2001.
[7] “Linux 2.4 Implementation of Westwood+ TCP with Rate- Halving: A Performance Evaluation over the Internet,” A. Dell’Aera, L. A. Greco, and S. Mascolo, Tech. Rep. No. 08/03/S, Politecnico di Bari, http://deecal03.poliba.it/mascolo/ tcp%20westwood/Tech_Rep_08_03_S.pdf
[8] “End-to-end Internet packet dynamics,” V. Paxson, Proceedings of ACM SIGCOMM 97, pp. 139–152, 1997.
[9] “H-TCP: TCP Congestion Control for High Bandwidth-Delay Product Paths,” D. Leith, R. Shorten, Work in Progress, June 2005. Internet Draft: draft-leith-tcp-htcp-00.txt
[10] “FAST TCP: Motivation, Architecture, Algorithms, Performance,” C. Jin, X. Wei, and S. H. Low, Proceedings of IEEE INFOCOM 2004, March 2004.
[11] “Congestion Control for High Bandwidth-Delay Product Networks,” D. Katabi, M. Handley, and C. Rohrs, ACM SIGCOMM Computer Communication Review, Volume 32, No. 4, pp. 89–102, October 2002.
[12] “TCP Performance,” Geoff Huston, The Internet Protocol Journal, Volume 3, No. 2, June 2000.
[13] “The Future for TCP,” Geoff Huston, The Internet Protocol Journal, Volume 3, No. 3, September 2000.
Geoff Huston在澳大利亚国立大学获得了学士和硕士学位。近二十年来，他广泛地参与了互联网的发展工作，特别是在澳大利亚，他负责澳大利亚学术和科研网络的 前期建设工作，并曾经在Telstra的互联网部门担任首席科学家。Geoff目前是亚太地区网络信息中心（APNIC）的互联网研究科学家。他是互联网 架构委员会的成员，目前还担任着IETF中的三个工作组的联合主席。他曾撰写多本与互联网有关的书籍。他的电子邮件地址为：gih@apnic.net。
