计算机网络:运输层 - TCP 流量控制 拥塞控制

2024-06-19 20:44

本文主要是介绍计算机网络:运输层 - TCP 流量控制 拥塞控制,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

计算机网络:运输层 - TCP 流量控制 & 拥塞控制

    • 滑动窗口
    • 流量控制
    • 拥塞控制
      • 慢开始算法
      • 拥塞避免算法
      • 快重传算法
      • 快恢复算法


滑动窗口

如图所示:

在这里插入图片描述

TCP首部中有一个窗口字段,该字段就基于滑动窗口来辅助流量控制拥塞控制。所以我们先讲解滑动窗口。

首先,发送方会维护一个发送缓存

在这里插入图片描述

应用程序会把想要发送的数据写入到发送缓存中,而在发送缓存内部,维护一个发送窗口

发送窗口将发送缓存分为四个部分:

在这里插入图片描述

当发送方发送数据后,就要等待对方确认,粉色区域就是发送了但是没有收到确认的区域。当粉色区域的字节收到确认后,就会离开滑动窗口,进入绿色区域。

蓝色区域的字节,是可以发送的但是还没有发送,一旦发送了就进入粉色区域,等待确认。黄色区域处于发送缓存但不处于发送窗口,此时是待发送的数据,但是还不能发送。

接收方也会维护一个接收缓存

在这里插入图片描述

接收缓存也被接收窗口划分为了三个部分:

在这里插入图片描述

接收窗口内部的数据,是允许接收的,当接收到一个数据接收到后,接收方对其发出确认,随后该数据变成绿色部分,即已经确认接收的部分。黄色部分则是不允许接收的部分,就算收到这个区域的数据,也会被丢弃。

滑动窗口的运行模式如下:

一开始A发送了313233这三个报文,但是31丢失了:

在这里插入图片描述

由于3233在接收窗口内,可以正常接收,但是由于31没有收到,此时接收窗口不能往后移动。

随后B发送确认报文,确认号为31,表示当前收到的最后一个连续报文是31,虽然3334也收到了,但是不连续

在这里插入图片描述

由于一直没收到31的确认报文,A超时重传31

在这里插入图片描述

随后B就收到了这三个连续的报文,于是接收窗口向后滑动:

在这里插入图片描述

B又发送确认号为34的报文,表示33之前的所有报文都收到了,此时A的发送窗口也向后移动:

在这里插入图片描述


流量控制

流量控制就是让发送方的发送速率不要太快,要让接收方来得及接收。其本质是通过控制滑动窗口的大小来实现的。

每个TCP数据报发送时,都会在窗口字段填入自己的接收窗口值,从而告诉对方最多传送多少数据。

如下,一开始B的接收窗口为400

在这里插入图片描述

随后A连续发送了三个报文,分别是[1, 100][101, 200][201, 300]。而第三个报文丢失了。

随后B发送了一个确认报文,此时rwnd就是窗口字段的值,表明当前自己的接收窗口是多少Brwnd控制为300并告知A

在这里插入图片描述

随后A发送了[301, 400][401, 500]并重传了[201, 300]

在这里插入图片描述

此时A计算出到已经发送到对方接收窗口的最大值了,不会再发送数据了。

直到BA发送新的报文,将rwnd = 100,表示可以再发送100个数据:

在这里插入图片描述

最后B又发送一个rwnd = 0的报文,表示接下来A不要发送任何数据了:

在这里插入图片描述

通过这样一个控制接收窗口的过程,你会发现A想要发多少数据,都由B来控制了,这就是流量控制


拥塞控制

在某段时间内,若对网络中某资源(带宽、缓存、处理机等)的需求超过了该资源所能提供的可用部分,网络的性能就要变坏,这种情况称为拥塞 (congestion)。

拥塞控制就是防止过多的数据注入到网络中,以防网络中的路由器或链路过载。它是一个全局性的过程,涉及到所有的主机和路由器。

为了进行拥塞控制,发送方维持一个叫做拥塞窗口 cwnd的状态变量。发送窗口的值是拥塞窗口接收窗口的较小值。本博客为了方便理解,假设接收窗口的值一直大于拥塞窗口,也就是说发送窗口的值一直和拥塞窗口保持一致。

发送方控制拥塞窗口的原则是:

  • 只要网络没有出现拥塞,拥塞窗口就可以再增大一些,以便把更多的分组发送出去,提高网络的利用率。
  • 但只要网络出现拥塞(依据就是出现了超时),拥塞窗口就减小一些,以减少注入到网络中的分组数,缓解网络出现的拥塞。

TCP进行依赖四种算法:满开始拥塞避免快重传快恢复

慢开始算法

慢开始算法的思路是:

