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个“老”的数据包已经从网络上离开了。
相关实践学习
深入解析Docker容器化技术
Docker是一个开源的应用容器引擎,让开发者可以打包他们的应用以及依赖包到一个可移植的容器中,然后发布到任何流行的Linux机器上,也可以实现虚拟化,容器是完全使用沙箱机制,相互之间不会有任何接口。Docker是世界领先的软件容器平台。开发人员利用Docker可以消除协作编码时“在我的机器上可正常工作”的问题。运维人员利用Docker可以在隔离容器中并行运行和管理应用,获得更好的计算密度。企业利用Docker可以构建敏捷的软件交付管道,以更快的速度、更高的安全性和可靠的信誉为Linux和Windows Server应用发布新功能。 在本套课程中,我们将全面的讲解Docker技术栈,从环境安装到容器、镜像操作以及生产环境如何部署开发的微服务应用。本课程由黑马程序员提供。 &nbsp; &nbsp; 相关的阿里云产品:容器服务 ACK 容器服务 Kubernetes 版(简称 ACK)提供高性能可伸缩的容器应用管理能力,支持企业级容器化应用的全生命周期管理。整合阿里云虚拟化、存储、网络和安全能力,打造云端最佳容器化应用运行环境。 了解产品详情: https://www.aliyun.com/product/kubernetes
相关文章
|
网络协议 算法 5G
TCP 拥塞控制详解 | 7. 超越 TCP(下)
TCP 拥塞控制详解 | 7. 超越 TCP(下)
846 1
TCP 拥塞控制详解 | 7. 超越 TCP(下)
|
监控 网络协议 算法
TCP 拥塞控制详解 | 6. 主动队列管理
TCP 拥塞控制详解 | 6. 主动队列管理
743 1
TCP 拥塞控制详解 | 6. 主动队列管理
|
网络协议 算法 测试技术
TCP 拥塞控制详解 | 5. 回避算法
TCP 拥塞控制详解 | 5. 回避算法
497 1
TCP 拥塞控制详解 | 5. 回避算法
|
缓存 网络协议 算法
四十一、TCP可靠传输、流量控制、拥塞控制
四十一、TCP可靠传输、流量控制、拥塞控制
四十一、TCP可靠传输、流量控制、拥塞控制
|
缓存 网络协议 算法
计算机网络学习26:TCP/UDP对比区别、TCP流量控制、拥塞控制、超时重传时间的选择、可靠传输的实现
UDP: User Datagram Protocol 用户数据报协议 TCP: Transmission Control Protocol 传输控制协议 同时这里指的连接是指逻辑连接,而不是物理连接。
计算机网络学习26:TCP/UDP对比区别、TCP流量控制、拥塞控制、超时重传时间的选择、可靠传输的实现
|
缓存 网络协议 算法
TCP 拥塞控制详解 | 7. 超越 TCP(上)
TCP 拥塞控制详解 | 7. 超越 TCP(上)
617 0
TCP 拥塞控制详解 | 7. 超越 TCP(上)
|
存储 网络协议 算法
TCP 拥塞控制详解 | 4. 控制算法(下)
TCP 拥塞控制详解 | 4. 控制算法(下)
445 0
TCP 拥塞控制详解 | 4. 控制算法(下)
|
存储 网络协议 算法
TCP 拥塞控制详解 | 4. 控制算法(上)
TCP 拥塞控制详解 | 4. 控制算法(上)
508 0
TCP 拥塞控制详解 | 4. 控制算法(上)
|
运维 算法 网络协议
TCP 拥塞控制详解 | 3. 设计空间(下)
TCP 拥塞控制详解 | 3. 设计空间(下)
345 0
TCP 拥塞控制详解 | 3. 设计空间(下)
|
机器学习/深度学习 人工智能 网络协议
TCP/IP五层(或四层)模型,IP和TCP到底在哪层?
TCP/IP五层(或四层)模型,IP和TCP到底在哪层?
374 4

热门文章

最新文章

下一篇
oss云网关配置