【TCP】滑动窗口、流量控制 以及拥塞控制

滑动窗口、流量控制 以及拥塞控制

  • [1. 滑动窗口(效率机制)](#1. 滑动窗口(效率机制))
  • [2. 流量控制(安全机制)](#2. 流量控制(安全机制))
  • [3. 拥塞控制(安全机制)](#3. 拥塞控制(安全机制))

1. 滑动窗口(效率机制)

TCP 使用 确认应答 策略,对每一个发送的数据段,都要给一个 ACK 确认应答。收到 ACK 后再发送下一个数据段。这样做有一个比较大的缺点,就是性能较差。尤其是数据往返的时间较长的时候。

既然这样一发一收的方式性能较低,那么我们一次发送多条数据,使用滑动窗口,就可以大大的提高性能(其实是将多个段的等待时间重叠在一起了)。
滑动窗口存在的意义就是在保证可靠性的前提下,尽量提高效率。

  • 窗口大小指的是无需等待确认应答而可以继续发送数据的最大值。上图的窗口大小就是 4000 个字节(四个段)。
  • 发送前四个段的时候,不需要等待任何 ACK,直接发送;
  • 收到第一个 ACK 后,滑动窗口向后移动,继续发送第五个段的数据;依次类推;
    (相当于一份等待时间等待多份 ACK, 当然不能不等,可靠传输的灵魂就是确认应答, 若没有 ACK,可靠传输就形同虚设。)
  • 操作系统内核为了维护这个滑动窗口,需要开辟 发送缓冲区 来记录当前还有哪些数据没有应答;只有确认应答过的数据,才能从缓冲区删掉;
  • 在一定范围内,窗口越大,传输速率就越快,网络的吞吐率就越高

那么如果出现了丢包,如何进行重传?这里分两种情况讨论。

  • 情况一:数据包已经抵达,ACK 被丢了。

这种情况下,部分 ACK 丢了并不要紧,因为可以通过后续的ACK进行确认.
ACK 的确认号有特定含义,保证后一条 ACK 覆盖前一条,

比如并没有收到 1001 ACK, 但是收到了 2001 ACK 就说明 2001 之前的数据全部已经收到了。

若发送 4001 ~ 5000 之前,只收到了 4001, 但是它的意思是,4001 之前的都收到了,窗口就可以一次往下挪动 4 个。

  • 情况二:数据包就直接丢了。
  • 当某一段报文段丢失之后,发送端会一直收到 1001 这样的 ACK,就像是在提醒发送端 "我想要的是 1001" 一样;
  • 如果发送端主机连续三次收到了同样一个 "1001" 这样的应答,就会将对应的数据 1001 - 2000 重新发送;
  • 这个时候接收端收到了 1001 之后,再次返回的 ACK 就是 7001 了(因为2001 - 7000)接收端其实之前就已经收到了,被放到了接收端操作系统内核的接收缓冲区中;
    (重传只需要把丢的数据重传就行了,后面已经传过的数据不用再传了。)

这种机制被称为 "高速重发控制"(也叫 "快重传")。

(为什么说是 "快" 重传,因为可能收到三个连续相同的 ACK 的时间内还没有触发超时机制,也就是还没超时呢,但是不等触发超时,直接就重传了。)

2. 流量控制(安全机制)

流量控制是滑动窗口的延伸,目的是为了保证可靠性。

  • 在一定范围内,滑动窗口越大传输效率就越高,但是不能只考虑发送方,不考虑接收方,
  • 接收端处理数据的速度是有限的。如果发送端发的太快,导致接收端的缓冲区被打满,这个时候如果发送端继续发送,就会造成丢包,继而引起丢包重传等等一系列连锁反应。

因此 TCP 支持根据接收端的处理能力,来决定发送端的发送速度。这个机制就叫做流量控制(Flow Control);

  • 接收端将自己可以接收的缓冲区大小放入 TCP 首部中的 "窗口大小" 字段,通过 ACK 端通知发送端;
  • 发送方接收到这个这个数据后,就会灵活的调整发送速度,调整窗口大小
  • 窗口大小字段越大,说明网络的吞吐量越高;
  • 接收端一旦发现自己的缓冲区快满了,就会将窗口大小设置成一个更小的值通知给发送端;
  • 发送端接受到这个窗口之后,就会减慢自己的发送速度;
  • 如果接收端缓冲区满了,就会将窗口置为 0;
  • 这时发送方不再发送数据,但是需要定期发送一个窗口探测数据段,使接收端把窗口大小告诉发送端。
  • 接收端如何把窗口大小告诉发送端呢?

    回忆我们的 TCP 首部中,有一个16 位窗口字段,就是存放了窗口大小信息;

  • 那么问题来了,16 位数字最大表示 65535,那么 TCP 窗口最大就是 65535 字节么?

    实际上,TCP 首部40字节选项中还包含了一个窗口扩大因子 M,实际窗口大小是 窗口字段的值左移 M 位即 65535 * 2 ^M

3. 拥塞控制(安全机制)

拥塞控制,也是滑动窗口的延伸,限制滑动窗口的发送速率。

拥塞控制描述的是发送方到接收方整个链路直接的拥堵情况。

  • 最终的滑动窗口的大小 = Min (流量控制窗口,拥塞控制窗口)

虽然TCP有了滑动窗口这个大杀器,能够高效可靠的发送大量的数据。

但是如果在刚开始阶段就发送大量的数据,仍然可能引发问题。

因为网络上有很多的计算机,可能当前的网络状态就已经比较拥堵。在不清楚当前网络状态下,贸然发送大量的数据,是很有可能引起雪上加霜的。

  • 发送方开始时以一个较小的窗口来发送数据,
  • 若数据很流畅到达,就逐渐加大窗口大小,
  • 若加大到一定程度出现丢包,就减小窗口,
  • 通过反复的增大/减小过程,逐渐找到一个合适的范围,拥塞窗口就在这个范围中不断变化,达到一个 "动态平衡"。

具体拥塞窗口是怎么变化的呢 ?

  1. 慢开始
    初始值 窗口大小为 1, 然后以指数级别增长,"慢开始" 只是指初使时慢,但是增长速度非常快。
  2. 拥塞避免
    窗口值到达 ssthresh 时,从指数增长变为 线性增长。
  3. 网络拥塞
    出现大量丢包情况,说明网络拥塞了,拥塞窗口大小直接变为 1 。ssthresh 阈值变为此时拥塞窗口大小的一半,图中就是从 变为 24 的一半 12 。
    (少量的丢包,我们仅仅是触发超时重传;大量的丢包,我们就认为网络拥塞;)
  4. 然后重新慢开始,循环这个过程。

当TCP通信开始后,网络吞吐量会逐渐上升;随着网络发生拥堵,吞吐量会立刻下降;

  • 为什么使用指数级别的增长速度 ?

    因为希望能快速接近 ssthresh 阈值, 既希望速度快,又希望不大量丢包,如果初始情况给的窗口大小很小,可能合适的值是个很大的值,那么使用指数增长的话,能够很快的接近这个值。

  • ssthresh 的意义 ?

    决定了什么时候从指数增长变为线性增长

  • 拥塞窗口最理想的大小 ?

    ssthresh 值与 出现拥塞的这个值之间是最理想的效果,这个范围之间传输速率较快,并且没有大量丢包。

  • 为什么出现拥塞时,直接让窗口变为初始值 1 ?

    因为网络的情况很复杂,不稳定,如果出现大量丢包,很可能速度降下来一点是不能解决问题的,速度降得太慢还会有可能出现持续丢包,就会对网络质量带来很大影响,一下让窗口变得很小,就是期望这次传输一定能成功。

拥塞控制,归根结底是TCP协议想尽可能快的把数据传输给对方,但是又要避免给网络造成太大压力的折中方案。

常见面试题:

  1. UDP 本身是无连接,不可靠,面向数据报的协议,如果要基于传输层UDP协议,来实现一个可靠传输,应该如何设计?
  2. UDP 大小是受限的,如果要基于传输层UDP协议,传输超过64K的数据,应该如何设计?

以上两个问题答案类似,都可以参考TCP的可靠性机制然后在应用层实现类似的逻辑:

如:

  • 引入序列号,保证数据顺序;
  • 引入确认应答,确保对端收到了数据,保证可靠传输;
  • 引入超时重传,如果隔一段时间没有应答,就重发数据;
  • 引入滑动窗口;
  • 引入窗口扩大选项;
  • 引入流量控制
  • 引入拥塞控制
  • ......

好啦! 以上就是对 TCP 滑动窗口、流量控制 以及拥塞控制的讲解,希望能帮到你 !
评论区欢迎指正 !

相关推荐
小兔子酱#2 小时前
【Linux 29】传输层协议 - UDP
linux·运维·服务器·网络·网络协议·udp
不爱学习的YY酱2 小时前
【计网不挂科】计算机网络期末考试——【选择题&填空题&判断题&简述题】试卷(2)
网络·计算机网络
想不到好名字了()2 小时前
负载均衡式在线oj项目开发文档2(个人项目)
linux·网络·c++
liuhaoodng6262 小时前
浮动路由:实现出口线路的负载均衡冗余备份。
运维·网络·网络协议·负载均衡
生活的高手☆2 小时前
网络安全之信息收集
网络·安全
小黑子不会打篮球2 小时前
记一次文件包含刷题(伪协议篇)
网络协议·学习·web安全
ac-er88883 小时前
PHP API的路由设计思路
开发语言·php
dot.Net安全矩阵3 小时前
.NET 黑名单上传 突破WAF防护的SoapShell (免杀版)
服务器·网络·学习·安全·web安全·.net
follycat3 小时前
[极客大挑战 2019]Upload 1
网络·网络协议·学习·http·网络安全
follycat4 小时前
[极客大挑战 2019]Secret File 1
网络·学习·网络安全