偶然發現可靠的 UDP 實現

Question

我收到了學院的一項任務，我必須通過 UDP aka 實現可靠的轉移。 TCP 超過 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 之后？

我的另一個問題是關於 Window 大小，Go-Back-N 使用固定的 window 而 TCP Tahoe 使用動態 Z044B8C742CBD962FBFF235 如何根據 cwnd 計算 window 大小？

Answer 1

注意：您的圖片不可讀，請提供更高分辨率的圖片

1. 我不認為該算法是正確的。 定時器應該與每個數據包相關聯，並在收到該數據包的 ACK 時停止。 當任何數據包的計時器觸發時，就會觸發擁塞控制。

2. TCP 不完全是 Go-Back-N 接收器。 在 TCP 接收器中也有一個緩沖區。 這不需要對發送方 Go-Back-N 進行任何更改。 但是，TCP 也應該實現流控制，其中接收方告訴發送方其緩沖區中剩余多少空間，發送方相應地調整其 window。

3. 請注意，Go-Back-N 序列號計數數據包和 TCP 序列號計數數據包中的字節，您必須相應地更改算法。

4. 我建議對 rfc793 有所了解。 它沒有擁塞控制，但它指定了其他 TCP 機制應該如何工作。 此鏈接也有一個很好的說明 TCP window 以及與之相關的所有變量。

我的問題是，如果 sendbase == nextseqnum，那么慢啟動和擁塞避免階段應該立即發生？ 也就是說，在確認收到預期的 ACK 之后？

您的算法僅在收到最后一個數據包的 ACK 時才執行某些操作。 正如我所說，這是不正確的。

不管。 每個確認新數據包的 ACK 都應該觸發 window 增加。 您可以通過檢查send_base是否由於 ACK 的結果而增加來檢查這一點。

不知道是否每個 Tahoe 實現都這樣做，但您可能也需要這個。 在三個連續的重復 ACK 之后，即不增加send_base的 ACK，您將觸發擁塞響應。

我的另一個問題是關於 Window 大小，Go-Back-N 使用固定的 window 而 TCP Tahoe 使用動態 Z044B8C742CBD962FBFF235 如何根據 cwnd 計算 window 大小？

您使N變量而不是常量，並將擁塞 window 分配給它。

在具有流量控制的真實 TCP 中，您執行N = min (cwnd, receiver_window) 。