阻塞窗口的单位和行为是什么？

Question

我了解到拥塞窗口是可以在一轮传输中发送的最大数据包数量。现在TCP似乎以字节来确认数据包，所以用字节来定义拥塞窗口不是更有意义吗？那么，如何才能让确认和拥挤窗口一起工作呢？

我希望在RFC 5681上找到更多的信息，但是在阅读完之后，我仍然没有答案。

RFC似乎是基于SMSS (发送者最大段大小)来度量拥塞窗口，这将是字节，而不是包数量。

此外，RFC还提到拥塞窗口增加了最大的SMSS，这实际上不允许指数增长。

那么，在缓慢启动时，拥塞控制到底是如何工作的呢？

编辑：

1. RFC的以下部分让我感到困惑：

在慢速启动期间，对于每个接收到的累计确认新数据的ACK，TCP增量最多为SMSS字节。慢启动结束时，当cwnd超过ss阈值(或者，可选地，当它到达它时，如上所述)或当观察到拥塞时。传统上，TCP实现在收到涵盖新数据的ACK时通过精确的SMSS字节增加cwnd，但我们建议TCP实现增加cwnd，如下：

  cwnd += min (N, SMSS)                      

它说，拥塞窗口增加N，它被称为the number of previously unacknowledged bytes acknowledged in the incoming ACK.或SMSS，这取决于哪个窗口更小。这意味着拥塞窗口是以字节为单位的？那怎么可能是指数呢？

Answer 1

接收窗口与发送方共享，在发送方必须暂停等待确认之前可以发送多少数据。

拥塞窗口与确认无关(除了通知它丢失的部分)。拥塞窗口只有发送方知道，它是发送方可以发送的突发发送量(只要接收窗口仍然打开)。发送方使用拥塞窗口来了解在出现问题之前它会爆炸多少。

发送方缓慢地增长拥塞窗口，直到出现问题，然后当它了解到问题时，它将大大缩小拥塞窗口。届时，挤塞窗口会慢慢扩大，直至再次出现问题，届时挤塞窗口会再次大幅缩减。

接收方不知道这一点，它只是确认它接收到的段，这可以通知发送方丢失的段，从而使发送方意识到存在问题，此时发件人将调整发送窗口。

拥塞窗口和接收窗口是分开的。接收窗口由接收方维护并与发送方共享，而拥塞窗口由发送方维护，但不与接收方共享。