TCP 流量控制和拥塞控制

本文涉及的产品
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
简介: 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个“老”的数据包已经从网络上离开了。
相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
网络协议 算法 5G
TCP 拥塞控制详解 | 7. 超越 TCP(下)
TCP 拥塞控制详解 | 7. 超越 TCP(下)
598 1
TCP 拥塞控制详解 | 7. 超越 TCP(下)
|
监控 网络协议 算法
TCP 拥塞控制详解 | 6. 主动队列管理
TCP 拥塞控制详解 | 6. 主动队列管理
512 1
TCP 拥塞控制详解 | 6. 主动队列管理
|
网络协议 算法 测试技术
TCP 拥塞控制详解 | 5. 回避算法
TCP 拥塞控制详解 | 5. 回避算法
286 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(上)
383 0
TCP 拥塞控制详解 | 7. 超越 TCP(上)
|
存储 网络协议 算法
TCP 拥塞控制详解 | 4. 控制算法(下)
TCP 拥塞控制详解 | 4. 控制算法(下)
262 0
TCP 拥塞控制详解 | 4. 控制算法(下)
|
存储 网络协议 算法
TCP 拥塞控制详解 | 4. 控制算法(上)
TCP 拥塞控制详解 | 4. 控制算法(上)
277 0
TCP 拥塞控制详解 | 4. 控制算法(上)
|
运维 算法 网络协议
TCP 拥塞控制详解 | 3. 设计空间(下)
TCP 拥塞控制详解 | 3. 设计空间(下)
229 0
TCP 拥塞控制详解 | 3. 设计空间(下)
|
6月前
|
机器学习/深度学习 人工智能 网络协议
TCP/IP五层(或四层)模型,IP和TCP到底在哪层?
TCP/IP五层(或四层)模型,IP和TCP到底在哪层?
110 4