问题标签 [congestion-control]

如果我如下所示更改系统范围的 TCP 拥塞控制算法，它是否也会影响已建立的连接？对它们有任何不利影响还是无缝发生？

# echo reno > /proc/sys/net/ipv4/tcp_congestion_control

我正在编写一个程序，它将一个小的 UDP 数据包（大约 100 字节）发送到很多目的地（包括一些真实的目的地，而所有其他目的地都是伪造的目的地）。

如果我发送到少数目的地，真正的目的地可以收到数据包。

如果我在每次发送之间没有休眠的情况下发送到大量目的地，那么只能接收到一些真实的目的地，或者它们都无法接收到数据包。

如果我发送到大量目的地，并且每次发送之间都处于正确的睡眠状态，那么只有一些真实的目的地可以接收到，或者它们都不能接收到数据包。

这是示例代码：

有人知道这个问题吗？它从何而来？我该如何解决？
使用我的解决方法（添加睡眠），我如何计算正确的毫秒数？

我正在iperf3对不同服务器上的多个发送者进行简单的实验，将TCP流量发送到另一台服务器上的单个接收者。

iperf3在此实验期间每 0.1 秒报告一次拥塞窗口 ( Cwnd)（以 KBytes 为单位）。我还在tcp_probe实验期间记录了内核模块的输出，它显示了每次变化时的拥塞窗口（分段）。我将tcp_probe-reported拥塞窗口乘以 1500（MTU 大小）以获得以字节为单位的拥塞窗口。我预计拥塞窗口会匹配，但我发现 iperf3 报告的拥塞窗口大小约为tcp_probe. 一旦被这个乘法因子校正，它们就完全一致了。为什么会出现这种情况？哪一个是对的？

我运行的命令是：

我尝试查看iperf3和tcp_probe的源代码，但没有发现任何可疑之处。

我一直在阅读《计算机网络：一种自顶向下的方法》一书，遇到了一个我似乎不明白的问题。

正如我所读到的，TCP 拥塞控制具有三种状态：慢启动、拥塞避免和快速恢复。我很了解慢启动和拥塞避免，但快速恢复非常模糊。这本书声称 TCP 的行为方式是这样的：（cwnd=拥塞窗口）
让我们看下图：

正如我们所看到的，在第 16 轮，发送方发送了 42 个段，并且由于拥塞窗口大小已减半（+3），我们可以推断出有 3 个 Duplicate-ACK。这个问题的答案声称 第 16 到 22 轮之间的轮次处于拥塞避免状态。但为什么不快速恢复？我的意思是，在三个重复的 ACK 之后，TCP 进入快速恢复并且每隔一个重复的 ACK 应该会增加拥塞窗口。为什么图表没有表示这一点？我能想到的唯一合理的解释是，在这张图中，只有三个重复的 ACK，并且此后收到的 ACK 都不是重复的。

即使是这样，如果有超过 3 个重复的 ACK，图表会是什么样子？**

上图中是否有快速恢复的表示？为什么不/是？

** 很长一段时间以来，我一直在努力回答这个问题。我会很高兴得到任何答复，谢谢！

更新这里的图像。我认为一轮定义为当窗口中的所有段都被确认时。在照片中，圆形显示为圆形。 为什么 cwnd 在 Fast Recovery 状态下会呈指数增长？（在我不小心写成权宜之计而不是指数级的图像中）

我在 Solaris 中使用以下命令来设置最大 CWND 窗口大小：

但我不知道它在 Linux 中的等价物。任何人都可以帮助我吗？注意：我想设置最大尺寸而不是初始尺寸。先感谢您。

我正在iperf通过 10Gbit 链路连接的两台服务器之间运行测量。我正在尝试将我观察到的最大窗口大小与系统配置参数相关联。

特别是，我观察到最大窗口大小为 3 MiB。但是，我在系统文件中找不到相应的值。

通过运行，sysctl -a我得到以下值：

第一个值告诉我们最大接收器窗口大小为 6 MiB。然而，TCP 倾向于分配两倍的请求大小，因此最大接收器窗口大小应该是 3 MiB，正如我测量的那样。来自man tcp：

请注意，TCP 实际上分配的缓冲区大小是 setsockopt(2) 调用中请求的缓冲区大小的两倍，因此后续的 getsockopt(2) 调用将不会返回与 setsockopt(2) 调用中请求的缓冲区大小相同的缓冲区。TCP 将额外空间用于管理目的和内部内核结构，并且 /proc 文件值反映了与实际 TCP 窗口相比更大的大小。

但是，第二个值net.core.rmem_max表示最大接收器窗口大小不能超过 208 KiB。这应该是硬限制，根据man tcp：

tcp_rmem max：每个 TCP 套接字使用的接收缓冲区的最大大小。此值不会覆盖全局net.core.rmem_max. 这不用于限制在套接字上使用 SO_RCVBUF 声明的接收缓冲区的大小。

那么，我怎么会观察到大于中指定的最大窗口大小net.core.rmem_max？

注意：我还计算了带宽延迟乘积：window_size = Bandwidth x RTT大约为 3 MiB（10 Gbps @ 2 毫秒 RTT），从而验证了我的流量捕获。

• 发送者发送数据。
• Receiver 等待几秒钟，然后计算吞吐率 / s
• 接收方将其接收数据包的速率（字节/秒）发送给发送方
• 发送方计算其发送数据包的速率
• 如果发送方的速率明显更高，则降低它以匹配接收速率。

或者，更高级的方法：

• 发件人以预定义的最小速率（例如 1kb / s）开始发送
• 接收方将计算的接收率发送回发送方。
• 如果接收速率与发送速率相同（考虑延迟），则将速率增加一个设定的 pct（例如 rate * 2）
• 继续这样做，直到发送速率高于接收速率。
• 如果需要，请继续监控速率以考虑带宽增加/降低速率的变化。

如果您要实现自己的 UDP 拥塞控制算法，这是否可行？

我正在尝试更改 Centos 7 上的 tcp 拥塞控制。

我检查了什么算法：

我想更改为 htcp 但是当我检查它是否可用时：

所以，首先我没有看到 CUBIC，也没有看到 HTCP。如何启用 HTCP 拥塞控制。

拥塞控制是网络现象，那么为什么以及如何在传输层进行处理。网络中的中间设备（路由器）之间发生拥塞。但是昨天我正在阅读一篇论文（TCP 的主机到主机拥塞控制，Alexander Afanasyev，Neil Tilley，Peter Reiher 和 Leonard Kleinrock）。在这里我们可以看到标题，主机到主机拥塞控制。所以另外，我想问一下，如果网络之间出现拥塞，那么控制它是网络层的职责，但是我们可以看到，传输层控制它。? 如何 ？传输层如何知道网络之间发生了拥塞。?

我知道 MPTCP 有自己的拥塞控制，例如“耦合”。但是，MPTCP 位于 TCP 层。TCP已经有原始的。这些是重复地一起工作，还是只有 MPTCP 独立地工作？

在一起的情况下，似乎出现了 HOL-Blocking 问题，就像 HTTP/2 的情况一样。