7

我想要一个程序来确定在捕获的 TCP 会话中使用的TCP 拥塞控制算法。

引用的维基百科文章指出：

TCP New Reno 是最常实现的算法，SACK 支持非常普遍，是 Reno/New Reno 的扩展。其他大多数是仍需要评估的竞争提案。从 2.6.8 开始，Linux 内核将默认实现从 reno 切换到 BIC。在 2.6.19 版本中，默认实现再次更改为 CUBIC。

还：

Compound TCP 是 Microsoft 的 TCP 实现，它同时维护两个不同的拥塞窗口，目标是在 LFN 上实现良好的性能，同时不损害公平性。它已与 Microsoft Windows Vista 和 Windows Server 2008 一起广泛部署，并已移植到较旧的 Microsoft Windows 版本以及 Linux。

确定正在使用哪种 CC 算法（来自捕获会话的第三方）的一些策略是什么？

更新

这个项目已经建立了一个工具来做到这一点：

互联网最近已经从同构拥塞控制发展到异构拥塞控制。几年前，互联网流量主要由标准 TCP AIMD 算法控制，而现在互联网流量由许多不同的 TCP 拥塞控制算法控制，如 AIMD、BIC、CUBIC、CTCP、HSTCP、HTCP、HYBLA、ILLINOIS、LP、 STCP、VEGAS、VENO、WESTWOOD+ 和 YEAH。然而，关于异构拥塞控制的互联网性能和稳定性研究的工作却很少。一个根本原因是缺乏不同 TCP 算法的部署信息。该项目的目标是：

1) develop tools for identifying the TCP algorithms in the Internet,
2) conduct large-scale TCP-algorithm measurements in the Internet.
4

1 回答 1

4

拥塞控制算法比您在此处提到的要多得多，在我的脑海中，列表包括：FAST、Scalable、HSTCP、HTCP、Bic、Cubic、Veno、Vegas。

由于实际实现中的错误修复，它们也有一些小的变化，我猜不同操作系统中的实现也会彼此略有不同。

但是如果我需要想出一个想法，那就是估计连接的 RTT，您可以尝试查看第三个和第四个数据包之间所用的时间，因为第一个和第二个数据包可能被污染了通过沿路由的 ARP 和其他发现算法。

在您对 RTT 进行估算后，您可以尝试在此过程中对其进行改进，但我不确定您如何做到这一点。但是您不需要该程序的完整规范，只需要想法:-)

计算出 RTT 后，您可以尝试将数据包放入 RTT 箱中，并计算每个箱中飞行数据包的数量。通过这种方式，您将能够“绘制”估计的 cwnd（bin 中的数据包数）到时间并在那里尝试一些模式匹配。

另一种方法是沿着跟踪并尝试在您的脑海中“运行”不同的拥塞控制算法，并查看任何点的决定是否与您将完成的决定相匹配。这将需要一些宽大和准确的间隔。

这听起来绝对是一项有趣且具有挑战性的任务！

于 2009-04-01T13:02:19.347 回答