TCP 流量控制和拥塞控制

简介: TCP 流量控制和拥塞控制

TCP 流量控制和拥塞控制


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

为啥需要流量控制?


发送数据的方式有两种:

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

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

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

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抓包数据,可以看到滑动窗口

image.png

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

滑动窗口


image.png

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

流量控制的死锁问题


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

如何解决死锁问题


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

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


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


拥塞控制


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


拥塞窗口


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


慢启动算法


  1. 连接建立开始, 发送方不了解网络的情况, cwind 初始化比较小的值, RFC j建议 2-4 MSS
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, 呈线性关系增长。


image.png

快速重传和快速恢复


快速重传

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


快速恢复

image.png


  • 在收到3个重复的ACK之后,ssthresh设置为cwnd的一半,然后把cwnd设置为ssthresh加3个单位的大小,接着重传丢失的报文段。
  • 如果这个时候再次收到重传的ACK,那么拥塞窗口增加1。
  • 如果收到的是新的数据包的ACK,把cwnd设置为第一步的ssthresh的值。为什么这么做,因为如果收到的新的ACK,说明网络已经恢复了,可以进入拥塞避免的线性增长阶段了。
  • 第一个例子里为什么加3呢,因为这个时候连续的收到3个ACK包,那么可以认为网络还有3个单位大小的余额,同时也可以这么想,说明有3个“老”的数据包已经从网络上离开了。
相关实践学习
容器服务Serverless版ACK Serverless 快速入门:在线魔方应用部署和监控
通过本实验,您将了解到容器服务Serverless版ACK Serverless 的基本产品能力,即可以实现快速部署一个在线魔方应用,并借助阿里云容器服务成熟的产品生态,实现在线应用的企业级监控,提升应用稳定性。
云原生实践公开课
课程大纲 开篇:如何学习并实践云原生技术 基础篇: 5 步上手 Kubernetes 进阶篇:生产环境下的 K8s 实践 相关的阿里云产品:容器服务&nbsp;ACK 容器服务&nbsp;Kubernetes&nbsp;版(简称&nbsp;ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情:&nbsp;https://www.aliyun.com/product/kubernetes
相关文章
|
缓存 网络协议 算法
四十一、TCP可靠传输、流量控制、拥塞控制
四十一、TCP可靠传输、流量控制、拥塞控制
四十一、TCP可靠传输、流量控制、拥塞控制
|
缓存 网络协议 算法
计算机网络学习26:TCP/UDP对比区别、TCP流量控制、拥塞控制、超时重传时间的选择、可靠传输的实现
UDP: User Datagram Protocol 用户数据报协议 TCP: Transmission Control Protocol 传输控制协议 同时这里指的连接是指逻辑连接,而不是物理连接。
计算机网络学习26:TCP/UDP对比区别、TCP流量控制、拥塞控制、超时重传时间的选择、可靠传输的实现
|
网络协议 算法 5G
TCP 拥塞控制详解 | 7. 超越 TCP(下)
TCP 拥塞控制详解 | 7. 超越 TCP(下)
472 1
TCP 拥塞控制详解 | 7. 超越 TCP(下)
|
缓存 网络协议 算法
TCP 拥塞控制详解 | 7. 超越 TCP(上)
TCP 拥塞控制详解 | 7. 超越 TCP(上)
257 0
TCP 拥塞控制详解 | 7. 超越 TCP(上)
|
监控 网络协议 算法
TCP 拥塞控制详解 | 6. 主动队列管理
TCP 拥塞控制详解 | 6. 主动队列管理
408 1
TCP 拥塞控制详解 | 6. 主动队列管理
|
网络协议 算法 测试技术
TCP 拥塞控制详解 | 5. 回避算法
TCP 拥塞控制详解 | 5. 回避算法
201 1
TCP 拥塞控制详解 | 5. 回避算法
|
存储 网络协议 算法
TCP 拥塞控制详解 | 4. 控制算法(下)
TCP 拥塞控制详解 | 4. 控制算法(下)
194 0
TCP 拥塞控制详解 | 4. 控制算法(下)
|
存储 网络协议 算法
TCP 拥塞控制详解 | 4. 控制算法(上)
TCP 拥塞控制详解 | 4. 控制算法(上)
201 0
TCP 拥塞控制详解 | 4. 控制算法(上)
|
运维 算法 网络协议
TCP 拥塞控制详解 | 3. 设计空间(下)
TCP 拥塞控制详解 | 3. 设计空间(下)
186 0
TCP 拥塞控制详解 | 3. 设计空间(下)
|
17天前
|
机器学习/深度学习 人工智能 网络协议
TCP/IP五层(或四层)模型,IP和TCP到底在哪层?
TCP/IP五层(或四层)模型,IP和TCP到底在哪层?
28 4