问题标签 [congestion-control]

如 RFC 3286 中所述：

“...端点必须管理发送和接收的字节以及发送和接收的 TSN 之间的转换，因为 TSN 是按块而不是按字节”。

这对拥塞控制算法有何影响？

我想要一个程序来确定在捕获的 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 算法的部署信息。该项目的目标是：

在谈论 UDP 时，我看到/听到过几次拥塞。这意味着什么？

我正在使用 Netkit 玩各种 TCP 算法。

有两台机器c1和c2由路由器连接，强制延迟为 200 毫秒。c1上的程序每 1ms 向c2发送 100 字节的数据包（TCP_NODELAY 已打开）。Reno 被用作两台机器上的拥塞控制。

根据 tcpdump，只有前 2 个数据包立即发送（200 字节），然后c1停止发送并等待 ACK。接收方的窗口大约是 2MSS（MSS=1460），所以我猜是 CWND 阻止了c1发送更多数据包。

根据 Reno 规范，初始 CWND 为 1MSS。我在那里遗漏了什么吗？.. 即使发送 1 字节的数据包也会给出相同的图片，发送 2 个数据包，然后发送方等待 ACK。可能是初始 CWND 大小是由初始段大小而不是 MSS 决定的吗？

ip route show cache显示类似

cache mtu 1500 rtt 361ms rttvar 360ms cwnd 5 advmss 1460 hoplimit 64

我想知道这是否意味着CWND = 5MSS？

到目前为止，Linux 中的命令“sysctl”会全局更改整个系统的拥塞控制算法。但是拥塞控制，其中 TCP 窗口大小和其他类似参数是变化的，通常是每个 TCP 连接完成的。所以我的问题是：

• 是否存在可以更改每个 TCP 连接使用的拥塞控制算法的方法？

还是我在这里遗漏了一些微不足道的东西？如果是这样，它是什么？

我正在检查的痕迹有点问题。我知道如果窗口大小随着每个段之间发送的 ACK 数量的增加而增加，并且它会随着 ACK 段的大小而增加，则连接启动缓慢。但是，我的跟踪开始显示的数字不相加（下面的屏幕截图）。我不知道数据包 6 的窗口大小是如何计算的，因为数学并没有与之前的窗口大小和中间的 ACK 相加。任何人都可以对此有所了解吗？

我也不知道如何发现慢启动何时成为避免拥塞。有什么我可以在跟踪中注意的吗？

慢启动似乎只持续到数据包 13，所以我是否应该假设拥塞避免已经接管？

http://img10.imageshack.us/f/tcptrace.jpg/

感谢您提供的任何帮助！对此，我真的非常感激

所以我创建了以下脚本：

它在大多数情况下运作良好。但是，在随机情况下，我会收到一个错误（在正在上传的图像列表中的一个随机点）“连接被强制关闭：预期保持打开的连接被服务器关闭”。我认为这是某种拥塞问题，我无法在 Google 上找到很多解决此问题的方法。所以我想知道是否有人知道在上传图像文件时从客户端减少服务器拥塞的方法，或者是否有更有效的上传图像的方法，或者是否有像每次注销 SharePoint 网站这样的解决方案15张图片，然后重新登录会起作用吗？提前感谢您的帮助！

我为 Mac OS X [1]找到了一个替代的开源 TCP 实现，它使用 LEDBAT 作为拥塞控制，而不是 NewReno。

• 由于我对该操作系统不太熟悉，您能否建议我如何构建该源文件并将其加载到系统中？

（例如，我想知道是否有一种方法可以像在 Linux 中那样，有一些实现[2]可以很容易地构建，然后作为模块插入内核并加载运行时：

)

[1] http://opensource.apple.com/source/xnu/xnu-1699.22.81/bsd/netinet/tcp_ledbat.c

[2] http://perso.telecom-paristech.fr/~valenti/pmwiki/pmwiki.php?n=Main.LEDBAT#howtokernel

谢谢

我在我的 Mint/Debian 盒子上安装了非常简单的 CouchDB。我的 Java webapp 在查询 CouchDB 时遇到了相当长的延迟，所以我开始寻找原因。

编辑：查询模式是很多小查询和小 JSON 对象（如 300 字节向上/1Kbyte 向下）。

Wireshark 转储非常好，主要显示 3-5 毫秒的请求-响应周转时间。JVM 帧采样向我展示了套接字代码（对 Couch 的客户端查询）有些忙，但没有什么了不起的。然后我尝试使用 ApacheBench 和 oops 进行分析：我目前看到 keep-alive 在非持久设置上引入了稳定的额外 39 毫秒延迟。

有谁知道如何解释这个？也许持久连接会增加 TCP 层上的拥塞窗口，然后由于 TCP_WAIT 和较小的请求/响应大小或类似的东西而空闲？是否应该为环回 tcp 连接打开此选项（TCP_WAIT）？

使用保持活动运行，每个请求平均 40 毫秒

没有keepalive，瞧——每个请求1 ms，主要是。

好的，现在保持活动状态，但也要求通过 http 标头关闭连接。每个请求也需要 1 毫秒左右。

假设两个对等方 Alice 和 Bob 通过 IP 网络连接。Alice 和 Bob 正在交换有损压缩数据包，这些数据包是实时生成和消费的（想想 VoIP 或视频聊天应用程序）。该服务旨在应对可用带宽最少的情况，但依赖于低延迟。Alice 和 Bob 将使用适当的 QoS 配置文件标记他们的连接。

Alice 和 Bob 希望使用可变比特率压缩，并希望消耗所有剩余带宽可用于他们之间的连接，但会根据网络状态自愿降低消耗的比特率。然而，他们希望保持稳定的链接，即避免由于拥塞和带宽调整前的延迟而导致解码数据流中断。然而，他们完全有可能丢失一些数据包。

TL;DR：Alice 和 Bob 想从头开始实施 VoIP 协议，并对带宽和拥塞控制感到好奇。

您建议 Alice 和 Bob 阅读哪些论文和资源？主要在带宽估计和拥塞控制领域。