TCP四次挥手

TCP释放连接，需要客户端和服务器端共发送四个包，即“四次挥手”。

“挥手”过程

来自TCP报文段的首部

1.序号seq

指本报文段所发送的数据的第一个字节的序号。由发送端随机生成

例如：一报文段的序号字段值为101，而携带的数据共有100字节。

这就表明：本报文段的数据的第一个字节的序号是101，最后一个字节的序号是200。

所以，下一个报文段(如果还有的话)的数据序号应该从201开始，即下一个报文段的序号字段值为201。

2.终止FIN

用来释放一个连接。

FIN=1，表示此报文段的发送方的数据子发送完毕，并要求释放运输连接。

3.确认ACK

仅当ACK=1时确认号字段才有效。当ACK=0时，确认号无效。

4.确认号ack

是期望收到对方下一个报文段的第一个数据字节的序号。

若确认号为101，则表明：到序号100为止的所有数据都已正确收到。

例如：B正确收到了A发送过来的一个报文段，其序号字段值是101，数据长度为200，这表明B正确收到了A发送的到序号为300为止的数据。所以，B期望下次收到序号为301开始的数据，于是B在发送给A的确认报文段中把确认号设为301。

状态

1.ESTABLISHED：初始状态，表示客户端与服务器处于连接中

2.FIN_WAIT1：客户端向服务端发送FIN报文，请求断开连接

3.CLOSE_WAIT：服务器收到FIN向客户端发送ACK，表示确认收到请求

4.FIN_WAIT2：客户端收到服务器发送的ACK，连接断开一半。此时，如果服务器还有数据要发送给客户端，可以继续发送

5.LAST_ACK：服务器发送完数据，发送FIN报文

6.TIME_WAIT：客户端收到服务器的FIN，发送ACK给服务器

7.CLOSED：服务器收到ACK后

8.CLOSED：客户端经过2MSL后。此时，连接全部断开

2MSL？？？

1.为了保证A发送的最后一个ACK报文段能够到达B。

假如这个ACK报文段丢失：处在LAST-ACK状态的B收不到对已发送的FIN+ACK报文段的确认。B会超时重传这个FIN+ACK报文段，而A就能在2MSL时间内收到这个重传的FIN+ACK报文段。接着A重传一次确认，重新启动2MSL计时器。

2.防止“已失效的连接请求报文段”。

该知识点在“TCP三次握手”中有详解。

为什么是三次握手，四次挥手

由于TCP连接是全双工的，断开连接会比建立连接麻烦一点点~

为什么是三次握手，四次挥手

建立连接时，服务端的LISTEN状态下的SOCKET当收到SYN报文的建连请求后，它可以把ACK和SYN（ACK起应答作用，而SYN起同步作用）放在一个报文里来发送。

关闭连接时，当收到对方的FIN报文通知时，它仅仅表示对方没有数据发送给你了；但未必你所有的数据都全部发送给对方了，所以你可以未必会马上会关闭SOCKET,也即你可能还需要发送一些数据给对方之后，再发送FIN报文给对方来表示你同意现在可以关闭连接了，所以它这里的ACK报文和FIN报文多数情况下都是分开发送的。

哦~~~，断开连接时，服务器的FIN和ACK不能同时发送，分开发送，所以比建立连接多一次~

过程

客户端：我没有数据要向你发送了，再见？

服务器：好的，我知道了

服务器：发送剩余数据

服务器：我也没有数据向你发送了，再见？

客户端：好的，再见！

愉快结束~