计算机网络 | 运输层知识点汇总-2

本文涉及的产品
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
简介: 计算机网络 | 运输层知识点汇总

七、TCP的流量控制

利用滑动窗口实现流量控制【⭐⭐⭐】

对于滑动窗口,在上面也提到过了,在流量控制这一块,就要利用到这个滑动窗口的机制去实现两个主机之间的通信

[流量控制的目的]:让发送方的发送速率不要太快,要让接收方来得及接收

==然后来说一下很重要的例子,要注意理解,与后面的三次握手紧密度非常之大==

  • 首先在建立连接的时候B就告诉了A:“我的接收窗口rwnd = 400”。表示主机B的接受窗口最多可以接收400B的大小,然后设置了一个100字节长的报文段,即DATA  = 100,数据报文段序号的初始值设置为1,即seq = 1
  • 然后一开始主机A就向B发送了100B的大小,第一个字节序号为1

image.png

  • 然后再发100B,第一个字节序号为为101

image.png

  • 但是在接下来的数据接收中,A主机继续向B主机发送了从[201]开始的数据,但在途中丢失了。此时主机B发现主机A没有再发送数据过来了,因此向它发送过去一个确认报文段
  • 【ACK】是一个确认字段,我们在TCP的首部格式中有说到过,只有当ACK = 1 时ack才有效
  • 【ack】是表示当前主机希望收到的下一个数据的首字节号,即确认字段的值
  • 【rwnd】表示接收窗口,接收方主机B将此窗口设置为300,表示它只能接收300大小的数据字节,而且是从201开始到500的这段范围,也就限定了主机A的发送窗口从400->300

  • 因为前200个字节的数据主机B已经完全接收了,所以主机A将其发送窗口向前滑动200字节⛸,将首字节号设置为201B,窗口大小设置为300B。
  • 但是因为主机A没有接收到主机B从201~300字节的数据的回应,便开始启动这一块的超时计时器

image.png

  • 接下去主机A就向主机B分别发送了301B - 400B以及401B - 500B的数据,此时接收窗口就满了。

image.png

  • 但此时主机A发现前面201~300B的超时计时器时间到了,但是主机B还是没有发来相关的响应,于是重新发送了一次从201开始的这100个数据报文段,这也就是我们在上面讲到过的【超时重传】

  • 然后接下去主机B就发送了一条确认说“==前面的500B我已经全部收到,现在我的接受窗口大小变为100,下一次希望收到501B为初始字节的数据==”那此时主机A就可以确认主机B已经全部收到了500B之前的所有数据,于是便会将自己的发送窗口后移300个B,到501B的位置

image.png

  • 接下去主机A又发送过来符合的100B数据,于是主机B的接受窗口就满了。此时主机B就发送回一个确认报文说“==前面的600B我已经全部收到,现在把你的发送窗口变为0,不要再发送数据了==”

