25-TCP 协议(慢启动——观察)

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

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

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. 总结

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