偶然发现可靠的 UDP 实现

Question

我从学院收到了一项任务，我必须通过 UDP 又名实现可靠传输。 TCP Over UDP（我知道，重新发明轮子，因为这已经在 TCP 上实现了）以深入了解 TCP 的工作原理。其中一些要求是：3 次握手、拥塞控制（尤其是 TCP Tahoe）和挥手。我考虑用 Java 或 Python 来做这件事。

一些更具体的要求是：

收到每个 ACK​​ 后：

• （慢启动）如果CWND < SS-THRESH: CWND += 512
• （拥塞避免）If CWND >= SS-THRESH: CWND += (512 * 512) / CWND
• 超时后，设置SS-THRESH -> CWND / 2，CWND -> 512，在最后一个确认字节后重传数据。

我找不到有关 TCP Tahoe 实施的更多具体信息。但是据我了解，TCP Tahoe 是基于 Go-Back-N 的，所以我发现了以下发送方和接收方的伪算法：

我的问题是慢启动和拥塞避免阶段应该在if sendbase == nextseqnum 之后发生吗？也就是说，在确认收到预期的 ACK 之后？

我的另一个问题是关于窗口大小，Go-Back-N 使用固定窗口，而 TCP Tahoe 使用动态窗口。如何根据 cwnd 计算窗口大小？

Answer 1

注意：您的图片不可读，请提供更高分辨率的图片

1. 我不认为该算法是正确的。定时器应该与每个数据包相关联，并在收到该数据包的 ACK 时停止。当任何数据包的计时器触发时，就会触发拥塞控制。

2. TCP 不完全是 Go-Back-N 接收器。在 TCP 接收器中也有一个缓冲区。这不需要对发送方 Go-Back-N 进行任何更改。但是，TCP 也应该实现流控制，接收端告诉发送端它的缓冲区还有多少空间，发送端相应地调整它的窗口。

3. 注意，Go-Back-N 序列号计算数据包，而 TCP 序列号计算数据包中的字节数，您必须相应地更改算法。

4. 我建议您熟悉一下 rfc793。它没有拥塞控制，但它指定了其他 TCP 机制应该如何工作。此外this link 有一个很好的 TCP 窗口说明以及与之相关的所有变量。

我的问题是，如果 sendbase == nextseqnum，那么慢启动和拥塞避免阶段应该立即发生吗？也就是说，在确认收到预期的 ACK 之后？

您的算法只有在收到最后一个数据包的 ACK 时才会执行某些操作。正如我所说，这是不正确的。

无论如何。每个确认新数据包的 ACK 都应该触发窗口增加。您可以通过检查 send_base 是否因 ACK 增加而进行检查。

不知道是否每个 Tahoe 实现都这样做，但您可能也需要这样做。在三个连续的重复 ACK 之后，即不增加 send_base 的 ACK，您将触发拥塞响应。

我的另一个问题是关于窗口大小，Go-Back-N 使用固定窗口，而 TCP Tahoe 使用动态窗口。如何根据 cwnd 计算窗口大小？

您将N 设为变量而不是常量，并为其分配拥塞窗口。

在具有流控制的真实 TCP 中，您可以使用 N = min (cwnd, receiver_window)。