TCP 流量控制和拥塞控制

2021-04-30 11:25:29 浏览数 (1)

TCP 流量控制和拥塞控制

代码语言：javascript复制
MSS：MAX  Segement Size  TCP 一次传输的最大数据长度
RTT: Roud Trip Time 从发送端发送开始到收到接收端的 ACK 的确认，总共经历的时间延迟。
RTO: 拥塞控制从发出原始包到重传该包到时间叫做 RTO (Retransmission TimeOut)

为啥需要流量控制？

发送数据的方式有两种：

  1. 每次发送一个，然后等待确认，然后再发送下一个
  2. 每次发送 N 个，然后等待对方一起确认
  • 方式1的问题，主要是效率太低，一个 RTT 只能发送一个包
  • 方式2的问题， 不能确保接收者一次性接收到这么多数据，同时网络带宽不一定够，可能会有丢包的情况。

方式1 的问题就是流量控制问题TCP，采用了滑动窗口解决 方式2 的问题说的是拥塞控制问题。

现在说下为啥需要流量控制：

代码语言：javascript复制
TCP uses an end-to-end flow control protocol to avoid having the sender send data too fast for the TCP receiver to receive and process it reliably. Having a mechanism for flow control is essential in an environment where machines of diverse network speeds communicate.

简单的说，TCP 使用 端到端端流量控制协议来避免发送端数据发送数据太快，导致接收端不能可靠端接收和处理数据。在不同网络网络速度的机器通讯环境中，流量控制是完全有必要的。

滑动窗口如何流量控制？

通过wireshark抓包数据，可以看到滑动窗口

上面的 Win 标识就是接收端告诉发送端自己还有多少缓冲区可以接收数据。

滑动窗口

接收方每次收到数据包，可以在发送确定报文的时候，同时告诉发送方自己的缓存区还剩余多少是空闲的，我们也把缓存区的剩余大小称之为接收窗口大小，用变量win来表示接收窗口的大小。发送方收到之后，便会调整自己的发送速率，也就是调整自己发送窗口的大小，当发送方收到接收窗口的大小为0时，发送方就会停止发送数据，防止出现大量丢包情况的发生。

流量控制的死锁问题

如果这个窗口不为0的应答在传输过程丢失，发送者一直等待下去，而接收者以为发送者已经收到该应答，等待接收新数据，这样双方就相互等待，从而产生死锁。

如何解决死锁问题

TCP 采用的持续基数器的方式解决死锁问题， 当发送者接收到窗口0 的应答之后就启动该计时器，时间一到，便主动询问接收者窗口大小。如果接收者仍然返回0 ，那么就重置该计时器，如果不为0，表示报文丢失，那么重置窗口，然后开始发送，这样避免的死锁问题。

流量控制和拥塞控制有什么区别

  • 拥塞控制是作用于网络的，防止过多数据注入网络， 避免网络出现负载过大的情况。
  • 流量控制是作用于接收者的，是用来控制发送者速率，使得接收者来得及接收，防止分组丢失。

拥塞控制

拥塞控制的4个算法：慢启动，拥塞避免，快速重传和快速恢复

拥塞窗口

TCP发送方新增的窗口，congestion window，简称cwnd。对应上文，发送方取拥塞窗口和滑动窗口的最小值作为发送上限，即谁严格谁起决定因素。

慢启动算法
  1. 连接建立开始， 发送方不了解网络的情况， cwind 初始化比较小的值， RFC j建议 2-4 MSS
代码语言：javascript复制
If (MSS <= 1095 bytes)
      then win <= 4 * MSS;
If (1095 bytes < MSS < 2190 bytes)
      then win <= 4380;
If (2190 bytes <= MSS)
      then win <= 2 * MSS;
  1. 如果发送出去的包都被 ACK，说明没有达到拥塞，则增加拥塞窗口，每收到 N 个 ACK, 那么cwnd 增加 N 个 MSS， 呈指数增长。这个过程叫做慢启动。
拥塞避免

慢启动维护了 cwnd,还会维护拥塞窗口临界值 ssthresh， 一般是 2^16-1, 一旦达到 ssthresh ，进入拥塞避免。

拥塞避免环节，有点类似 redis,string里面点扩容环节，无论一个RTT收到多少个 ACK , 每次确认只增加一个 MSS, 呈线性关系增长。

快速重传和快速恢复

快速重传

进入拥塞避免之后， 最终还是会碰到拥塞点， 如果发送方此时得不到确认，发送方决定等待一端时间，如果一端时间后，还是得不到确认，那么就发起重传，这个过程叫做超时重传，这个从原始包发送到发起重传点这段时间，叫做 RTO(Retransmission TimeOut)

快速恢复

在这里插入图片描述

  • 在收到3个重复的ACK之后，ssthresh设置为cwnd的一半，然后把cwnd设置为ssthresh加3个单位的大小，接着重传丢失的报文段。
  • 如果这个时候再次收到重传的ACK，那么拥塞窗口增加1。
  • 如果收到的是新的数据包的ACK，把cwnd设置为第一步的ssthresh的值。为什么这么做，因为如果收到的新的ACK，说明网络已经恢复了，可以进入拥塞避免的线性增长阶段了。
  • 第一个例子里为什么加3呢，因为这个时候连续的收到3个ACK包，那么可以认为网络还有3个单位大小的余额，同时也可以这么想，说明有3个“老”的数据包已经从网络上离开了。

参考资料

  • https://zhuanlan.zhihu.com/p/37379780
  • https://www.cnblogs.com/iou123lg/p/9017044.html

redis string timeout wireshark 流量

0 人点赞