网络编程5——TCP协议的五大效率机制:滑动窗口+流量控制+拥塞控制+延时应答+捎带应答


前言

本人是一个普通程序猿!分享一点自己的见解,如果有错误的地方欢迎各位大佬莅临指导,如果这篇文章可以帮助到你,劳请大家点赞转发支持一下!

本文讲解了TCP在保证安全可靠的前提下,提高效率的五大机制。


一、TCP协议段与机制

TCP协议的特点

特点说明
有连接刻意保存对端的相关信息
可靠传输尽全力将数据传输过去不是百分百成功,自己会知道数据传输是否成功
面向字节流以一个字节为基本单位(一个数据可以分成几份 多次发多次收)
有接收缓冲区,也有发送缓冲区接收缓冲区:接收方用一个特殊的数据结构来组织接收到的数据,使用数据就从接收缓冲区拿,然后接收缓冲区就会删除已经拿走的数据。
发送缓冲区:发送方将要发送的数据存入发送缓冲区,等发送缓冲区满了,才会集中发送一次,可能会导致BUG(数据写到了发送缓冲区而没有发送出去),因此代码中发送数据时尽量刷新缓冲区
大小不受限对于要传输的数据大小没有要求
全双工一条通信路径,双向通信。(可以同时发送和接收数据)

TCP报头结构

在这里插入图片描述

6位标志位
在这里插入图片描述


TCP协议的机制与特性

TCP的协议段格式,比UDP的协议段格式复杂一万倍!😵😵
所以他的机制与功能也比UDP更加强大!!😇😇

TCP对数据传输提供的管控机制,主要体现在两个方面: 安全和效率
这些机制和多线程的设计原则类似: 保证数据传输安全的前提下,尽可能的提高传输效率

TCP协议的机制与特性
1️⃣确认应答
2️⃣超时重传
3️⃣连接管理
4️⃣滑动窗口
5️⃣流量控制
6️⃣拥塞控制
7️⃣延时应答
8️⃣捎带应答
9️⃣面向字节流
🔟异常处理


二、TCP协议的 滑动窗口机制

TCP协议中确认应答机制,对每一个发送的数据段,都要给一个ACK确认应答。收到ACK后再发送下一个数据段。
这样做有一个比较大的缺点,就是性能较差。

在这里插入图片描述

如上图,如果在数据往返的时间较长的时候,等待数据送达后,还要再等待ACK,这一来一返的时间就浪费了,后面要发送的数据全都得等着排队,效率就不高。


因此为了在保证可靠传输的前提下尽可能的提高效率,就引入了 滑动窗口机制

在这里插入图片描述

如上图,规定可以批量传输数据(同时发送多个数据段)。
相当于有一个窗口,窗口里的数据都可以同时发送,这些数据段的大小加在一起等于窗口大小。


假设窗口大小为4000个字节,每条数据段的大小为1000字节。

同时发送4个数据段,然后等待ACK,等到了一个呢,就可以证明有1个大小为1000个字节的数据段,送到了,那么此时就是只有3个数据段,3000个字节大小的数据在发送中。

但是窗口大小为4000个字节,所以我还可以再同时发送1000个字节的数据。窗口向下移动,再发送一个数据大小为1000字节的数据段。

这就是滑动窗口的原理: 规定一个窗口可以同时发送多少数据,当有ACK返回,确定有多少数据送到了,就再发送多少数据,从而达到了提高效率的目的。 规当传输速度足够快时,那么窗口就变成了滑动,因此叫做窗口滑动。


那么如果发生了丢包怎么办?

第一种情况:ACK丢包了

在这里插入图片描述

如上图,前三个ACK都丢包了,那也毫无影响,只要第四个ACK送达了,就没啥,因为ACK中的确认序号就是告诉他,确实序号之前的字节都收到了,因此只要最后一个ACK没丢就没事。

如果是最后一个包丢了,或者是最后几个都丢了,那就会触发超时重传机制。TCP安全第一位


第二种情况:数据丢包了

此时采取的策略为:只重传丢了的数据,不丢的数据不重传。
这个策略也称之为快速重传。

在这里插入图片描述

如上图,第二个数据段丢了,那么 后续所有应答报文中的确认序号就会一直是1001(即索要1001及以后的数据), 不会因为2001-3000送达而改变,会一直保持到1001以后的数据送到。

在这里插入图片描述

主机B当中会有一个接收缓冲区,采用特定的数据结构去组织这些收到的数据, 当1001-2000的数据送达时, 会自动排序调整位置。然后ACK中的确认序号就继续变为4001。

