在上一节,我们已经介绍了什么是网络拥塞以及常用的拥塞控制算法;
另外,我们还简单的讲述了如何试探性的去探测网络有没有拥塞;实际上,慢启动算法也是这样做的,只是比这个稍稍复杂一点;
在讲慢启动算法之前, 我们先做一个实验,观察一下;
实验环境
- 服务器
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 中的这个过程,实际上就是慢启动算法所做的事情。不过,现在的慢启动算法相比最原始的慢启动算法要复杂的多,它综合考虑了太多的因素。
有关慢启动算法以及拥塞避免的相关细节,下一篇文章再详述。