目录
题外话
正题
滑动窗口机制
如果出现丢包问题怎么办??
滑动窗口触发条件
流量控制
拥塞控制
小结
题外话
宿舍没有空调的感觉谁懂?!!!
人要蒸发了,八点自动热醒,直接强行学习
正题
我们继续讲解TCP协议核心机制
上篇博客讲完了,建立连接机制,确认应答机制,超时重传机制,接着往下书写
滑动窗口机制
由于确认应答机制,每次从客户端向服务器发送数据,服务器都会返回一个ACK(同步确认包)
如下图
我们可以看到,每次客户端发送数据到服务器,都要等待服务器返回ACK数据包才会再发送数据
如果数据包比较多,发送次数就会变得更高,而且会影响效率
当我们触发滑动窗口,就会把一条一条的数据发送转换成批量发送并且批量等待ACK
当客户端收到一个ACK数据包的时候,客户端就会往后继续发送数据包,比如客户端收到了服务器发来的1001序列号的ACK数据包,然后就会发送3001-4000这个数据包
如下图
这样就可以在同一时间发送多个数据包,从而使效率提升
如果出现丢包问题怎么办??
滑动窗口机制是一定要保证可靠性的
下面有两种丢包情况
1.客户端发送数据包抵达,但ACK数据包丢包
如果ACK数据包丢包,不会做任何处理
比如序列号1001和2001的ACK数据包全部丢失,但是3001ACK数据包没有丢失,成功发送到客户端,这就意味着客户端已经知道服务器接收到了0-1000,1001-2000的数据包
如下图
2.客服端发送数据包丢包
如果客户端发送序列号为0-1000数据包时发生丢包,服务器会不断发送序列号为1001的ACK,当客户端收到若干次相同序列号ACK,客户端则会重新发送丢包的数据包,并且之前客户端继续发送过来的数据包服务器也会正常接收
如下图
针对上述出现的丢包问题,整个处理过程是很高效的,这叫快速重传和超时重传不同
1.对于ACK丢失,不做任何处理
2.对于数据包丢失,只需要把缺失部分数据重传即可,不需要重传其它数据
滑动窗口触发条件
如果TCP传输数据比较少,不频繁,就不会触发滑动窗口
如果短时间传输大量的数据,此时才会触发滑动窗口
流量控制
在服务器会有一个接收缓冲区(阻塞队列)
服务器发送的ACK数据包中会在tcp报头中指定一个字段,表示未使用空间大小
客户端会根据接收缓冲区中的未使用空间的大小进行数据传输控制
如下图
客户端发送的数据包会被应用程序消耗
客户端会周期性发送一个"窗口探测报文",主要是为了触发服务器发送ACK
从而知道接收缓冲区空间情况
接收缓冲区大小在TCP中是可以扩容的,接收缓冲区中的未使用空间越多,也就意味着传输的数据可以更多
拥塞控制
拥塞控制和流量控制都是为了搭配滑动窗口机制而产生的
如上图,当我们要将大量数据包从A设备发送到B设备,中间可能会经过好几个节点
如果中间任何一个节点出现丢包都会影响整体数据传输效率
TCP会将它们都看做一个整体
通过"实验"的方式去找到一个合适的窗口大小从而提升数据传输效率
窗口具体变动如下图
由图可见窗口时刻处于一个动态变化
小结
本篇博客讲解了滑动窗口机制,流量控制机制,拥塞控制机制
喜欢的家人们麻烦给个三连(点赞关注收藏!!!)