当主机在刚建立的 TCP 连接上发送数据时,并不清楚网络当前的状况,不宜把大量的数据注入网络,而是应当由小到大逐渐增大注入到网络中的数据量,即由小到大逐渐增大拥塞窗口的数值。

慢开始算法的规则是:

每收到一个确认报文,就把cwnd的值增大1

如图所示:

在这里插入图片描述

首先明确轮次的概念:发送方把拥塞窗口所允许发送的报文段都连续发送出去,并收到对这些报文段的确认所经历的时间,就叫一个轮次。

第一轮次cwnd = 1,只能发送一个数据,接收方收到这个数据后回应一个确认报文。发送方接收到一个回应报文,cwnd = cwnd + 1

第二轮次发送窗口cwnd就变成了2,此时发送方就可以一次发送两个数据报,接收方就回应两个确认报文。发送方接收到两个回应报文,cwnd = cwnd +2

第三轮次发送窗口cwnd就变成了4,此时发送方就可以一次发送四个数据报,接收方就回应四个确认报文。发送方接收到四个回应报文,cwnd = cwnd +4

于是发送窗口cwnd变为8,以此类推。

你会发现:处于慢开始阶段,cwnd呈指数级增长。为了控制拥塞窗口增加过快,此时会设置一个慢开始门限 sstresh

  • cwnd < ssthresh 时,使用慢开始算法。
  • cwnd > ssthresh 时,停止使用慢开始算法而改用拥塞避免算法。
  • cwnd = ssthresh 时,既可使用慢开始算法,也可使用拥塞避免算法。

接下来我们就讲解拥塞避免算法。


拥塞避免算法

拥塞避免算法的思路是让拥塞窗口 cwnd 缓慢地增大,规则如下:

每经过一个轮次,把拥塞窗口 cwnd 值加 1

拥塞避免并非完全避免拥塞,而是让拥塞窗口增长得缓慢些,使网络不容易出现拥塞。

如图所示:

在这里插入图片描述

横坐标为轮次,纵坐标为cwnd值。当cwnd < sstresh时,执行慢开始算法,此时cwnd指数级增长。当cwnd = 16 = sstresh时,改用拥塞避免算法,每个轮次cwnd = cwnd + 1,此时呈现线性增长

无论在慢开始阶段还是在拥塞避免阶段,只要发送方判断网络出现拥塞,此时就会重新调整cwnd,和sstresh规则如下:

ssthresh 设置为出现拥塞时的拥塞窗口值的一半。然后把拥塞窗口 cwnd 重新设置为 1,并执行慢开始算法。

这样做的目的就是要迅速减少主机发送到网络中的分组数,使得发生拥塞的路由器有足够时间处理队列中积压的分组。

如图:

在这里插入图片描述

等到第13个轮次,此时某个报文超时重传了,于是主机认为此时网络拥塞了,于是sshtresh = cnwd / 2 = 12cwnd = 1,并重新执行慢开始算法。

随后当慢开始执行到cwnd = 12时,cwnd = sstresh,由执行拥塞避免了。


慢开始拥塞避免1988年提出的TCP拥塞控制算法,在1990年由增加了两个算法:快重传快恢复算法。

快重传算法

为了避免单个报文段的意外丢失被发送方误认为网络产生了拥塞,同时为了让发送方尽早知道有个别报文段没有按序到达接收方,需要应用快重传算法。

快重传算法首先要求接收方每收到一个失序的报文段就立即发出对已收到的报文段的重复确认。当发送方连续收到三个重复的确认时,就执行快重传,这样就不会出现超时,发送方也就不会误认为网络出现了拥塞。

如图:

在这里插入图片描述

发送方发送M3丢失了,如果按照以前的算法,此时M3超时重传就会把cwnd = 1,就要从头开始增长了,导致传输效率降低。

于是当接收方收到M4M5M6时,都发送M3的确认报文,此时发送方连续收到三个M2确认报文,立刻重传M3,这个重传不算超时重传,不会触发网络拥塞的判断条件,后续就可以正常传输了。


快恢复算法

发送方在收到三个连续确认报文,执行快重传丢失的报文段的同时,执行快恢复算法:

令拥塞窗口 cwnd 减半,并设置慢开始门限 ssthresh 为同样的数值,然后开始执行拥塞避免算法,使拥塞窗口缓慢地线性增大

如图:

在这里插入图片描述

这是在,没有快恢复快重传的时候,遇到报文丢失后超时重传触发的机制。

而现在如果报文丢失,执行快恢复快重传,那么整体恢复速度就很快了:

在这里插入图片描述

执行快重传的时候,sstresh = cwnd = cwnd / 2 = 12,然后立刻执行拥塞避免,此时就可以在很短的时间内恢复到之前的状态了。


这篇关于计算机网络:运输层 - TCP 流量控制 拥塞控制的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1076101

相关文章

Python实现局域网远程控制电脑

