绊倒在可靠的UDP实现上

Question

我收到了一份来自学院的任务，在那里我必须通过UDP aka实现一个可靠的调动。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，并在上次确认的字节之后重新传输数据。

我找不到更多关于Tahoe实现的具体信息。但据我所知，TCP Tahoe基于回溯-N，因此我为发送方和接收方找到了以下伪算法：

​

​

​

​

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

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

Answer 1

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

1. 我不认为那个算法是正确的。当接收到该分组的ACK时，应将计时器与每个分组相关联并停止。当任何数据包的计时器触发时，都会触发拥塞控制。
2. TCP不完全是回溯-N接收器.在TCP协议中，接收器也有一个缓冲区。这不需要在发件人返回-N的任何更改。然而，TCP也应该实现流控制，其中接收方告诉发送方缓冲区中的剩余空间，然后发送方相应地调整其窗口。
3. 请注意，回溯-N序列号计数数据包，和TCP序列号计数字节的数据包，您必须相应地改变您的算法。
4. 我建议您对rfc793有所了解。它没有拥塞控制，但它指定了其他TCP机制应该如何工作。此外，此链接还很好地说明了TCP窗口及其相关的所有变量。

我的问题是，如果sendbase == nextseqnum，那么应该马上开始和避免拥塞的阶段吗？也就是说，在确认收到预期的ACK之后？

您的算法只在接收到最后一个数据包的ACK时才做一些事情。正如我所说，这是不正确的。

不管怎样。每一个确认新数据包的ACK都应该增加触发窗口。您可以通过检查send_base是否作为ACK的结果来检查这一点。

不知道如果每个Tahoe实现都这样做，但您可能也需要这一点。在三个相应的重复ACK(即不增加send_base的ACK)之后，您将触发拥塞响应。

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

您可以使N变量而不是常量，并将拥塞窗口分配给它。

在真正的具有流控制的TCP中，您可以执行N = min (cwnd, receiver_window)。