我正在从Forouzan 的书中学习 TCP 。它解释了发件人侧窗口如下：
因为它定义了接收器窗口的大小如下：
rwnd = 接收器缓冲区大小 - 等待接收器进程消耗的字节数
然后它说：
- 发送方窗口关闭（将窗口的左墙向右移动），当它收到一些确认时
- 发送方窗口打开（将右墙向右移动），当接收方通信 rnwd 时，
新 ackNo + 新 rwnd > 旧 ackNo + 最后一个 rwnd- 在上述情况没有发生的情况下，发送窗口缩小（将右窗口向右移动）。
它显示发件人窗口的打开和关闭如下：
它不显示窗口缩小。我不明白为什么会发生收缩。如果您查看上面第一个引用文本中的 rwnd 公式，缩小将需要减少接收器缓冲区大小，对吗？如果是，那会发生吗（我觉得这个缓冲区大小必须是固定的）？如果是，为什么？由于运行 TCP 接收器的计算机的可用 RAM 减少？
接收缓冲区可以是固定大小，这在接收窗口中实际上没有任何作用，除了在接收窗口大小上放置一个绝对最大值。接收窗口的真正定义可以在RFC 793，传输控制协议中找到，它是 TCP 的定义。接收窗口在 RFC 中的几个地方进行了解释。例如：
流量控制：
TCP 为接收方提供了一种方法来管理发送方发送的数据量。这是通过返回一个带有每个 ACK 的“窗口”来实现的，该窗口指示除了成功接收的最后一个段之外的可接受序列号的范围。该窗口指示发送方在接收进一步许可之前可以传输的允许的八位字节数。
假设接收器具有 10,000 字节的固定缓冲区大小，并以该大小的接收窗口开始。如果它已收到 4,000 个字节，但应用程序进程尚未从接收缓冲区中消耗这些字节，则 TCP 将确认收到的字节，但指定接收窗口现在为 6,000 个字节，因为这是缓冲区中剩余的全部内容。接收器告诉发送器它应该在发送 6,000 个字节后停止发送更多数据，除非接收器给它一个不同的接收窗口大小。请记住，TCP 是一个进程，而不是应用程序进程，TCP 将根据其可用资源维护连接和接收窗口，这些资源被填充直到应用程序进程开始消耗数据并释放 TCP 资源。
它不显示窗口缩小。
该图似乎显示了发送窗口的缩小和扩展（从 800 到 600 到 400，然后在客户端返回到 600）。它还显示接收窗口（在服务器上）随着接收数据而缩小，直到应用程序进程消耗来自 TCP 的一些数据，此时接收窗口随着消耗的数量而增长。
TCP 没有客户端或服务器，它在两个对等点之间创建连接，所以我不确定这本书为什么暗示了这一点；它只会混淆视听。在这种情况下，客户端是发送方，服务器是接收方，这与许多人使用的情况相反。任一 TCP 对等体都可以发送和接收（每个都是发送方和接收方）。TCP 的 RFC 没有提到客户端或服务器。