【JavaEE】——四次挥手，TCP状态转换，滑动窗口，流量控制

​

目录

一：断开连接的本质

二：四次挥手

三：“三次握手”和“四次挥手”异同

四：TCP连接状态转换

五：滑动窗口

六：流量控制

一：断开连接的本质
通过上一篇文章的学习，我们知道“三次握手”的目的和本质就是让通信双方能够保存对端的信息，当信息这个数据量过大的时候，就要引用数据结构。

那么断开连接的本质就是把对端的信息从数据结构中进行删除，释放掉。

二：四次挥手
1：FIN

2：过程梳理
引入：与“三次握手”中“一定是客户端先主动”不同，“四次挥手”中服务器和客户端两者谁都可以先主动（分手像极了爱情~）这里我们用“客户端先主动”充当例子

3：能合二为一吗？
引入：在上述图解步骤下，服务器和客户端各自给对方发起FIN，并再给对方返回ACK，“四次挥手”后代表着通信双方“和平分手”。那么这里的②③步骤是否也能“合并”呢？

答案是：可以合并，但是不能100%的合并——“如合~”

如果②③两者发送的时间间隔很长，那么就不能合并

三：“三次握手”和“四次挥手”异同
1：相同点

2：不同点

四：TCP连接状态转换
引入：在TCP的连接中，数据结构会保存两端的信息，在这里面就有一个属性，叫做“状态”，操作系统可以根据状态的不同，决定应该对连接做什么

1：TCP状态转换图

铁铁们看到这个图脑壳都大了吧，俺也是，这里我们只介绍几个比较重要的状态即可

2：LISTED

3：ESTABLISHED状态
注：established（译为：已建立的）

表示：客户端和服务器已经建立完毕（三次握手完了）

4：CLOSE_WAIT（面试高频）

（1）过程梳理

（2）作用

5：TIME_WAIT（面试高频）

（1）过程梳理

（2）作用

五：滑动窗口
引入：之前我们简单了解一次数据传输，所经历的过程。

我们可以发现一个问题：发一个数据就要等一个ack，这样的效率是不足以满足现在“信息爆炸”的现状的。

所以我们引出：批量传输这个概念

1：批量传输
顾名思义——先发一个数据，不等ack了，下一个数据接着发，连续发了好多个ack之后，使用同一份时间来等待ack

好处：减少了总的等待的时间内（下面这张图能非常形象的表现出来）

2：滑动窗口

3：ack丢包
看图——

1001的ack应答丢包了，但是2001这个ack没有丢包，主机A收到②这个ack后就知道主机B2001之前的数据都收到了，所以①号ack丢包问题不大，这种情况无需处理，对于TCP传输的可靠性没有影响。

4：数据丢包

（1）快速重传
注意点①

注意点②

（2）优点
上述重传的过程，整体效率非常高，做到了“针对性”的丢包重传，不必重新发送，这种重传叫做“快速重传”

（3）总结

六：流量控制
引入：上述滑动窗口可以提高数据的传输效率，窗口越大，更多数据复用同一块时间，效率就更高，那么问题来了，窗口越大越好吗？显然不行

1：缓存区上限
数据到达接收方是先暂时存储在缓冲区当中，等到一定的数量后，接受方在一次性拿(read)出来。

试想发送方如果一下子发送数据太快，导致接收方的缓冲区装不下了，就会导致丢包，这时在重传也没用了（因为已经返回ack了）

2：窗口动态变化
与其等待接收方缓存区满了，不如提前感知到，就减慢发送数据的速度，（下面有请我们的老朋友）

16位窗口大小，就能很好的动态控制窗口的大小，通过这个字段，来给发送方反馈发送速度，很明显这个字段对于发送方的报文中没有意义，只有ack报文中才有意义

注：这个16位并不是实际上的大小——在TCP报头中有一个参数叫做窗口扩展因子

实际窗口大小 = 16位窗口大小* 2^窗口扩展因子

​