使用数据会从缓冲区当中拿数据,但是如果传输速度太快,那么缓冲区也会满。
如果缓冲区满了,你再发送过来数据,不会阻塞等待而是将你发来的数据直接丢掉,这就造成了效率浪费。


这就引出了另外两个个效率机制:流量控制机制与拥塞控制机制。


三、TCP协议的 流量控制机制

流量控制机制也对保证可靠传输有一定作用。

窗口滑动机制,提高了效率。但是接收缓冲区的空间也有限,如果接收缓冲区满了,那么再传输数据也是丢包,此时还不如传的慢一点。

所以啊就有了流量控制机制。

流量控制机制: 让报文中携带一个"窗口大小"这样的字段,来进行流量控制,只有ACK标志位为1时,即ACK报文才会生效

"窗口大小"的作用:建议发送方的滑动窗口大小(建议不是一定,但是作用也很大)

接收缓冲区满了,即"窗口大小"为0: 发送方暂停发送,每隔一段时间发一个窗口探测报文,如果"窗口大小"不是0了,就继续发送。


四、TCP协议的 拥塞控制机制

一条数据由一台设备发送到另一台设备中,这中间序列经过一系列的中间节点(很多个交换机和路由器)。

如果传输路径上的任何一个节点的发送能力遇到瓶颈(收发数据太多等问题),那么对经过这个节点的数据的传输速率都会产生明显的影响。
即数据传输的快不快,取决于整体路径上最慢的节点(木桶效应)。

拥塞控制: 衡量中间节点(传输路径上发送方与接收方之外的节点)的传输能力,得出一个拥塞窗口大小 ,来避免因为个别节点拉跨而带来的效率浪费。

因为网络环境复杂,每次传输可能走的路径都不同,且各个节点的传输能力也不是一成不变的(用户多时,可能就慢,用户少时,可能就快)。
因此拥塞窗口的计算方法是实验法:通过实验的方式,找到一个合适的发送速率,实现动态平衡。

拥塞窗口的计算方法:
1️⃣:开始时,以一个小速率来传输数据。
2️⃣:如果没有发送丢包,慢慢加快这个速率。
3️⃣:如果出现丢包,立即把速率再减小。
4️⃣:重复2️⃣3️⃣。

感兴趣的朋友可以去搜一下具体的计算方法。

“窗口大小” 取 流量控制(衡量接收方的处理能力) 拥塞控制(衡量中间节点的处理能力) 这两个中最小的那一个。


五、TCP协议的 延时应答机制

延时应答机制:将确认应答机制中的ACK应答报文,延时发送。

为什么延时发送ACK会提高效率呢?

TCP中决定传输效率的关键元素是"窗口大小"。
"窗口大小"取决与流量控制与拥塞控制。
而流量控制就取决于接收方的接收缓冲区。


这里咱们要搞清楚一个事情:
发送方一直发送数据(一直生产),而应用程序一直从接收方的接收缓冲区中读取数据(一直消费)。


如果立刻返回ACK,那么ACK的"窗口大小"假设为n
如果稍微等一会会,那么等的这一会,应用程序就会在这一会中消费一些数据,因此再返回ACK,那么"窗口大小"就大概率会比n大。


所以通过延时一会发送ACK,使得ACK中的"窗口大小"变大一点,传输速率也就快一点。

不是所有的包都可以延迟应答

  • 数量限制:每隔N个包就应答一次(操作系统不同N也各有差异)
  • 时间限制:超过最大延迟时间就应答一次

六、TCP协议的 捎带应答机制

捎带应答机制是基于延时应答机制开发的。

一般客户端服务器模型都是一问一答的形式。 即客户端发送一个请求request,服务器返回一个响应response。

正常流程:

1️⃣客户端向服务器发送一个request。
2️⃣服务器收到reques,并返回一个应答报文ACK
3️⃣服务器返回一个response
4️⃣客户端收到response,并返回一个应答报文

基于延时应答于捎带应答机制:

1️⃣客户端向服务器发送一个request。
2️⃣服务器收到reques(延时应答,让ACK暂缓发送)
3️⃣服务器返回一个 (response+ACK)报文 (如果response在ACK发送前就计算完毕,那么就会触发捎带应答机制,把response与ACK合并)
4️⃣客户端收到(response+ACK)报文,并返回一个应答报文

四次挥手有可能是三次挥手也与上述流程相同。

发送一个一定比发送两个快,所以效率得到了提高。


总结

以上就是今天要讲的内容,本文分享了TCP协议的五大效率机制,讲述了TCP在保证安全可靠的前提下是如何提高效率的,尽管如此,TCP的效率仍然没有UDP快,保证安全可靠必然会牺牲一部分效率。

路漫漫不止修身,也养性。

  • 2
    点赞
  • 13
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值