同样我们先认识一下TCP数据报包中，6个标志符中的FIN——结束报文段

单词为finish（结束）——>缩写为FIN

在之前的学习中，我们调用通过ServerSocket类调用close方法就会触发FIN，这里的FIN也是在内核中完成。

同样如果我们结束一个进程也会触发FIN【JavaEE】——TCP回显服务器（万字长文超详细）-CSDN博客

编辑

2：过程梳理

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

（1）客户端发起FIN（结束报文段）

编辑

（2）服务器ACK应答并且也发起FIN（结束报文段）

编辑

（3）客户端ACK应答

编辑

3：能合二为一吗？

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

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

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

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

1：相同点

都是需要有一端先发起SYN/FIN，然后对端在返回ACK

传输顺序：syn/ack/syn/ack fin/ack/fin/ack

2：不同点

三次握手中中间两次一定能够合并，四次挥手中中间来那个词不一定能够合并

三次握手中一定是客户端先主动，四次挥手中谁先主动都可以

四：TCP连接状态转换

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

1：TCP状态转换图

编辑

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

2：LISTED

listed（译为：已登录的）表示：服务器这边已经建立好了ServerSocket，并且绑定好了端口号，随时准备接收客户端的连接

编辑

步骤一：我们先启动服务器（代码在之前TCP回显服务器那一篇文章，直接复制粘贴即可）

【JavaEE】——TCP回显服务器（万字长文超详细）-CSDN博客

编辑

步骤二：打开命令窗口，输入netstat -ano

编辑

步骤三：服务器加上限制条件，我们看9090这个在代码里选择连接的端口

编辑

3：ESTABLISHED状态

注：established（译为：已建立的）

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

步骤四：客户端和服务器连接进入ESTABLISHED

注：这里双方进入时间差极小，肉眼是看不出来先后顺序的，除非精确查看日志里的时间戳

编辑

4：CLOSE_WAIT（面试高频）

close_wait（译为：关闭等待）——谁被断开连接，谁进入close_wait状态

（1）过程梳理

看图客户端发起FIN断开连接（四次挥手），服务器收到后发送ACK应答报文后进入close_wait状态。

这个状态是比较难观察到的，因为服务器发送ACK和FIN的时间间隔极短，即关闭socket文件的时间极短，此时close_wait -> last_ack 状态的切换非常快。

（2）作用

阻塞等待客户端数据请求

注：如果发现服务器或者客户端出现大量的CLOSE_WAIT，意味着很可能是socket没有关闭，出bug了。

编辑

5：TIME_WAIT（面试高频）

谁主动断开连接，谁进入TIME_WAIT状态

（1）过程梳理

服务器返回给客户端ASK和FIN，客户端收到返回ASK应答后，进入TIME_WAIT状态

（2）作用

如果最后一个ACK丢包了，服务器迟迟收不到ACK，就会重传一个FIN，客户端收到后也会相应重传一个ACK。

而TIME_WAIT就为这个过程留下充足的时间，这个等待的时间不是无休止的等待（连机器都不会无限制的等待，更何况爱情呢~），最多2MSL（MSL是系统内核的配置项）

五：滑动窗口

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

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

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

1：批量传输

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

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

编辑

2：滑动窗口

编辑

3：ack丢包

看图——

编辑

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

4：数据丢包

编辑

（1）快速重传

注意点①

看上图，主机A发送的1001~2000这个数据丢包了，但是2001后面的数据还在发送，此时主机B就会对2001后面的数据，返回ack，多次强调下一个数据是1001，服务器收到三次这个ack之后，就知道1001~2000这个数据丢包了，就会重传（有点超时重传的感脚~）

注意点②

主机B收到1001~2000这个丢包的数据后，直接会跳到索要7001这个数据包了，而不是2001~。

这是因为TCP有一个接受缓冲区，你可以想象成一个队列编辑

（2）优点

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

（3）总结

①“确认应答”、“超时重传”、“滑动窗口”、“快速重传”这四种机制并不冲突，可以同时存在。

②短时间发送了很多数据，窗口才滑的起来

③判定丢包的标准是：连续有多个ack索要同一个数据；普通传输判定标准是：ack超时没有到达

六：流量控制

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

1：缓存区上限

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

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

2：窗口动态变化

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

编辑

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

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

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

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

一：断开连接的本质

二：四次挥手

1：FIN