数据中心中的拥塞控制
数据中心有何不同？
我们已经了解到，与通用网络相比，数据中心网络有额外的约束条件（例如，物理上位于同一建筑物内，由同一运营商拥有）。这使得可以开发利用这些网络特殊特性的专用协议。在本节中，我们将探讨那些可能在通用互联网中不适用，但在数据中心环境中有效的 TCP 拥塞控制算法。这是一个活跃的研究和开发领域。
首先，我们需要回答：是什么让数据中心的拥塞控制有所不同？
回想一下，数据包延迟包括传输延迟（在链路上发送比特的时间，由带宽决定）、传播延迟（比特在链路上传输的时间）和排队延迟。
在数据中心中，传输延迟通常相对较小（请记住，我们有 10 Gbps 的高容量链路）。数据中心中的传播延迟也相对较小（记住，所有服务器都在同一建筑物内）。因此，在数据中心中，排队延迟往往是延迟的主要来源。相比之下，在广域网中，传播延迟可能大得多（例如，数据包可能需要穿越整个国家），并且是更常见的主要延迟来源。
回想一下，TCP 拥塞控制会故意填满队列，直到数据包丢失（我们通过检查丢失来检测拥塞）。TCP 的设计者没有考虑到数据中心的情况，在这种情况下，排队延迟可能对性能产生更大的影响。
在数据中心中，大队列的问题更为严重，因为与广域网不同，大多数数据中心连接属于两类之一。大多数连接是小鼠流，它们数据量小且对延迟敏感。例如，网页搜索查询和结果页面包含的数据量非常小，但我们希望尽快将结果返回给用户。相比之下，有些连接是大象流，它们数据量大且对吞吐量敏感。例如，将数据从一台服务器备份到另一台服务器需要一个长期运行的连接，以高吞吐量发送大量数据。
如果我们对这两种类型的连接运行 TCP 拥塞控制，大象流会提高它们的速率，直到队列被填满。此时，任何后续的小鼠流都会被困在队列中，导致小鼠流延迟。
为了使这些特定类型的连接获得最佳性能，数据中心拥塞控制算法必须避免填满队列。近年来，已经开发了许多针对数据中心的解决方案。
例如，BBR 是谷歌在 2016 年推出的。在这种方法中，我们不是通过检查丢失（这需要队列已满）来检测拥塞，而是通过检查数据包延迟来检测拥塞。
DCTCP：来自路由器的反馈
DCTCP（数据中心 TCP）于 2010 年由微软推出，现在已被广泛使用（例如，在 Linux 内核中实现）。
回想一下，IP 报头有一个 ECN 位，路由器可以启用该位来表示其处于拥塞状态。当数据包到达目的地时，确认包也会设置 ECN 位，这会告诉发送方减速。
在 DCTCP 中，当队列长度超过某个阈值时，路由器会启用 ECN 位。这使发送方能够更早地检测到拥塞并进行调整（在队列填充过程中，在队列完全填满之前）。
作为对拥塞的响应，发送方会根据带有 ECN 标记的数据包数量成比例地降低速率。这使发送方能够更平缓地适应拥塞。不再是二元决策（拥塞或不拥塞），发送方可以检测到可能正在发生的一些拥塞，并略微降低速率以进行补偿。
ECN 位在广域网中不是很有效，因为并非所有路由器都支持它。然而，在数据中心中，运营商控制所有交换机，并且可以让它们以一致的方式切换 ECN。实际上，在主机和路由器上实现 DCTCP 是一个相对较小的改动。
为了衡量 DCTCP 的性能，我们可以测量流完成时间（FCT），即从发送第一个字节到接收最后一个字节的时间。作为基准，理想的 FCT 是如果我们使用具有整个网络和所有连接全局知识的全知调度器的完成时间。然后，调度器可以利用这些知识来优化流的调度并为流分配带宽。
该图显示了归一化的 FCT，即实际 FCT 与理想 FCT 的比率。这告诉我们，与理想的拥塞控制算法相比，我们的表现有多差。我们可以看到，标准的 TCP 拥塞控制比理想情况差 3 倍，如果网络负载更高，则比理想情况差多达 10 倍。相比之下，DCTCP 的性能明显优于标准的 TCP 拥塞控制。DCTCP 连接完成得更快，排队延迟更小。
pFabric：数据包优先级
我们已经看到，数据中心中的问题是小鼠流可能被困在大象流后面的队列中。如果我们让小鼠流能够跳到队列前面，以便它们能更快完成，会怎么样呢？
为了优先处理小鼠流，我们将为每个数据包分配一个优先级编号。优先级是根据剩余流大小（未确认的字节数）计算的。数值越低，优先级越高。
在这个系统中，小鼠流数据包将具有高优先级（流大小非常小）。大象流将具有低优先级，尽管大象流连接中的最后几个字节将具有较高的优先级。这具有优先处理几乎完成的连接的效果（即使它们是较大的大象流连接）。
为了实现这个想法，回想一下 IP 数据包报头有字段来指示数据包的优先级。在 pFabric 中，每个数据包都携带一个优先级编号，并且交换机经过修改，以便发送最高优先级的数据包。如果队列已满，交换机将丢弃最低优先级的数据包。
有了优先级系统，发送方现在可以安全地以全速传输和重传数据包，而无需为拥塞控制调整速率。发送方只需要在极端丢失的情况下（例如超时）降低速率。
如果我们再看一下 FCT 图表，会发现 pFabric 的性能甚至比 DCTCP 更好，非常接近理想情况。
为什么 pFabric 表现如此出色？大象流和小鼠流一起传输，并且每个流都以全速发送，这确保了可用带宽的充分利用。我们不必在慢启动上浪费时间。此外，我们可以避免网络崩溃，因为大象流中的大多数数据包都是低优先级的。优先级系统确保小鼠流数据包仍然能够以低延迟通过队列。
实现这个系统需要对交换机和终端主机进行不小的改动，并且需要完全控制交换机和终端主机。交换机需要实现优先级系统，发送方需要替换其 TCP 实现以全速发送。尽管如此，pFabric 是网络（交换机）和终端主机协作以实现良好性能的一个很好的例子。
（注：文档部分内容可能由 AI 生成）