慢启动与拥塞窗体

在局域网中，发送方一開始便向网络发送多个报文段，直至达到接收方通告的窗体大小为止。

可是。假设收发两方不在同一个局域网中，那么发送方一直发送可能会出问题，由于中间路由器有可能发生拥塞。拥塞是指一个或者多个交换点的数据报超载而导致时延剧烈添加的现象。

为了解决问题，TCP支持一种被称为“慢启动”的算法，该算法通过观察到新分组进入网络的速率应该与还有一端返回确认的速率同样而进行工作。为了控制拥塞，TCP使用了第二个窗体（第一个是控制流量的滑动窗体）限制，即拥塞窗体限制。

拥塞窗体是发送方使用的流量控制，而滑动窗体则是接收方使用的流量控制。

刚建立TCP时，拥塞窗体大小为1个报文段。此时。发送方一次仅仅能发送一个报文段。

每收到一个ACK。拥塞窗体就添加一个报文段。所以这是一种指数增长。发送方取拥塞窗体与滑动窗体中的较小值作为发送上限。当发送方窗体开得过大时。中间路由器開始丢弃分组，这就通知发送方要它的窗体变小。

对于拥塞窗体大小的限制採用慢開始和乘法减小两种技术：

• 慢启动：拥塞窗体随着一个确认的到达，拥塞窗体的大小每次添加一个报文段。拥塞窗体大小呈指数增长。
• 乘法减小的拥塞避免策略：一旦发现报文段丢失。就把拥塞窗体的大小减半（直到减至最小的窗体，窗体中应至少包括一个报文段）。

以下通过离散的时间序列，观察拥塞控制协议：

黑色部分就代表一个个报文段。每一个矩形上半部分表示发送方发往接收方的数据，下半部分表示接收方发往发送方的确认信号。左边8个时间单元time0—time7就表示一个往返时间RTT。

发送方在time7收到一个ACK，此时拥塞窗体添加到2。time8—time9便发送了两个报文段。当收到这两个报文段的ACK后，拥塞窗体添加到4。例如以下所看到的：

最后在time31。管道被填满。连接达到理想稳定状态。

拥塞经常出如今下列情况：

• 大管道向小管道发送数据。如以太网向外网数据传输。

• 路由器的输入流大于输出流。

基本上能够总结为网络中某个节点忙只是来。

第一种情况例如以下图所看到的：

中间带宽较窄的为广域网。两側带宽较宽的为局域网。瓶颈路由器R1在单位时间内的接收数据量始终大于发送数据量，导致拥塞，当R1接收到数据的累积量超过了它的缓存。终于会导致路由器R1丢弃分组。

參考：

《TCP/IP具体解释》 P216-P221.