本文是接着上篇 画图带你理清TCP协议三次握手和四次挥手 继续带你学习TCP 其他 7 大特性。
四、滑动窗口机制
五、流量控制
六、拥塞控制 (安全机制)
七、延迟应答 (效率机制)
八、捎带应答 (效率机制)
九、粘包问题
十、保活机制
TCP总结
四、滑动窗口机制
滑动窗口机制,是在可靠性的前提下,进一步地提高传输效率
认识滑动窗口
一发一收的方式:TCP 协议需要对数据进行确认后,才可以发送下一个数据包,如图:
如上图,发送端每发送一个数据包,都需要得到接收端的确认应答以后,才可以发送下一个数据包,是一问一答的串行过程;即每次传输数据都需要等待一个对应的等待时间,那么传输 N 份数据,就需要等待 N 次应答时间,总的传输时间:N 份数据传输时间 + N 份应答传输时间
一发一收的方式性能较低,那么我们一次发送多条数据,就可以大大地提高性能(其实是将多个段的等待时间重叠在一起了),如图:
滑动窗口本质上是批量传输数据
总的传输时间:N 份数据传输时间重叠成了一份时间,N 份应答传输时间重叠成了一份时间,相当于把多份数据的传输时间和等待 ACK 的时间压缩成一份了,总的等待时间少了,传输效率也就高了
a. 窗口
窗口大小: 不等待 ACK 的情况下,批量发送的最大数据量,就叫"窗口大小" (如上图,就是4000个字节,4个字段)
b. 滑动
窗口范围内的数据是在等待这些数据的 ACK (已经被发送出去)
如上图,当发送方收到 2001 的 ACK,意味着 1001 - 2000 的数据对方已经接收,此时立刻继续传输 5001 - 6000 的数据,则等待 ACK 的数据包的序号就是 2001,3001,4001,5001
丢包问题处理
丢包的两种情况如图:
情况1: 确认应答 (ACK) 丢包
不需要进行额外的处理;在这种情况下,部分 ACK 丢了并不要紧,因为可以通过后续的 ACK进 行确认
理解"确认序号"的含义
从当前序号开始,前面的数据都已经正确到了
如上图,是 1001 的 ACK 丢失,2001 的 ACK 没丢,此时,发送方收到 2001 之后,就会认为 1 - 1000 这个数据也是顺利到达的,1001 丢了无所谓,2001 的 ACK 能够包含 1001 ACK 中的信息
情况2: 数据包丢失
如下图,若是 1001-2000 丢失,然后 2001-3000,3001-4000 等后边的几个数据都顺利到达,此时主机 B 反馈的 ACK 的确认序号始终是 1001;
此时若主机 A 发现连续几个 ACK 都是1001,主机 A 就知道,1001 这个数据丢失,就会重传 1001;
在重传 1001 之前,收到的确认序号都是 1001;
当主机 B 收到 1001 这个数据的时候,由于 2001-7000 这些数据前边已经收到过,接下来的 ACK 就从 7001 开始;
此处的重传,只是重传丢了的数据,其他数据不需要额外重传—— 快速重传(搭配滑动窗口下的超时重传)
"乱序"传输:
五、流量控制
流量控制: 根据接收方的处理能力来反向制衡发送方的发送效率(窗口大小) (通过接收缓冲区的 “剩余空间大小” 来决定发送方的速率)
窗口大小不能无限大,传输速率太快,接收方可能处理不过来
在使用滑动窗口机制进行数据传输时,发送方根据实际情况发送数据包,接收端接收数据包;由于接收端处理数据包的能力是不同的,因此可能出现两种情况:
(第一次的窗口大小是根据链路带宽的大小来决定的) ,发送数据包,接收端接收这些数据包,并返回确认应答包,告诉发送端自己下次希望收到的数据包是多少(新的窗口大小),发送端收到确认应答包以后,将以该窗口大小进行发送数据包
如下图:
图解:
六、拥塞控制 (安全机制)
拥塞控制是考虑网络传输路径上的拥堵程度
虽然TCP有了滑动窗口这个大杀器,能够高效可靠的发送大量的数据;但是如果在刚开始阶段就发送大量的数据,仍然可能引发问题;因为网络上有很多的计算机,可能当前的网络状态就已经比较拥堵,在不清楚当前网络状态下,贸然发送大量的数据,是很有可能雪上加霜,因此,TCP引入 慢启动 机制,先发少量的数据,探探路,摸清当前的网络拥堵状态,再决定按照多大的速度传输数据
线增积减 (和式增加,积式减少)
像上面这样的拥塞窗口增长速度,是指数级别的,“慢启动” 只是指初使时慢,但是增长速度非常快,具体的增长如下图:
刚开始的时候从1指数增长,到达阈值后开始线性增长,如果出现网络阻塞,直接减小到初始值,然后再次指数增长到达新的阈值(新阈值为上次阻塞窗口大小的一半),再次线性增长直到网络阻塞,一直这样动态变换循环
为啥要动态变化??
网络的拥堵情况是瞬息万变的,我们要随时根据网络的实际情况进行动态调整 (随时适应网络的变化过程)
七、延迟应答 (效率机制)
目的是为了提高效率,在流量控制的基础上,尽量返回一个合理但又比较大的窗口
在前面我们提到,在发送端发送数据后,接收数据的主机需要返回 ACK应答,此时若立刻返回,窗口可能比较小 (因为缓冲区的数据只处理了一部分),所以 TCP 采用了延迟应答机制,举例:
不带延迟应答:
有一个超市,假设泡面库存最多存放100箱,当前已经存了80箱,空余20箱;
第二天一早,送货小哥来问:“老板,你明天需要多少面?”
老板:“你最多送20箱就行。”
带延迟应答:
第二天一早,送货小哥来问:“老板,你明天需要多少面?”
老板:“我晚上的时候打电话告诉你需要多少。”
(可能白天又卖出了10箱,第二天最多送10箱即可)
延时应答其实就是让 ACK 的发送时间晚一会儿 (不影响可靠性的前提下);
延迟的时间中就会给应用程序提供更多的消费数据的机会,此时时间到了,再发送 ACK 的时候,得到的窗口大小(接收缓冲区的剩余空间就会更大一些)
窗口越大,网络吞吐量就越大,传输效率就越高;我们的目标是在保证网络不拥塞的情况下尽量提高传输效率
问:所有的包都可以延迟应答么?
肯定不是
八、捎带应答 (效率机制)
在延迟应答的基础上,为了进一步提高程序运行效率而引入的机制
在很多情况下,客户端和服务器的通信模式一般都是 Request - Response 模式,即 “一问一答”
如图:
注意:
三次握手中间的 SYN 和 ACK 都是由内核决定的,不涉及不同的时机
上述提到的四次挥手的过程,ACK 是内核决定的,发的 FIN (close方法) 是应用程序代码决定的
九、粘包问题
严格说,粘包问题不是 TCP 自身的机制,而是面向字节流传输所具备的共性问题
粘包,指粘的是应用层数据包,导致数据在处理的时候,容易读取半个应用层数据包
面向字节流: 指的是一次读一个字节,或者一次读两个字节,或者一次读 N 个字节都行
举例:双方建立连接,需要在连接后一段时间内发送不同结构数据,如连接后,有好几种结构
读多少个字节才是一个完整的应用层数据包,这个是不清楚的
若一次读一个汉字,读出来就是 “好”;若一次读三个汉字,读出来就是 “好个P”
读法不一样,最终的含义差异也很大;读取应用层数据,就不应该只读半个包
如何避免粘包问题?
归根结底就是一句话,明确两个包之间的边界
TCP 协议本身不帮你区分应用层数据包,相对而言,UDP 协议没这个问题 (UDP 协议就是按照数据包为单位进行收发的)
比如,上述回答改为 “好个P;”
用分号 ;当做两个包的分隔符,读数据,一直读到分号;才认为是一个完整的应用层数据包
应用层协议,是程序猿自己来定的,只要保证分隔符不和正文冲突即可**
比如,上述用例改为 “4你好不好3好个P”
先读取最开始的四个字节,得到包的长度3;继续读取3个汉字,于是就读取一个完整的包
HTTP 协议基于 TCP 的应用层协议,自己就会处理好粘包问题,上述两种方式都使用到了:
对于 GET 请求,分隔符就是空行
对于 POST 请求,Content-length 来指定包的长度
思考:对于UDP协议来说,是否也存在 “粘包问题” 呢?
十、保活机制
双方建立交互的连接,并不是一直存在数据交互,有些连接会在数据交互完毕后,主动释放连接,而有些不会,那么在长时间无数据交互的时间段内,交互双方都有可能出现掉电、死机、异常重启,还是中间路由网络无故断开、NAT超时等各种意外
在这些 “异常情况” 下,TCP 对于连接会有一些特殊的处理
举例:
1.进程崩溃: 这种情况,TCP 连接会正常四次挥手 (只要是进程退出,都会自动关闭相关的文件)
2.主机关机(按照流程关机):关机的时候会强制先杀进程,杀进程过程之中就要进行四次挥手了
3.主机断电 / 网线断开:
TCP总结
TCP 之所以复杂,是因为它既要保证可靠性,同时又尽可能地提高性能
可靠性:
校验和,序列号
确认应答,超时重传
连接管理,流量控制,拥塞控制
提高性能:
滑动窗口,快速重传
延迟应答,捎带应答
其他:
定时器(超时重传定时器,保活定时器,TIME_WAIT定时器等)
原文链接:https://blog.csdn.net/m0_47988201/article/details/122735834