7.4 TCP-Friendly Protocols (TFRC)

本书中曾多次指出，很容易开发出超越TCP性能的传输层协议。这是因为TCP及其所有变种在检测到拥塞时都会降低传输速率。所以任何不响应拥塞并降低传输速率的协议，最终都将比任何TCP或者类似TCP的流量，在瓶颈链路上占有更大的份额。极端情况下， 这样的协议可能会导致拥塞崩溃，正如TCP拥塞控制机制刚刚被引入那会一样。因此，非常有必要确保大多数互联网流量在某种程度上是“对TCP友好（TCP-Friendly）”的。

当我们使用“TCP-friendly”这个术语时，我们期望对应的协议能像 TCP 一样响应拥塞。LEDBAT可以被认为是超越“TCP-friendly”了，因为它对拥塞的响应更为激进，它一旦检测到有拥塞的迹象，就会减少其窗口大小。而对于另一类应用，由于没有使用基于窗口的拥塞控制方案，要实现TCP-Friendly则更为复杂一些，这些应用通常是涉及流媒体的“实时”应用。

多媒体应用程序，如视频流和电话会议，可以通过改变编码参数来调整其发送率，这其实是在带宽和质量之间做取舍。它们不能在不影响质量的前提下，突然大幅度减少发送率，并且质量等级也是有限的几个选择。基于这些因素，它们的拥塞控制算法是基于速率，而不是基于窗口，如第3.1节所讨论的一样。

为了使这些应用程序对TCP友好，它们会尝试选择一个发送速率，该速率也是TCP在相同条件下能达到的速率，但选择的发送速率又不能波动的过于剧烈。这里实现的基础是多年来关于模拟TCP吞吐量的一系列研究。RFC 5348中给出了 TCP 吞吐量方程的简化版本，该RFC同时也定义了 TFRC 的实现标准。将几个变量设置为推荐值后，目标传输速率X（bps）的方程为：

其中：

• s是segment大小（排除了IP头和传输层头）

• R是RTT，单位是秒

• p是“loss event”的数量与传输的数据包数量的比例

这个公式的推导本身就很有趣（详见下面更多阅读的第二个参考资料），它的关键的想法是，如果我们知道网络路径的 RTT和丢包率，就能相对准确地预测一个 TCP 连接的带宽。因此，TFRC试图控制那些无法实现基于窗口的拥塞控制算法的应用程序，以相同条件下TCP会达到的吞吐量（带宽）来发送数据。

剩下需要解决的问题是测量 p 和 R，然后决定应用程序应如何响应传输速率 X 的变化。与我们看到的其他一些协议一样，TFRC 使用时间戳来更准确地测量 RTT，这比最初版本的 TCP 测量更精确。包序列号用于在接收端确定包丢失，连续丢失的包会被归入一个“loss event”。根据这些信息，可以在接收端计算“loss event”的速率 p，并传回给发送端。

如何响应传输速率的变化当然取决于应用本身。基本思想是，应用程序可以在一组编码速率中，选择 TFRC 所指示的速率能够容纳的最高质量。

尽管TFRC的概念很扎实，但由于多种原因，其部署很有限。其中一个原因是，对于某些类型的流媒体传输，出现了一个更简单的解决方案，称为 DASH（Dynamic Adaptive Streaming over HTTP）。DASH只适用于非实时媒体（例如，观看电影），但这恰好占了通过互联网运行的媒体流量的很大一部分——实际上，它占了所有互联网流量的很大一部分。

DASH允许TCP（或者也可能是QUIC）负责拥塞控制；应用程序测量TCP正在传输的吞吐量，然后相应地调整视频流的质量，以避免在接收器端没有音视频可播放。这种方法已被证明适合娱乐类音视频，但由于它依赖于接收端大量的缓存来平滑处理TCP吞吐量的波动，因此并不真正适用于交互式音频或视频。DASH可行的关键因素之一是，人们可以以多种质量等级编码视频，不同质量等级的视频具有不同的带宽需求，并且可以提前在流媒体服务器上存储它们。然后，一旦观察到的网络吞吐量下降，服务器就可以降低到较低质量的流，然后在条件允许时提升到更高质量。客户端可以将信息反馈给服务器，例如它还有多少缓冲视频在等待播放，以帮助服务器选择合适的质量和带宽。这种方法的代价是服务器上需要存储额外的媒体（注，即不通码率的视频），但在现代流视频时代，这种代价已变得相对不重要。注意，在这种情况下的“服务器”很可能是CDN（content distribution network）中的一个节点。因此，视频流可以在客户端与服务它的CDN节点之间的带宽得到改善时，转移到更高的质量级别。

TFRC 的另一个局限性在于，它主要使用丢包作为拥塞的信号，但不响应先于丢包的延迟。虽然这种行为在 TFRC 正在被研究时，是大家的普遍做法，但 TCP 拥塞控制领域现在已经考虑延迟，如TCP Vegas和BBR（参见第5章）。而当考虑到那些DASH不能支持的多媒体应用时，延迟尤为重要。因此，截至撰写本文时，为实时流量定义 TCP-friendly的拥塞控制研究仍然在进行。IETF RMCAT（RTP Media Congestion Avoidance Techniques）工作组是这项工作的主导。因此，下面对TFRC 的规范并非最终成果，但还是提供了如何实现 TCP-friendly Protocol 的有用背景。

更多阅读：S. Floyd, M. Handley, J. Padhye, and J. Widmer. TCP Friendly Rate Control (TFRC): Protocol Specification. RFC 5348, September 2008.

J. Padhye, V. Firoiu, D. Towsley, and J. Kurose. Modeling TCP Throughput: A Simple Model and its Empirical Validation. ACM SIGCOMM, September 1998.