最近哪个TCP窗口更新？

如何解决最近哪个TCP窗口更新？

我正在编写一个TCP实现，完成了所有花哨的慢速和快速重传工作，并且一切都正常，所以我以为自己完成了。但是后来我查看了我的数据包接收功能（总共400行代码的几乎一半），并意识到我对基本流控制的理解还不完整...

假设我们有一个带有“发送方”和“接收方”的TCP连接。假设“发送方”没有发送任何东西，并且接收方先停滞然后取消固定。

由于“发送方”未发送任何内容，因此“接收方”看不到ack_no delta。因此，来自“接收器”的两个窗口更新如下：

1. ack_no = X，窗口= 0
2. ack_no = X，窗口= 8K

由于两个数据包具有相同的ack_no，并且可以在传输过程中对其进行重新排序，所以发送方如何知道先到哪个？

如果发件人不知道先到哪个，那么在接收到两个数据包之后，如何知道是否允许发送？

一个猜测是，也许永远不允许窗口的上端点减小？一旦接收者分配了接收缓冲区并进行了通告，它就永远不能取消通告吗？在那种情况下，可以通过以下代码可靠地处理窗口更新（为简单起见，假设没有窗口缩放比例）：

  // window update  (https://stackoverflow.com/questions/63931135/)
  int ack_delta = pkt_ack_no - c->tx_sn_ack;
  c->tx_window  = MAX(BE16(PKT.l4.window),c->tx_window - ack_delta);
  if (c->tx_window)
    Net_Notify(); // wake up transmission

但是从接收器的角度来看这很糟糕：它大大增加了可靠地支持10K连接所需的内存。协议肯定比这更聪明吗？

解决方法

有一个假设是接收缓冲区永远不会缩小，这是故意没有记录的以创建精英“游戏皮肤”俱乐部以限制 TCP 实现的数量。