TCP 吞吐量模型

建模假设

在前几节中，我们开发了一种拥塞控制算法。该算法告诉我们如何根据拥塞情况调整速率，但并未明确说明速率具体是多少。

在本节中，我们将建立一个模型来估算特定路径上 TCP 连接的吞吐量。具体来说，我们希望得到一个简单的方程，将吞吐量表示为路径往返时间（RTT）和丢包率的函数。这个方程可以帮助运营商和用户估算 TCP 连接的速率。

为了简化模型，我们做如下假设：存在单一的 TCP 连接；忽略慢启动阶段；假设往返时间（RTT）是一个固定值。

当窗口大小达到最大瓶颈带宽$Wmax$（某个常数）时，我们假设恰好发生一个数据包丢失。由于只丢失一个数据包，我们可以通过重复确认（而非超时）检测到丢包。

基于窗口大小的吞吐量

在这个简化模型中，当窗口大小达到$Wmax$时，我们会检测到丢包，窗口大小也会因此发生变化。

之后，在每个后续的 RTT 内，窗口大小会增加 1：从$\frac{1}{2}Wmax + 1$，到$\frac{1}{2}Wmax + 2$，再到$\frac{1}{2}Wmax + 3$，依此类推。最终，窗口大小会再次达到$Wmax$，然后被减半，这个过程不断重复。

从$\frac{1}{2}Wmax$开始增长到$Wmax$需要$\frac{1}{2}Wmax$个 RTT（每次迭代增加 1，每个迭代为一个 RTT）。这也意味着两次丢包之间的间隔是$\frac{1}{2}Wmax$个 RTT。

在每个 RTT 内，平均窗口大小为$\frac{3}{4}Wmax$（正好在$\frac{1}{2}Wmax$和$Wmax$的中间）。

窗口大小以数据包为单位（因为我们每次迭代增加 1 个数据包）。每个数据包可以包含$MSS$字节（最大段大小），因此平均窗口大小（以字节为单位）是$\frac{3}{4}Wmax \times MSS$。

窗口大小表示我们在每个 RTT 内可以发送的数据量。因此，要计算速率，我们将窗口大小（数据量）除以 RTT（时间），得到平均速率为$\frac{3}{4}Wmax \times \frac{MSS}{RTT}$。

基于丢包率的吞吐量

到目前为止，我们的吞吐量方程是：$\frac{3}{4}Wmax \times \frac{MSS}{RTT}$。

但我们的目标是用 RTT 和丢包率（记为$p$）来表示吞吐量。因此，我们需要用丢包率$p$来表示$Wmax$。

前面我们推断出，每$\frac{1}{2}Wmax$个 RTT 会丢失一个数据包。这是从一次丢包后重新增长到$Wmax$并再次发生丢包所需的时间。

因此，要确定丢包率，我们只需计算在$\frac{1}{2}Wmax$个 RTT 内发送的数据包数量。

从图形上看，发送的数据包数量是这个图形的面积（速率乘以时间），或者等价于曲线下的面积（曲线表示速率，我们需要速率的积分）。

我们从前面知道平均窗口大小是$\frac{3}{4}Wmax$，这是每个 RTT 发送的数据包数量。因此，在$\frac{1}{2}Wmax$个 RTT 内，我们预计发送的数据包数量为$(\frac{1}{2}Wmax) \times \frac{3}{4}Wmax = \frac{3}{8}Wmax^2$。

既然我们知道了两次丢包之间发送的数据包数量，那么丢包率就是丢失的 1 个数据包除以两次丢包之间发送的数据包数量。（例如，如果两次丢包之间发送了 100 个数据包，那么丢包率大约是 1/100）。

因此，我们的丢包率为$p = \frac{1}{(\frac{3}{8}Wmax^2)} = \frac{8}{3 Wmax^2}$。

现在，我们得到了$Wmax$和$p$之间的关系，只需通过代数运算将$Wmax$用$p$表示出来。

$p = \frac{8}{3 W_{max}^2}$

$3 Wmax^2 p = 8$

$Wmax^2 = \frac{8}{3p}$

$Wmax = 2\sqrt{\frac{2}{3p}}$

现在，我们可以通过进一步的代数运算，将前面的吞吐量方程中的$Wmax$替换为$p$：

$throughput = \frac{3}{4}Wmax \times \frac{MSS}{RTT} = \frac{3}{4}(2\sqrt{\frac{2}{3p}}) \times \frac{MSS}{RTT} = \frac{\sqrt{3}}{\sqrt{2}} \times \frac{MSS}{RTT \sqrt{p}}$

公式的含义

现在我们得到了用 RTT 和丢包率表示的吞吐量方程。这个方程告诉我们什么呢？

吞吐量与丢包率的平方根成反比。直观地说，丢包率越高，吞吐量越低。这是合理的，因为丢失的数据包越多，窗口大小就会越频繁地被减半。

吞吐量与 RTT 成反比。直观地说，RTT 越小，吞吐量越高。这也是合理的，因为窗口大小会在每次收到确认时增加，而较小的 RTT 意味着我们能更频繁地收到确认。

当存在多个具有不同 RTT 的连接时，RTT 与吞吐量之间的这种关系可能会带来问题。

RTT 较小的连接会更快地收到确认，这意味着该连接也会更快地增加窗口大小并发送数据包。在这种情况下，RTT 较小的连接会获得两倍于 RTT 较大的连接的带宽。

从根本上讲，当 RTT 不同时，TCP 是不公平的。较小的 RTT 不仅减少了传播时间，还帮助 TCP 更快地提高速率。我们将此视为 TCP 的一个特性，在实际中并未对此采取措施。

基于速率的拥塞控制

我们的拥塞控制协议会导致吞吐量波动。从图中可以看出，速率在$W/2$和$W$之间反复波动。有些应用不喜欢这种不断变化的速率，更希望以稳定的速率发送数据（例如流媒体应用）。

这些应用的一种可能解决方案是基于公式或基于速率的拥塞控制，它放弃了动态调整速率的规则，而是直接遵循上述方程。为了以平稳的速率发送数据，可以测量 RTT 和丢包率，将其代入吞吐量方程，并以计算出的速率持续发送数据。这种解决方案还能保持公平性（不会占用过多带宽），因为该方程确保我们消耗的带宽不会超过类似情况下 TCP 所消耗的带宽（更多细节参见 RFC 5348）。

形式上，包括基于速率的拥塞控制在内的其他实现，如果能与 TCP 良好共存（在必要时降低速率），则被视为TCP 友好的。TCP 友好的替代算法即使在一些主机运行 TCP 而另一些主机运行替代算法时，也能实现公平的带宽共享。

（注：文档部分内容可能由 AI 生成）