从上面就可以看出主机B实现了三次流量控制,第一次将主机A的发送窗口大小从400->300,第二次从300->100,第三次就是从100->0,通过【rwnd】这个接收窗口的控制,就使得主机A的发送窗口呈现出一个动态变化的趋势,也就是我们前面在讲到窗口值是在动态变化的

  • 但是主机A要何时才能继续向主机B发送数据呢❓也就是当主机B重新发出一个新的窗口值为止。B主机会在它的接收缓存中腾出一些地方,把缓存当中的数据[主机A发送过来的600B]上交给了应用层后,它的接收缓存中就又可以有一些存储空间了
  • 于是这个时候主机B就又会向主机A发送一个rwnd = 400的报文段,告诉它你==现在可以将自己的发送窗口设置为400,并且开始发送数据了==。但是这个报文段呢若是在传输的过程中丢失了(〃>目<),主机A就收不到,此时主机B一直在等待主机A发送新的数据过来,主机A呢也等待主机B发送一个报文段过来告诉自己可以发数据了,于是它们就开始了一段漫长的等待.<{=....
  • 以上这个局面叫做【死锁】,是双方在数据传输过程中很可能会出现的一个现象

image.png

那要怎么去解决这个局面呢?

  • TCP为每一个连接都设有一个【持续计时器】,当连接的一方收到对方的零窗口通知后,就会启动这个计时器。也就是当前的主机A,接下去呢它会发送一个【探测报文段】,这个报文段中会有1B的数据,发送过去之后若是接收方给出的窗口值依旧是0,那么主机A就会重新设置持续计时器。
  • 在这个时候呢主机B可能已经收到了应用层的通告,可以继续接收数据了;如果不是零,那么死锁的僵局就可以打破了。

  • 从上述流量控制就可以看出TCP真的是非常的严谨,很好得控制了每一次数据的传输o((>ω< ))o

八、TCP的拥塞控制

1、拥塞控制的一般原理

首先来看看什么叫做【拥塞】

【拥塞】:在某段时间内,若对网络中某一资源的需求超过了该资源所能提供的可用部分,网络的性能就要变坏 👉∑对资源的需求 > 可用资源

① 解决网络拥塞的误区

很多人就认为解决网络拥塞的问题只需要增加一些资源即可

  1. 把节点缓存的存储空间扩大❌
  2. 把链路更换为更高速率的链路 ❌
  3. 把节点处理机的运算速度提高 ❌
  • 其实对于上面的这几种做法,都是不可行的,网络拥塞并没有想象中的那么简单,可能你单纯地解决了某个表现的问题,但是会引发出一些其他层次的问题。
  • 例如说丢弃一些路由器分组时,这一分组的源点就会重传这一分组,但是这又会间接导致更多的分组流入网络和被网络中的路由器丢弃
  • 那其实我们可以看到,若只是采用一些简单的做法,在许多情况下,非但不能解决网络的拥塞问题,而且还可能使网络的性能更坏,所以我们要采取更加有效的方法

② 拥塞控制与流量控制的关系【重点理解✔】

在上一模块,我们讲到了流量控制,现在又说到了拥塞控制,那你可能会想它们之间会不会存在着什么关系呢?一起来看看🐎

image.png

  • 对于【拥塞控制】而言, 其实就是要防止过多的数据注入到网络,使得网络中的路由器或链路不至于过载,而且它是一个全局性的过程,会接收到不同主机、路由器所发送过来的数据,那么这个中心的交换节点就会同时被使用,从而到导致繁忙进而造成拥塞,可是呢接收方在这么繁忙的情况下又很难去知道、去查询是哪个主机出了问题
  • 对于【流量控制】而言,要做的就是抑制发送端发送数据的速率,以使接收端来得及接收。它是一个点对点通信量的控制,是个端到端的问题

可能在看了上面的叙述后依旧有点模糊,没关系,我通过一个生活中的小场景来叙述一下

  • 其实对于它们二者可以看作为一个水龙头通过管道向水桶放水。对图a来说,它只有一个很小的桶,因为来不及接收从水管中注入的水,因此就告知水龙头那边的人【将水龙头拧得小一些,以此来减缓放水的速率】,这种两端之间的通信就叫做流量控制
  • 相反,对图b来说,它拥有一个很大的桶,完全可以接得下从水管中流过来的水,但是呢水管中间可能因为一些内部的各种污垢造成了拥塞,然后可以看到水管的上方已经积蓄了很多的水,因此就需要和管水龙头一方的人说【将水龙头拧得小一些,以此来减少流入水管内部的水量】,这种内部的缓解就相当于是拥塞控制

image.png👉对于同样的请求,都是将水龙头拧得小一些,但是目的却不一样。对照它们的原理之后,若是读者能明白,那也就懂了它们之间的区别


2、TCP的拥塞控制方法

了解了拥塞控制的一半原理,接下去我们来聊聊TCP面对这样的拥塞状况是如何应付的

为了集中讨论拥塞控制,假定:

  1. 数据是单方向传送的,对方只传送确认报文
  2. 接收方总是有足够大的缓存空间,因为发送窗口的大小由网络的拥塞程度来决定

① 接收窗口【rwnd】与拥塞窗口【cwnd】

  • 在流量控制中,我们提到了rwnd接收窗口,是由接收方维护的。表示接收方示意发送方自己可以接受的数据大小,以此来控制发送方发送数据的大小,
  • 在拥塞控制中我们再来聊聊一种窗口叫做cwnd拥塞窗口,它呢是由发送方维护的。它的大小取决于网络的拥塞程度,并且是动态变化着的。因为上面我们假定接收方的接收窗口足够大,因为发送方只需要考虑拥塞窗口的大小即可

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

  1. 只要网络没有出现拥塞,拥塞窗口就可以增大一些,将更多的数据发送出去,以此来提高网络利用率
  2. 当网络出现拥塞或可能要出现拥塞时,就把拥塞窗口减小一点,减少注入到网络的分组数,以便缓解网络出现的拥塞

发送方如何知道网络出现了堵塞?

  • 没有按时收到对方的确认报文,超时重传计时器启动,便判断出网络出现了拥塞

来总结一下这两个窗口 👉【接受窗口 rwnd】:由接收方维护,会根据接收缓存设置的值,并告知给发送方,反映接收方容量

👉【拥塞窗口 cwnd】:由发送方维护,会根据自己估算的网络拥塞程度而设置的窗口值,反映网络当前容量

② 慢开始和拥塞避免算法

接下去我们来介绍一下拥塞控制中的算法,首先是慢开始和拥塞避免算法这两种,它们是配合使用的

📚 【慢开始算法原理】:由小到大逐渐将数据字节注入到网络中,即逐渐增加拥塞窗口的数值

  • 接着你要知道一个东西叫做最大报文段SMSS,因为慢开始规定,每收到一个新的报文段后,可以把拥塞窗口增加最多一个SMSS的值。然后通过下面这个例子来介绍一下慢开始算法

image.png

  • 从上图可以看出,对于发送方它首先设置【cwnd = 1】,发送出第一个报文段,然后接收方确认了这个报文段再发送回一个确认报文段,这一点我们在前面TCP流量控制中也有说到过,这么一趟来回就叫做一个轮次,也可以叫做往返时延RTT
  • 经过了一个往返时延后,发送方便扩大拥塞窗口,令【cwnd = 2】,连续发出了两个报文段,然后接收方那个接收到之后就进行了返回确认,这是第二轮的RTT
  • 那发送方收到这两个确认报文段之后,便继续扩大自己的拥塞窗口,令【cwnd = 4】,一样,接收方接收到之后又会返回确认,这是第三轮的RTT
  • 依此类推。。。发送方若是试探到本网络的拥塞状况良好,就会不断地增加自己的拥塞窗口,尽快地将数据发送出去。这种慢开始的策略可以使得网络拥塞的概率减小

从上可以知道拥塞窗口在慢开始算法下会不断地增大,但是若是太大也不好,也会造成过多的数据涌入导致网络拥塞,因此便有了[慢开始门限ssthresh]这么一个状态变量,它的用法如下👇

  1. 当【cwnd < ssthresh】时,使用上述的慢开始算法
  2. 当【cwnd > ssthresh】时,停止使用慢开始算法而改用拥塞避免算法
  3. 当【cwnd = ssthresh】时,即可使用慢开始算法,也可使用拥塞避免算法

📚 【拥塞避免算法原理】:让拥塞窗口cwnd按线性规律缓慢增长,每个轮次RTT只加1

  • 然后我们便可以通过下面这张曲线图来看出TCP的拥塞窗口cwnd是如何变化的image.png

这一块可以听一听王道这个小姐姐讲的,还是蛮不错的👍

[video(video-VBwBwJlf-1675133417516)(type-bilibili)(url-player.bilibili.com/player.html… TCP拥塞控制)]

③ 快重传和快恢复算法

然后再来简单介绍一下快重传和快恢复这两个算法

📚 【快重传算法原理】:让发送方尽早知道发生了个别报文段丢失的情况,若发送发一连收到三个重复确认,便会立即重传接收方需要的报文段

  • 对于这三次报文的重复确认,就是我们前面介绍过的冗余ack

image.png📚 【快恢复算法原理】:当发送端收到连续三个重复的确认时,不执行慢开始算法,而是执行快恢复算法算法

  • 对于慢开始算法而言,会使拥塞窗口降到1后再使用拥塞避免算法慢慢升回到调整后的慢开始门限值
  • 对于快恢复算法而言,不会使拥塞窗口降到最小值1,而是降到门限值ssthresh / 2的位置,然后再次执行拥塞避免算法,使拥塞窗口缓慢地线性增大

以下是【TCP拥塞控制】的整个流程图,可以再对照回顾一下

image.png

3、主动队列管理AQM

上一节我们在讨论TCP拥塞控制时并没有和【网络层】采取的策略联系起来,其实它们之间有着密切的联系本小节考试不会涉及,可以有兴趣可以了解一下

  • 网络层的策略对TCP拥塞控制影响最大的就是——> 路由器的分组丢弃策略
  • 在数据结构中我们有学习过队列,直到它的原理是FIFO 先进先出,因此当队列满了的时候,后面再到达的所有分组就都会被丢弃,这种就叫做[尾部丢弃策略]
  • 对于这种策略其实容错率很高,因为随着尾部的一连串分组的丢弃,会影响到很多条TCP的连接,这就使得许多TCP连接在同一时间突然都进入慢开始状态,这在TCP的术语中就叫做【全局同步】(global synchronization)
  • 要解决这种全局同步的问题,就要使用到AQM主动队列管理这种措施,不要等到路由器的队列长度已经达到最大值时才不得不丢弃后面的分组,而是预感到会出现拥塞后做到主动丢弃这样便可以使得网络拥塞程度减轻甚至不会出现网络拥塞问题

九、TCP的传输连接管理【三次握手,四次挥手】

铺垫了这么多,有关TCP最最最重要的内容到了,你必须有很扎实的基础才能理解这些

  • 因为这个在考试中不会过多深入的涉及,但是在校招面试中是网络部分是必考的知识点,因此后面会专门出一个它的讲解

有网上找了许多关于TCP三次握手和四次挥手的视频和文章,筛选了一些,可供复习参考

这个蛋老师讲得很生动

[video(video-Z8TFOv5o-1675404444850)(type-bilibili)(url-player.bilibili.com/player.html…)]

楠哥则是解说得很详细

[video(video-srf9gN2C-1675404490370)(type-bilibili)(url-player.bilibili.com/player.html…)]

这篇是文章——> 博文参考

如果觉得难理解也没关系,了解一下即可,可以的话记住三次握手和四次挥手中客户端与服务端之间发送的报文字段

十、中英互译【背背就能拿分👈】

image.png

十一、终极押题密卷

  1. 传输层主要作用:完成进程到进程之间的数据传送。
  2. 运输层两种不同些协议:TCP、UDP;他们传输特点:P213

TCP【传输控制协议】

  • 提供可靠的、面向连接的运输服务(建立连接---》释放连接)
  • 不提供广播或多播服务
  • 开销较多(确认、流量控制、计时器以及连接管理)

UDP【用户数据包协议】

  • 传送数据之前不需要建立连接
  • 收到UDP报后,不需要给出任何确认
  • 不提供可靠交付,但是确实一种最有效的工作方式
  1. UDP和TCP的应用层协议。P213表5-1

image.png

  1. 端口号的含义和作用,服务器端使用端口号和客户端使用端口号;P214~215
  • 【含义】:在应用层和传输层之间的界面上,设置一个特殊抽象的,有了这个门,应用层中的应用进程就必须通过这个门才能将数据经过运输层发送到互联网;而且别的主机上的应用进程要寻找本主机中的某个某个应用进程,也必须通过这个门
  • 【作用】:只具有本地意义,为了标识计算机应用层中各个进程在和运输层交互时的层间接口
  • 【服务器端口号】
  • 熟知端口号:0 ~ 1023
  • 登记端口号:1024 ~ 49151
  • 【客户端端口号】:4915
  1. UDP主要特点:P216
  • 无连接、尽最大努力交付、面向报文、没有拥塞控制、支持一对一、一对多、多对一和多对多的交互通信、首部开销小
  1. TCP主要特点:P219
  • 面向连接、点对点、可靠交付、全双工通信、面向字节流
  1. TCP报文段首部格式。P226
  • 记住一些重要的字段
  1. TCP可靠传输的实现。P230
  • 对滑动窗口要重点理解掌握
  1. TCP连接建立。三次握手信号;
  • 第一次连接:link:是由客户端发起,客户端会向服务端发送一个报文,在这个TCP报文里,SYN位这个标志位是置1
  • 当服务段收到这个报文之后就知道客户端要和我发生一个连接,于是服务端就向客户端发送一个确认消息报文,这个消息报文里ACK位是置1
  • 第三次握手,此时当客户端收到服务端发过来的确认消息的报文之后,还要继续给服务端进行一个回应,所以它也会向服务端发过去一个ACK位是置1的消息报文
  1. TCP连接的释放过程,四报文握手,二个2次握手,了解
  • 四次握手是由客户端发起的,在这个报文里面FIN位标志位置1
  • 当服务端收到这个报文之后我就知道了客户端想要和我断开连接,但是此时服务端不一定能做好准备,因为当客户端要发其断开连接的这个消息以后,服务端可能还有没发完的消息要继续发送。以此时服务端只能进行一个消息确认,发送给客户端一个消息确认报文
  • 在发送完这个消息确认报文报文之后,稍过片刻就会继续给客户端发送一个断开连接的一个报文,也是一个FIN位置1的报文【由服务端发送给客户端】,这个报文表示服务端已经做好了断开连接的准备
  • 那么当这个报文发送给客户端后,客户端还要继续给服务端发送一个消息确认的报文ACK位是置1的

日常练习题讲解 —— 考试高频题型🔥

  1. 试说明运输层在协议栈中的==地位和作用==,运输层的通信和网络层的通信有什么重要==区别==?
  • 【地位和作用】:运输层既属于面向通信部分的最高层,同时也是用户功能中的最低层。当网络边缘部分的两台主机使用网络核心部分的功能进行端到端的通信时,都要使用到协议栈中的运输层
  • 【区别】:网络层为主机之间的通信提供服务;传输层则是在网络层的基础上,为应用进程之间的通信提供服务

  1. 一个UDP用户数据报的数据字段为8192字节。在链路层要使用==以太网==来传送。试问应当划分为几个IP数据报片?说明每一个IP数据报片的数据字段长度和片偏移字段的值
  • 加上UDP的8字节首部。IP层的数据字段为8200字节。以太网的MTU为1500B。假设IP层采用默认首部,即20字节。那么应划分为8200/(1500-20),为6片。前5片是1480字节。第6片是800字节。片偏移字段分别是:0,185[1480 / 8],370[2960/ 8],555[4440/ 8],740[5920/ 8],925[7400/ 8]

  1. 主机A向主机B连续发送了两个TCP报文段,其序号分别是70和100。试问: (1)第一个报文段携带了多少字节的数据? (2)主机B收到第一个报文段后发回的确认中的确认号应当是多少? (3)如果B收到第二个报文段后发回的确认中的确认号是180,试问A发送的第二个报文段中的数据有多少字节? (4)如果A发送的第一个报文段丢失了,但第二个报文段到达了B。B在第二个报文段到达后向A发送确认。试问这个确认号应为多少?
  • ① 由题可得,两个TCP报文的序号分别为70和100,因为第二个报文段的序号为100,所以可以看出第一个报文段携带了30B的有效数据,即70~99
  • ② 因为第一个报文段的最后一个字节为99B,所以主机B发回的确认号ack为99 + 1 = 100
  • ③ 因为主机B收到第二个报文段后发回的确认号ack为180,又因为它在上次发回给主机A说希望收到从100B开始的数据,所以可以看出主机A发送的第二个报文段中的数据有80B
  • ④ 因为第一个报文段中的数据范围是70~99,此时主机B想要收到这些数据,那就可以和主机A说希望收到70字节之后的数据,那主机A就可以知道在这个70字节之后的第一个报文段是丢失了,因此会重复第一个报文段,所以主机B的这个确认号ack应该要为70

  1. TCP在进行拥塞控制时是以分组的丢失作为产生拥塞的标志。有没有不是因拥塞而引起的分组丢失的情况?如有,请举出一种情况
  • 不是因为拥塞引起的分组丢失,那么分组就不会收到拥塞的影响,也就是说这个IP数据报可以到达它想要去的地方,但是呢由于这个IP报文过长,UDP将其转交给IP层后,IP层在传送时可能要进行分片,这就降低了IP层的效率,使得不同分片的报文到达终点的时间不一样,此时就会有数据报片无法及时到达终点,而早早到达终点的数据报片已经超时,所以会被丢弃,那此时就会导致这个【分组丢失】的现象

以上便是对于《计算机网路》中运输层这部分知识点的期末汇总,期盼正在阅读的你可以取得一个好成绩❤️


相关实践学习
容器服务Serverless版ACK Serverless 快速入门:在线魔方应用部署和监控
通过本实验,您将了解到容器服务Serverless版ACK Serverless 的基本产品能力,即可以实现快速部署一个在线魔方应用,并借助阿里云容器服务成熟的产品生态,实现在线应用的企业级监控,提升应用稳定性。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
相关文章
|
16天前
|
网络协议
计算机网络学习记录 运输层 Day5(2)
计算机网络学习记录 运输层 Day5(2)
16 1
|
9天前
|
缓存 网络协议 Linux
Linux、Python、计算机网络中的常见知识点
Linux、Python、计算机网络中的常见知识点
|
16天前
|
网络协议 算法 网络性能优化
计算机网络学习记录 运输层 Day5(1)
计算机网络学习记录 运输层 Day5(1)
14 0
|
2月前
|
缓存 网络协议 网络架构
网络层五大核心知识点
网络层五大核心知识点
|
2月前
|
存储
网络部分应掌握的重要知识点
网络部分应掌握的重要知识点
32 1
|
2月前
|
存储 监控 网络协议
网络管理相关(知识点详细)
网络管理相关(知识点详细)
36 1
|
2月前
|
缓存 网络协议 算法
计算机网络 第四章 运输层(习题)
计算机网络 第四章 运输层(习题)
49 1
|
2月前
|
安全 网络安全 网络架构
网络开发过程详细知识点
网络开发过程详细知识点
24 0
|
1月前
|
网络协议 算法 Linux
【嵌入式软件工程师面经】Linux网络编程Socket
【嵌入式软件工程师面经】Linux网络编程Socket
47 1