TCP慢启动如何提高吞吐量？答案

【问题标题】：How does TCP slow start increase throughput?TCP慢启动如何提高吞吐量？
【发布时间】：2012-06-13 03:16:57
【问题描述】：

TCP 慢启动出现在 Internet 开始经历“拥塞崩溃”的时期。来自Van Jacobson and Michael Karels paper 的轶事示例如下：

During this period, the data throughput from LBL to UC Berkeley (sites separated
by 400 yards and two IMP hops) dropped from 32 Kbps to 40 bps.

拥塞问题通常被描述为由从高速链路过渡到低速链路以及在此瓶颈处的缓冲区建立/丢弃数据包引起的。
我想了解的是，这种构建如何导致端到端吞吐量下降，而不是简单地在链路的高速部分引起多余的活动/重新传输导致进入完整的缓冲区。例如，考虑以下网络：

    fast       slow       fast
A ======== B -------- C ======== D

A 和 D 是端点，B 和 C 是从高速网络过渡到低速网络时的数据包缓冲区。所以例如A/B 和 C/D 之间的链路为 10Mbps，B/C 之间的链路为 56Kbps。现在，如果 A 向 D 发送 large（假设理论上是无限的）消息，我想了解的是，如果它只是用数据敲击 TCP 连接，为什么它需要更长的时间才能通过与适应连接中间较慢的链接速度相比。我设想 B 只是其缓冲区以 56Kbps 的固定速率耗尽的东西，无论其缓冲区被 A 敲击的程度如何，也无论由于缓冲区已满而必须丢弃多少数据包。因此，如果 A 始终保持 B 的缓冲区已满（或可能是过满），并且 B 始终以 56Kbps 的最大速率传输，那么通过使用慢启动来提高吞吐量如何？

我唯一能想到的是，如果 D 已经收到的相同数据包必须在拥塞下通过慢速 B/C 链路重新传输，这会阻塞新数据包。但是 D 通常不会对它收到的任何数据包进行 ACK 确认，因此重传的数据包应该主要是那些合法地没有被 D 接收到的数据包，因为它们被丢弃在 B 的缓冲区中？

【问题讨论】：

或者，也许，这些段被 A 重新传输，因为它没有看到它们的 ACK，因为它们仍在传输中......它只会等这么久才认为他们是 MIA。在这一点上，它会将大部分数据发送两次，其中大部分是第三次，第三次大部分是第四次，并且...
@cHao 我确实想到了这个。他们仍在运输中的事实似乎意味着 B 的缓冲膨胀。我不认为缓冲膨胀在当时是一个问题，但我可能是错的？
不确定。但也请考虑一下……如果那样的话，A 和 D 只知道链路各自端的速度。他们不知道 BC 链接有多快。如果他们假设他们有 10Mbps 的速度可以玩，并且实际上以 10Mbps 的速度发送内容（当然，设置足够大的窗口以使其有用），并且 B 丢弃了 A 的大部分数据包，他们会仍然需要重新传输...所以现在 A 占用了其网络上的大量带宽（不仅仅是用数据包淹没 B，而且必须重新传输，因为它们中的大多数都被丢弃了！）以便发送最大 56K 的东西。
无论你怎么看，重传的数据包都会丢失/浪费带宽。如果每个人都在做同样的事情......：P

标签： tcp congestion-control

【解决方案1】：

请记住，网络涉及在多台计算机之间共享资源。非常简单，需要慢启动以避免少量 TCP 会话耗尽路由器缓冲区（在您的图中，这很可能在 B 点和 C 点）

来自RFC 2001, Section 1：

旧的 TCP 会启动与发送方的连接，注入多个分段到网络中，直到由网络通告的窗口大小接收者。虽然这在两台主机在同一个 LAN 上时是可以的，如果发送方和发送方之间有路由器和较慢的链路接收器，可能会出现问题。一些中间路由器必须排队数据包，并且该路由器可能会用完空间。 [2] 展示了这种简单的方法如何降低 TCP 的吞吐量连接剧烈。