《Python实现局域网远程控制电脑》这篇文章主要为大家详细介绍了如何利用Python编写一个工具,可以实现远程控制局域网电脑关机,重启,注销等功能,感兴趣的小伙伴可以参考一下... 目录1.简介2. 运行效果3. 1.0版本相关源码服务端server.py客户端client.py4. 2.0版本相关源码1

QT实现TCP客户端自动连接

《QT实现TCP客户端自动连接》这篇文章主要为大家详细介绍了QT中一个TCP客户端自动连接的测试模型,文中的示例代码讲解详细,感兴趣的小伙伴可以跟随小编一起学习一下... 目录版本 1:没有取消按钮 测试效果测试代码版本 2:有取消按钮测试效果测试代码版本 1:没有取消按钮 测试效果缺陷:无法手动停

Spring Security 基于表达式的权限控制

前言 spring security 3.0已经可以使用spring el表达式来控制授权,允许在表达式中使用复杂的布尔逻辑来控制访问的权限。 常见的表达式 Spring Security可用表达式对象的基类是SecurityExpressionRoot。 表达式描述hasRole([role])用户拥有制定的角色时返回true (Spring security默认会带有ROLE_前缀),去

poj 2135 有流量限制的最小费用最大流

题意: 农场里有n块地,其中约翰的家在1号地,二n号地有个很大的仓库。 农场有M条道路(双向),道路i连接着ai号地和bi号地,长度为ci。 约翰希望按照从家里出发,经过若干块地后到达仓库,然后再返回家中的顺序带朋友参观。 如果要求往返不能经过同一条路两次,求参观路线总长度的最小值。 解析: 如果只考虑去或者回的情况,问题只不过是无向图中两点之间的最短路问题。 但是现在要去要回

poj 3422 有流量限制的最小费用流 反用求最大 + 拆点

题意: 给一个n*n(50 * 50) 的数字迷宫,从左上点开始走,走到右下点。 每次只能往右移一格,或者往下移一格。 每个格子,第一次到达时可以获得格子对应的数字作为奖励,再次到达则没有奖励。 问走k次这个迷宫,最大能获得多少奖励。 解析: 拆点,拿样例来说明: 3 2 1 2 3 0 2 1 1 4 2 3*3的数字迷宫,走两次最大能获得多少奖励。 将每个点拆成两个

poj 2195 bfs+有流量限制的最小费用流

题意: 给一张n * m(100 * 100)的图,图中” . " 代表空地, “ M ” 代表人, “ H ” 代表家。 现在,要你安排每个人从他所在的地方移动到家里,每移动一格的消耗是1,求最小的消耗。 人可以移动到家的那一格但是不进去。 解析: 先用bfs搞出每个M与每个H的距离。 然后就是网络流的建图过程了,先抽象出源点s和汇点t。 令源点与每个人相连,容量为1,费用为

poj 3068 有流量限制的最小费用网络流

题意: m条有向边连接了n个仓库,每条边都有一定费用。 将两种危险品从0运到n-1,除了起点和终点外,危险品不能放在一起,也不能走相同的路径。 求最小的费用是多少。 解析: 抽象出一个源点s一个汇点t,源点与0相连,费用为0,容量为2。 汇点与n - 1相连,费用为0,容量为2。 每条边之间也相连,费用为每条边的费用,容量为1。 建图完毕之后,求一条流量为2的最小费用流就行了

【Go】go连接clickhouse使用TCP协议

离开你是傻是对是错 是看破是软弱 这结果是爱是恨或者是什么 如果是种解脱 怎么会还有眷恋在我心窝 那么爱你为什么                      🎵 黄品源/莫文蔚《那么爱你为什么》 package mainimport ("context""fmt""log""time""github.com/ClickHouse/clickhouse-go/v2")func main(

Sentinel 高可用流量管理框架

Sentinel 是面向分布式服务架构的高可用流量防护组件,主要以流量为切入点,从限流、流量整形、熔断降级、系统负载保护、热点防护等多个维度来帮助开发者保障微服务的稳定性。 Sentinel 具有以下特性: 丰富的应用场景:Sentinel 承接了阿里巴巴近 10 年的双十一大促流量的核心场景,例如秒杀(即突发流量控制在系统容量可以承受的范围)、消息削峰填谷、集群流量控制、实时熔断下游不可用应

控制反转 的种类

之前对控制反转的定义和解释都不是很清晰。最近翻书发现在《Pro Spring 5》(免费电子版在文章最后)有一段非常不错的解释。记录一下,有道翻译贴出来方便查看。如有请直接跳过中文,看后面的原文。 控制反转的类型 控制反转的类型您可能想知道为什么有两种类型的IoC,以及为什么这些类型被进一步划分为不同的实现。这个问题似乎没有明确的答案;当然,不同的类型提供了一定程度的灵活性,但