QUIC 对 TCP 是公平的答案

【问题标题】：is QUIC fair to TCPQUIC 对 TCP 是公平的
【发布时间】：2022-01-26 23:23:43
【问题描述】：

我有一个关于 TCP 和 QUIC 的问题。对于一个项目，我必须测试 TCP 公平性如何是 QUIC。我的设置是两台虚拟机，一台使用 nginx Quic 实现，另一台使用 nginx TCP。我必须生成随机文件并在运行 TCP 和 QUIC 的情况下下载它们。对于文件下载，据说我可以使用 curl，这没问题，但可以衡量我认为 Iperf 的公平性，以获得吞吐量和带宽，并使用 Jains 公平指数计算结果。我不知道这是否是最好的解决方案，但我真的找不到其他东西，我想知道我是否可以在使用 curl 下载的同时使用 Iperf 进行测量，还是没有意义？

对不起，我对这个论坛以及 TCP 和 QUIC 真的很陌生。

提前谢谢你

【问题讨论】：

所以，我知道 quic 可以打开单独的数据流，但我不知道这如何与 iperf 一起工作，或者 iperf 是否有任何选项来控制使用多少流。基本公平是 iperf over tcp vs iperf over quic。尽管您需要检查拥塞控制算法是否相同。如果 quic 设法获得更多的流，它应该需要更多的带宽。但这应该通过启动几个 tcp 流来消除（iperf 应该可以选择这样做）。虽然当您获得匹配数量的流时，这应该衡量拥塞控制的公平性，而不是快速
您可以尝试的第二件事是流程完成时间，您可以通过使用 curl 加载小东西来做到这一点。 Quic 应该有更快的连接设置，所以它应该更快。
下一个公平参数可以是新流达到其公平带宽份额的速度。在这里你可能会做 iperf vs curl，或者在第一个 iperf 流之后启动第二个 iperf 流，看看它何时达到全带宽
我不知道的另一件事是，Quic 中的安全性是否是可选的。如果你在安全的情况下运行 quic，而在没有 tls 的情况下运行 tcp，这应该会导致比实际情况更不公平。 curl应该使用https，但我不知道您是否可以使用tls强制执行ipref。
是的，我不知道 iperf 是否是 curl 的好选择。但是我认为如果我想下载一堆文件，curl 是最好的选择，但我不知道如何衡量当 TCP 和 Quic 应该并行下载同一页面时 Quic 是否公平@Effie

标签： curl tcp virtual-machine iperf quic

【解决方案1】：

QUIC 对 TCP 是否公平并不是真正的问题。两者都将与控制吞吐量的拥塞控制算法一样公平，而不是任何一种协议固有的任何东西。

传统上，TCP 使用相当保守的拥塞控制算法，在丢包是达到网络容量的结果（通常是不正确的）假设下，一旦丢包的最轻微提示就会大大退缩。

BBR 是一种新的拥塞控制算法，它以不同的方式处理网络模型，因此不像拥塞控制信号那样依赖丢包。结果it has received criticism of being “unfair”：

BBR 版本 1 (BBRv1) 高效且快速，但其对非 BBR 流的公平性存在争议。在 YouTube 上实施时，BBRv1 产生的网络吞吐量平均提高了 4%，在某些国家甚至高达 14%。虽然 Google 的演示文稿显示 BBRv1 与 CUBIC 共存良好，但 Geoff Huston 和 Hock、Bless 和 Zitterbart 等研究人员发现它对其他流不公平且不可扩展。 Hock 等人还在 Linux 4.9 的 BBR 实现中发现了“一些严重的固有问题，例如排队延迟增加、不公平和大量丢包”。

目前，QUIC 实现基本上重新实现了 TCP 拥塞控制算法（包括 BBR），因此任何公平性度量都只是对这些算法的度量。现在 QUIC 确实允许更快地迭代更改，因此可能会变得更加“不公平”，因为如果/当这种情况出现时，可以更轻松地部署另一个更不公平的拥塞控制算法，但目前它们与 TCP 非常相似。此外，不依赖于代表所有 QUIC 的任何单个实现，尚未完成且不太可能改变 - 所有实现都是年轻的，并且随着从 QUIC 中学习的发现和改进而发生很大变化。已经完成了多项关于 QUIC 是否更快的研究，并且大多数研究得出的结论是，与目前大多数其他因素相比，它因实施而异。

【讨论】：