在上一节，我们已经介绍了网络拥塞以及常用的拥塞控制算法，另外，我们还简单的讲述了如何试探性的去探测网络有没有拥塞。实际上，慢启动算法也是这样做的，只是比这个稍稍复杂一点。

在讲慢启动算法之前， 我们先做一个实验，观察一下。

1. 实验环境

服务器 unp/protocol/tools/tcpserver/psh_serv.c，部署在 Linux 上。客户端 unp/protocol/tools/winclient/psh_client.cpp，部署在 Windows 上。

为了能够有效的观察到现象，客户端一次发送了 1MB 的数据给服务器。

2. 实验步骤

Linux 上启动服务器 $ ./psh_serv 192.168.80.129 8000 Windows 上启动 OmniPeek 抓包，然后再启动 psh_client.exe psh_client.exe 192.168.80.129 8000 1 1048576

psh_client.exe 最后两个参数表示发送一次数据，大小为 1MB

3. 实验结果

图1 客户端发送的数据

由于数据比较多，我只截了一部分图放在这里，但是足以说明问题。

注意到图 1 中 Note 那一栏的备注，数字表明客户端连续发送了多少个 TCP 分组。

从图中我们可以观察到，客户端最开始发送了 2 个分组，接下来是 4 个，然后是 8 个，12 个，16 个，20 个。为什么客户端不一开始就连续发送 20 个呢？而是由少到多的增加呢？

实际上，这样做的目的就是为了防止一下子数据发多了，导致网络拥塞。图 1 中的这个过程，实际上就是慢启动算法所做的事情。不过，现在的慢启动算法相比最原始的慢启动算法要复杂的多，它综合考虑了太多的因素。

有关慢启动算法以及拥塞避免的相关细节，下一篇文章再详述。

4. 总结

观察慢启动现象理解为什么要有慢启动