24-TCP 协议(拥塞控制)

1.概述

在学习拥塞控制前,我们假设:接收方总是有足够大的缓存空间,接收方的接收窗口大小总是很大——这意味着接收方对数据来者不拒。

在基于这样的理想条件上,如果发送方发送的数据接收方没有收到,那么大抵上可以判断为网络出现了拥塞。

2. 网络拥塞是怎么来的


这里写图片描述
图1 某个小型局域网

图 1 所示的是一个典型的小型局域网,SW 表示交换机,R 表示路由器。基于第 1 节中所述的假设,如果 PC1 给主机 PC3 发送 TCP 报文的时候,出现了丢失,我们大抵上就可以猜测:PC1—SW1—R1—R2—PC3 这条网络路径,出现了拥塞。

为什么会出现这种情况呢?可能有以下原因:PC1 发送数据的速度太快了,导致了 SW1、R1、R2 忙不过来。

实际上,无论是交换机也好,路由器也好,他们转发数据都是按照“存储+转发”的方式进行的——即接收到数据后先保存到自己的缓存,然后再挨个处理,发送到对应的接口。

所谓的 SW1、R1、R2 忙不过来,就是指这些设备的缓存有限,你发送太快,我没地方进行缓存,导致的结果就是将数据丢弃。

3. 如何避免拥塞

从图 1 中可以看到,路径上的任意一个节点都有可能“忙不过来”,那么发送方如何才能知道按照什么样的速度发送数据呢?

唯一的方法就是尝试各种不同的发送速度。比如一开始以 100kb/s 的速率发送数据,如果没问题,再将速率提高到 200kb/s,再没问题继续提升发送速率。一旦达到某个上限后,便开始出现丢包现象,发送方就可以认为,网络已经拥塞了,于是降低发送速率,减轻网络负担。

我们将上面这种探测网络拥塞的方法称为拥塞控制。当然了,上面这种方法实在是太简单了。

早在 1999 年,RFC 2581 就定义了四种拥塞控制算法:

  • 慢启动(slow-start)
  • 拥塞避免(congestiono avoidance)
  • 快重传(fast retransmit)
  • 快恢复(fast recovery)

有关这些算法,会在后面详细讨论。

4. 总结

  • 理解第 1 节中,为什么要提出这样的假设条件
  • 知道为什么网络会拥塞
  • RFC 定义了 4 种拥塞控制算法
说明:本文转自--Allen--,用于学习交流分享,仅代表原文作者观点。如有侵权,请联系我们删除~