问题标签 [congestion-control]

在 FACK 论文（MM' 96）中，我不明白这个说法：如果发送方收到一个 ACK​​，它在重新传输段时将 snd.fack 推进到 snd.nxt 的值之外（并且重新传输的段在其他情况下是下落不明的for)，发送方知道重传的那个段已经丢失。

有人可以对此提供更多解释或示例吗？MM96链接： FACK MM96

为什么拥塞控制过程部署在发送节点？

我知道避免在路由器上部署拥塞控制的限制之一是路由器需要维护流状态，这增加了路由器的负担。撇开这个不谈，还有其他限制在路由器端部署拥塞的缺陷吗？

我想在 ns2 模拟器中绘制 ddos​​ 攻击。还想计算丢包率并比较流量的 xgraph。

文档说 TCP 窗口更新通常是由于以前的零窗口。

我找不到以前的零窗口。还可能是什么？

拥塞避免算法是从 cwnd>=ssthresh 开始还是仅从 cwnd>ssthresh 开始？

cwnd=拥塞窗口 ssthresh=慢启动阈值

谁能帮我找到ubuntu中TCP的最大拥塞窗口值？我只找到初始化窗口大小；我找不到最大值。我只能找到初始窗口大小。我需要最大值，它与 tcp 的缓冲区大小有关吗？

当 TCP Tahoe 或 Reno 观察到丢失事件时，阈值将重置为最后一个拥塞窗口 (CW) 的一半。当之前的 CW 是奇数时，新的阈值是 的下限还是上限CW/2？

我正在使用 NS2，我的 Ubuntu 16.04 上有 2.35 版本，内核为 4.4.0。我的 Ubuntu 的默认 TCP 拥塞算法是 CUBIC。

当我在 NS2 中制作 Linux TCP 代理时，他们究竟使用了哪种拥塞控制算法？

起初，我以为他们会使用 CUBIC，这是我的 Linux 的默认算法，但是使用 NS2 的 CUBIC 代理和 Linux 代理进行实验我得到了完全不同的结果，所以我得出的结论是 Linux 代理没有使用 CUBIC，或者至少他们没有使用 CUBIC正在使用它的修改版本。有谁知道 Linux TCP 代理在 NS2 版本 2.35 中使用的算法到底是什么？

我正在使用 netty 来开发将通过 TCP 侦听特定端口的应用程序。一旦收到字节，我就有一个带有业务逻辑的管道，可以在收到的字节上运行。该管道由多个通道处理程序组成，如标头解码器、应用程序级碎片处理程序等。在管道结束时，一旦处理完消息，管道中的最后一个处理程序（例如 BufferWriter）会将处理后的消息放入阻塞队列。这个阻塞队列就像缓冲区一样，而 BufferWriter 就像生产者一样。请注意，此阻塞队列在所有通道之间共享。因此，应用程序接收到的所有数据都将写入单个队列。还有另一个预定的执行器服务将作为这个缓冲区的消费者。这个消费者是周期性任务，它以特定的时间间隔运行并从缓冲区获取消息并写入文件。

我遇到的问题是，当有大量传入流量时，我的消费者线程无法跟上步伐。导致缓冲区队列变满。

在netty中，有什么办法可以降低socket的读取速度，让消费者跟上生产者的步伐？比如，一旦缓冲区满了，netty 就不会从套接字读取，只要缓冲区有空间，它就会继续从套接字读取。

请注意，在这种情况下，发送者不是用 java/netty 编写的。它们是 c 程序，它将与我的服务器形成 TCP 连接并开始发送数据。我假设，当我减慢服务器套接字读取速率时，TCP 将使用拥塞控制策略自动减慢发送方（慢启动）

问题

假设您使用 TCP 通过网络传输一个 4 MB 的文件。接收方通告 4 MB 的接收窗口。假设重传定时器在 5 个 RTT 后到期。

(a) 如果 TCP 发送 4KB 段，假设没有段丢失，发送文件需要多少 RTT？

(b) 描述如果在发送窗口达到 1MB 后发送的第一个段丢失会发生什么情况。假设您使用的 TCP 版本没有实现快速重传和快速恢复。发送文件需要多少 RTT？

(c) 现在假设您使用的 TCP 版本实现了快速重传和快速恢复。你的 TCP 实现了快速重传和快速恢复，节省了多少 RTT？

我最近开始研究拥塞控制，但我对重传/恢复的速度与普通重传有何不同感到困惑。请解释一下。