详解TCP流量控制以及拥塞控制

90 阅读 0 评论 60 点赞

我是靠谱客的博主烂漫狗，最近开发中收集的这篇文章主要介绍详解TCP流量控制以及拥塞控制，觉得挺不错的，现在分享给大家，希望可以做个参考。

概述

1、TCP的流量控制

使用滑动窗口协议实现流量控制。防止发送方发送速率太快，接收方缓存区不够导致溢出。接收方会维护一个接收窗口 receiver window（窗口大小单位是字节），接受窗口的大小是根据自己的资源情况动态调整的，在返回ACK时将接受窗口大小放在TCP报文中的窗口字段告知发送方。发送窗口的大小不能超过接受窗口的大小，只有当发送方发送并收到确认之后，才能将发送窗口右移。

发送窗口的上限为接受窗口和拥塞窗口中的较小值。接受窗口表明了接收方的接收能力，拥塞窗口表明了网络的传送能力。

问题：接收窗口为0时会如何？

如果接收方没有能力接收数据，就会将接收窗口设置为0，这时发送方必须暂停发送数据，但是会启动一个持续计时器(persistence timer)，到期后发送一个大小为1字节的探测数据包，以查看接收窗口状态。如果接收方能够接收数据，就会在返回的报文中更新接收窗口大小，恢复数据传送。

2、TCP的拥塞控制

超时重传机制

超时重传机制主要是为了解决数据包在传输过程中丢失的问题。

TCP每发送一个报文段，就会为这个报文段开启一个定时器，如果定时器溢出时仍然没有收到接收端的应答报文，那么TCP就认为这个报文段在传输过程中丢失，然后重新发送这个报文段。这便是超时重传机制

举例：客户端请求发送”and hi”报文段时启动了定时器，然而在规定的时间内没有收到对端的回复，所以重新发送”and hi”报文段，并重启定时器(重启的定时器时间会增大)。

拥塞控制：

超时重传是为了解决数据丢失的问题，而数据丢失的原因很大程序上是由于传输路径拥塞导致的。

在正常的传输过程中，数据是从一个路由器跳到下一个路由器，每个路由器都有自己的缓冲区，新来的数据会存放在缓冲区中，与此同时路由器也在不断地将缓冲区中的数据发送给下一个路由器。但是如果某个路由器接收数据的速率大于发送数据的速率，就会导致缓冲区数据累积，最终填满缓冲区。此时如果再有数据到来，缓冲区已经无法容纳它们，只能将它们丢掉，造成数据丢失，这就是所谓的拥塞现象，本质就是传输路径上的节点不平衡。为了解决这一问题，就需要当出现拥塞现象时立即减少发送端发送的数据量，为路径上的某些节点提供清空缓冲区的时间，同时也避免了不必要的重传。

但是，发送端如何才能得知网络中发生了拥塞呢。因为由于硬件错误造成的数据丢失是很罕见的，所以发送端假定，如果出现了数据丢失，那么就可以认定发生了拥塞。

发送方维持一个叫做拥塞窗口cwnd（congestion window）的状态变量。拥塞窗口的大小取决于网络的拥塞程度，并且动态地在变化。发送方让自己的发送窗口等于拥塞窗口，另外考虑到接受方的接收能力，发送窗口等于拥塞窗口和接收窗口中的最小值。

四个传输过程中的算法：

（1）慢开始

慢开始算法的思路就是，不要一开始就发送大量的数据，先探测一下网络的拥塞程度，也就是说由小到大逐渐增加拥塞窗口的大小。

这里用报文段的个数的拥塞窗口大小举例说明慢开始算法，实时拥塞窗口大小是以字节为单位的。

刚开始发送数据时，先把拥塞窗口（congestion window，cwnd）设置为一个最大报文段MSS的数值，每收到一个新的确认报文之后，就把拥塞窗口加1MSS。这样每经过一个传输轮次（或者说是每经过一个往返时间RTT），拥塞窗口的大小就会加倍（指数增长）。比如，第一轮传一个，收到一个加一个，cwnd变为2MSS。第二轮传两个，收到两个加两个，cwnd变为4MSS。

（2）拥塞避免

当拥塞窗口的大小达到慢开始门限(slow start threshold)时，拥塞避免算法让拥塞窗口缓慢增长，即每经过一个往返时间RTT就把发送方的拥塞窗口cwnd加1，而不是加倍。这样拥塞窗口按线性规律缓慢增长。

无论是在慢开始阶段还是在拥塞避免阶段，只要发送方判断网络出现拥塞（其根据就是没有收到确认，虽然没有收到确认可能是其他原因的分组丢失，但是因为无法判定，所以都当做拥塞来处理），就把慢开始门限设置为出现拥塞时的发送窗口大小的一半。然后把拥塞窗口设置为1，执行慢开始算法。

（3）快重传

快重传要求接收方在收到一个失序的报文段后就立即发出重复确认（为的是使发送方及早知道有报文段没有到达对方）而不要等到自己发送数据时捎带确认。快重传算法规定，发送方只要一连收到三个重复确认就应当立即重传对方尚未收到的报文段，而不必继续等待设置的重传计时器时间到期。

（4）快恢复

当发送方连续收到三个重复确认时，就把慢开始门限和拥塞窗口减半，然后执行拥塞避免算法。不执行慢开始算法的原因：因为如果网络出现拥塞的话就不会收到好几个重复的确认，所以发送方认为现在网络可能没有出现拥塞。