看完之后这问题我仍然对基于 TCP 的通信环境中接收窗口和拥塞窗口之间的关系感到困惑。
答案指出，为了确保“最佳”吞吐量，拥塞窗口会扩大（对于成功传输的段，每个收到的 ACK 都会加倍），然后在达到拥塞时减半（ACK 不再以发送数据的速率返回）。
但是，它没有说明如何计算接收窗口以及它与拥塞窗口的关系。这两者之间的关系是什么？
答案1
接收窗口是接收者可以一次处理而不会被淹没。这是接收方施加的流量控制。
拥塞窗口（注意：是“拥塞窗口”；没有“传输窗口”，所以你的标题有点不对）是指网络（发送方和接收方之间的路由器）可以立即处理而不会被淹没（即不会引起或加剧拥塞）。拥塞窗口可以被认为是发送方强加的流量控制的一种形式。
在我们了解拥塞窗口之前，让我们先了解一下接收窗口的细节。
接收窗口是指在接收应用程序从接收 TCP 堆栈读取等待数据并释放这些内核缓冲区之前，接收 TCP 堆栈愿意接收和缓冲多少数据给接收应用程序。接收窗口的大小可能受特定于实现的细节限制。例如，类 Unix 内核可能会根据内核愿意为每个 TCP 连接分配多少个内核消息缓冲区 (mbuf) 来限制接收窗口大小。
假设您不受接收器资源的限制，您可以计算出用于给定 TCP 连接的最佳接收窗口。基本上，接收窗口至少应为 TCP 连接的“带宽 * 延迟乘积”（BDP）。因此，以典型的 1300Mbps 802.11ac 为例，如果您拥有 1,300,000,000 比特/秒的链接（这是您的带宽），往返时间（RTT；想想“ping 时间”；这是您的延迟）为 0.003 秒，您的接收窗口至少应为 1,300,000,000 比特/秒 * 0.003 秒 = 3,900,000 比特，约为 476KiBytes。将接收窗口的大小调整为 BDP 可让发送方“填充管道”，向网络发送尽可能多的数据，直到有足够的时间将 Ack 返回给发送方。如果低于这个值，发送方将无法连续传输；相反（一旦 TCP 慢启动足够快），它将发送一个接收窗口大小的突发，但它会在收到 Ack 回复（告知它接收窗口中有更多空间）之前将该突发注入网络。因此，它必须暂停并等待该 Ack，然后才能知道它可以发送更多内容而不会压垮接收方的 TCP 堆栈。它暂停并等待 Ack 的时间就是它本可以用于传输的时间。
这就是接收窗口的含义及其计算方法。现在让我们看看拥塞窗口。
拥塞窗口是发送方跟踪的事物之一，以确保它不会导致发送方和接收方之间的网络跳数（路由器、路由器间链路）出现网络拥塞。最终，显式拥塞通知 (ECN) 等创新技术将得到广泛部署，允许路由器通知 TCP 发送方拥塞。但在此之前，TCP 发送方需要尝试以其他方式检测和避免拥塞，其中大部分来自开始缓慢传输数据包以探测网络在不丢失数据包的情况下可以传输多快的速度，将数据包丢失解释为拥塞的迹象，在发生丢失时大大降低数据包传输速率，然后缓慢地再次增加。
目前 TCP 拥塞控制标准 RFC 是RFC 5681，表示拥塞窗口最初应计算为 TCP 最大段大小 (MSS；类似于 TCP 层 MTU 的等效值) 的 2-4 倍；具体来说，是 TCP MSS 的 2-4 倍，发件人正在跟踪。这是发送方 MSS 或 SMSS。RFC 还规定，发送方应遵循拥塞窗口和接收窗口之间较低的值。也就是说，即使网络速度快且不拥塞（因此拥塞窗口已经变得比接收窗口大），也没有必要向网络发送比接收方能够处理的数据更多的数据；这最终只会让接收方不堪重负，并导致它在数据包成功穿过网络后将其丢弃。
这就是拥塞窗口和接收窗口之间的关系。一个是接收方流量控制，这样接收方就不会不堪重负，另一个是发送方流量控制，这样网络中的路由器就不会不堪重负。在决定是否可以发送更多数据包时，TCP 发送方必须同时查看拥塞窗口和接收窗口，并遵循较低者。
拥塞窗口通常从大约 3 个 SMSS（3 * 1448 字节 = 4344 字节）开始，在 TCP 慢启动期间，假设至少 1 个 SMSS 的先前未确认字节已确认，则拥塞窗口每确认增加最多 1 个 SMSS（1448 字节）。慢启动后，拥塞避免算法启动，拥塞窗口每 RTT 增加不超过 1 个 SMSS。如果发送方检测到数据包丢失，它会将其解释为拥塞，并将拥塞窗口基本减半，以方便恢复丢失（快速重传/快速恢复，由“三重重复确认”触发），并将其削减至 1 个 SMSS，以应对更严重的丢失情况（在重传计时器到期之前未收到确认）。
请注意，您的问题有误。说发送方收到确认后拥塞窗口会加倍是错误的。拥塞窗口通常从 3 条 SMSS 开始，每收到一条确认 SMSS 最多增加一条 SMSS。当发生丢失时，拥塞窗口基本上会减半甚至更糟。事实上，拥塞窗口调整策略通常总结为“加法增加，乘法减少”。