...
[2]  V. Jacobson, "Congestion Avoidance and Control," Computer

    Communication Review, vol. 18, no. 4, pp. 314-329, Aug. 1988.
    ftp://ftp.ee.lbl.gov/papers/congavoid.ps.Z.

路由器必须有有限的缓冲区。链路之间的速度不匹配越大，缓冲区耗尽而没有慢启动的机会就越大。缓冲区耗尽后，您的平均 TCP 吞吐量将下降，因为缓冲增加了 TCP 使用链接的能力（防止不必要的下降导致瞬时链接饱和）。

请注意，上面的 RFC 2001 已被 RFC 5681 取代；但是，RFC 2001 为您的问题提供了更可引用的答案。

来自您的 OP...

现在，如果 A 向 D 发送一条大的（假设理论上是无限的）消息，我想了解的是，如果它只是用数据敲击 TCP 连接而不是适应连接中间的链接速度较慢。

首先，TCP 中不存在无限消息。 TCP 在慢启动出现之前受到初始窗口大小的限制。

因此，假设初始 TCP 段的长度为 64KB。如果整个 TCP 段在 B 处填满路由器的 tx 缓冲区，由于丢包、ACK 和 TCP 回退涉及的动态，TCP 随着时间的推移使用较少的链路。让我们看看个别情况：

B 的 tx_buffer
B 的 tx_buffer >= 64KB：只要 A 是唯一发送的站，没有负面影响（只要 D 正确 ACK-ing）；但是，如果有多个主机在 A 的 LAN 上传输试图通过 56K 链路进行传输，则可能会出现问题，因为在 56K 上将单个 1500 字节数据包出列需要 200 毫秒。如果您有来自 A 的 64KB 初始窗口的 44 个 1500 字节数据包（44*1460=64KB；您只获得 1460 字节的 TCP 有效负载），则路由器在处理 A 的流量时有将近 9 秒的饱和链路。

第二种情况既不公平也不明智。当 TCP 发现任何数据包丢失时，它会后退...共享单个链接的多个主机必须使用慢启动来保持情况正常。

顺便说一句，我从未见过在接口上缓冲 9 秒的路由器。没有用户会容忍这种延迟。大多数路由器的最大速度约为 1-2 秒，而那是几年前的 T-1 速度。由于多种原因，如今的缓冲区甚至更小。

【讨论】：

关于您的要点，我仍然无法看到这如何影响总吞吐量。第 1 点，是的，A 和 B 之间的带宽因重传而浪费，但 B 到 C 一直很忙（这就是数据包在 B 处丢弃的原因），所以看起来端到端的事情仍在以同样快的速度移动尽可能。第 2 点似乎主要针对公平和延迟，而不是吞吐量。如果数据包正在发送到 C 并且 then 由于超时而必须重新传输，这一切都是有道理的。正如您似乎推断的那样，实际上较小的缓冲区大小有助于限制延迟。
第1点：如果数据包被丢弃并且必须重新传输，那么您的吞吐量会降低；问题不仅在于丢包，还在于丢包检测所需的 1xRTT 以及由于丢包导致的自我强制 TCP 回退。第2点：我承认第一个站没有吞吐量问题，但这种情况未能通过常识测试。总结一下：由于路由器缓冲区大小有限，人们不得不让 TCP 启动缓慢
第 1 点：在 1xRTT 进行丢包检测期间，后续数据包不会逐步通过 B -> C，因此您可以获得相当的吞吐量，数据包只是以不同的顺序到达?我认为自我强加的退避是与 TCP 慢启动同时引入的（即在那之前不存在），但我猜那是错误的？第 2 点我想我明白你的意思了，我只是不认为它对总吞吐量有任何影响，除非数据包被丢弃/需要在已经通过慢速瓶颈链路之后重新传输。
啊，我想除非缓冲区耗尽时间远小于重传超时。在这种情况下，将在溢出的缓冲区之间循环，然后快速完全耗尽，然后是在重新传输之前等待超时的很长一段时间，然后是另一个溢出的缓冲区，所有重新传输......这可能是你得到的在...