22.TCP协议-观察慢启动的发包过程(拥塞控制算法)

在上一节，我们已经介绍了什么是网络拥塞以及常用的拥塞控制算法；

另外，我们还简单的讲述了如何试探性的去探测网络有没有拥塞；实际上，慢启动算法也是这样做的，只是比这个稍稍复杂一点；

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

实验环境

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

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

实验步骤

• Linux 上启动服务器

$ ./psh_serv 192.168.80.129 8000

• 1

• Windows 上启动 OmniPeek 抓包，然后再启动 psh_client.exe

psh_client.exe 192.168.80.129 8000 1 1048576

• 1

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

实验结果

图1 客户端发送的数据 

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

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

从图中我们可以观察到，客户端最开始发送了 2 个分组，接下来是 4 个，然后是 8 个，12 个，16 个，20 个；

为什么客户端不一开始就连续发送 20 个呢？而是由少到多的增加呢？

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

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