我有一个关于TCP和QUIC的问题。对于一个项目，我必须测试TCP公平是如何快速。我的设置是两个虚拟机，一个是nginxQuic实现，另一个是使用nginxTCP。我必须生成随机文件，并在TCP和QUIC运行的情况下下载它们。对于文件下载，据说我可以使用curl，这没有问题，但为了衡量公平性，我考虑了Iperf来获得吞吐量和带宽，并用Jains公平指数计算结果。我不知道这是否是最好的解决方案，但我真的找不到其他东西，我知道我想知道我是否可以在使用curl下载时使用Iperf进行测量，或者这没有意义吗？
对不起，我真的是这个论坛的新手，TCP和QUIC。
提前感谢
TCP传统上使用非常保守的拥塞控制算法，在数据包丢失是达到网络容量的结果的假设下(通常是不正确的(，只要有最轻微的数据包丢失迹象，拥塞控制算法就会显著后退。
BBR是一种新的拥塞控制算法，它以不同的方式对待网络模型，因此不像拥塞控制信号那样依赖于分组丢失。因此，它受到了"不公平"的批评：
BBR版本1(BBRv1(高效快速，但其对非BBR流的公平性存在争议。当在YouTube上实现时，BBRv1的网络吞吐量平均提高了4%，在一些国家高达14%。虽然谷歌的演示显示BBRv1与CUBIC共存良好，但Geoff Huston和Hock、Bless和Zitterbart等研究人员认为它对其他流不公平，而且不可扩展。Hock等人还发现；一些严重的固有问题，例如增加的排队延迟、不公平和大量的分组丢失"；在Linux 4.9的BBR实现中。
目前，QUIC实现基本上已经重新实现了TCP拥塞控制算法(包括BBR(，因此任何公平性度量都只是其中的一个度量。现在，QUIC确实允许更快地迭代更改，因此如果出现这种情况，允许更容易地部署另一种更不公平的拥塞控制算法，可能会变得更"不公平"，但目前它们与TCP非常相似。此外，这并不取决于任何一个实现是否代表所有QUIC，是否尚未完成，也不太可能发生变化——所有实现都很年轻，随着从QUIC学习的发现和改进，变化很大。关于QUIC是否更快，已经完成了许多研究，大多数研究得出的结论是，与目前大多数其他因素相比，它因实施而变化更大。