【计算机网络】TCP/IP——流量控制与拥塞控制

news2024/11/15 7:15:42

学习日期：2024.7.22

内容摘要：TCP的流量控制与拥塞控制

流量控制

一般来说，我们总是希望数据传输的快一些，但是如果数据传输的太快，接收方可能就来不及接收，这就会导致数据的丢失，流量控制正是为了避免这一现象。

所谓流量控制，其实就是让发送方的发送速率不要太快，让接收方来得及接收，所以一定是接收方给发送方流量控制。用滑动窗口机制可以很方便的在TCP上实现对发送方的流量控制。

下面我们举一个例子，在这个例子中，为了方便讨论，我们不考虑拥塞控制，而是认为接收窗口与发送窗口大小相等。

如图，一开始流量窗口是400，A向B发送数据，B给A流量控制。图中第三部分，201~300的字节数据丢失了，B就在确认时，ack=201，意思是201号字节之前的数据都收到了，而rwnd=300的意思是，调整接收窗口为300。

于是，发送窗口被调节为201之后的300个字节，如上图蓝色阴影所示。然后A会从301开始发送（接着上次的）然后发完401~500之后，窗口内的数据已经全部发完，不能再发送新数据了。待重传计时器超时后，A就会开始超时重传旧数据

如图，当主机A超时重传201~300的数据后，主机b就能对收到的501以前的数据进行累计确认，再把接收窗口调整成为100。主机A的发送窗口会调整为501~600，发完这部分数据后，主机A就不能再发送数据了。此时主机B对601号以前的数据进行了累计确认，ACK=1的意思是确认收到，ack=601的意思是601以前的数据，rwnd=0是接收窗口调整为了0。

因为此时接收窗口是0，所以就不能发送一般的TCP报文了，直到B通知A，接收窗口不为0。

但是这样可能导致一个问题，如果主机B的接收窗口扩大了，它想通知主机A，但这个通告在传输过程中丢失了，这会怎么样呢？

主机A会一直等待主机B告诉它传输窗口已经打开了，而主机B会一直等待主机A发送消息，双方会无限等待下去，这样就会导致死锁。A以为B在忙一直等，B以为自己告诉A了，双方又不交流，就死锁了。

为了解决这个问题，TCP规定，如果收到0窗口通知，发送方就要启动一个持续计时器，每隔一段时间发送一个0窗口探测报文，仅携带1字节数据。就好比A隔一段时间问一下B，“在吗？”，如果B的接收窗口还没调大，就回ACK=1表示收到（确认通信能完成），rwnd=0表示接收窗口为0，就是还在忙。如果可以了，就是rwnd=xxx，这样就能够避免死锁了。

拥塞控制

在某段时间中，若对网络中某一资源的需求超过了该资源所能提供的可用部分，网络性能就要变坏，这种情况就叫做拥塞。类比生活中就是堵车，大家都想去一个地方（访问一个处理机），但是路就那么宽，那么就塞车了。

在计算机网络中的链路容量、交换节点中的缓存和处理机等，都叫做“网络的资源”。

若出现拥塞而不进行控制，整个网络的吞吐量将随着输入负荷的增大而下降。

如图，理想的拥塞控制是绿线，在达到阈值前，输入负载始终等于吞吐量，达到之后，吞吐量始终保持最高。这好比公路在达到承载能力上限之前，始终能满负荷运转，而达到之后，即使再多的车来，也能保持以最大限度运转，但塞过车的都知道这是不可能的。

如果无拥塞控制，就是红线，随着车越来越多，大家全部都动不了，最后所有车都堵在路上，吞吐量为0。而实际的拥塞控制，就是要尽量接近理想的拥塞控制。

TCP的拥塞控制主要有慢开始，拥塞避免，快重传，快恢复。

为了方便讨论，我们假定：

①数据是单方向传送的，另一个方向只传送确认

②接收方的缓存空间足够大，因而发送方发送窗口的大小以网络的拥塞程度决定，不考虑接收窗口

③以最大报文段MSS的个数为讨论问题的单位，而非字节

慢开始和拥塞避免

传输轮次：发送方给接收方发送后，到接收方给发送方发回对应的确认报文段的时间，其实就是往返时间RTT，这个时间并不是恒定的，会根据具体的网络情况波动。

慢开始算法的过程很简单，一开始拥塞窗口cwnd为1，发送窗口等于拥塞窗口，之后每轮次2，4，8，16这样指数级增大，直到拥塞窗口大于慢开始门限。然后采用拥塞避免算法，其实就是改为每轮次都线性+1，直到发生超时重传（认为此时网络已经开始拥塞），就把慢开始门限值调节为拥塞时的一半，然后从头再来一遍慢开始—>拥塞避免。