计算机网络——TCP四次挥手过程详解
上次写了TCP的三次握手，此次总结一下TCP的四次挥手的过程，理清楚为何握手是三次，挥手须要四次。web
TCP是面向链接的，链接的创建过程被称为“三次握手”，天下没有不散的宴席，有了链接的创建，就会有链接的断开，TCP断开的过程一般被称为“四次挥手”。服务器
首先要明确一点，断开TCP请求既能够由客户端发起也能够由服务端发起。这里讨论客户端发起断开链接请求的状况。网络
过程以下：（能够先看文末的通俗对话模拟）
(1) 客户端A发出一个关闭链接的命令，这会使得客户端的TCP发送一个特殊的TCP报文段给服务器B，这个报文段的FIN标记位（finish的缩写，表示结束）被置为1。此时A由ESTABLISHED状态转为FIN_WAIT_1状态，等待来自B的ACK报文。svg
(2) B收到这个报文段，检测到这是请求关闭链接的报文，发送一个确认报文段（ACK字段为1）给A，表示收到，通知A能够释放链接了。A收到这个ACK报文时，单方面释放了与B的链接，此时他不能再向B发送应用层数据了，但因为B可能还有数据没有发送完，因此此时A还能够接收来自B的报文段。此时A进入FIN_WAIT_2状态，等待来自B的FIN报文。B由ESTABLISHED状态进入CLOSE_WAIT状态。.net
(3) 当B向A发送完全部数据以后，也向A发送一个关闭链接的报文段，FIN和ACK都为1的报文段（尚未搞清楚为何ACK也是1，但估计是为了与第一次的请求关闭报文段区分开），并等待来自A的确认报文段。此时B进入LAST_ACK状态。计算机网络
(4) A接收到B的关闭链接请求后，给B发一个确认报文段，通知B能够释放链接了。B收到以后，释放全部链接资源，进入CLOSED状态。而A并无立刻释放资源，而是进入TIME_WAIT状态，等待一段时间（自定义，一般为30sec、1min或2min），使得能够在ACK报文段丢失的状况下进行重传。在等待时间结束以后，链接正式关闭，客户端的全部资源也被释放，进入CLOSED状态。xml
如下分别为客户端和服务端的TCP链接状态转换（结合TCP的三次握手）：
由上述的讨论可知，之因此须要进行四次挥手，在于某一方发起关闭链接的请求时，能够保证本身再也不须要发送数据，但并不能猜想到对方是否已经发送完数据了，因此只是先通知对方我要断开链接了，你也差很少能够断开了，对方能够断开的时候则又会发一个断开链接的报文段。而额外的两个的ACK报文是确保两个FIN报文都被接收到。
模拟成一段对话就是：blog
- A：“我发完数据了，不发了，要断开链接啦！”（FIN报文）
- B：“好啊，你不发就不发，但先收完我发给你的数据好吗，很快就发完了。”（ACK报文）
（A继续接收来自B的数据）图片
- B（发完数据）：“好了，我也发完数据了，能够断开链接了！”（FIN/ACK报文）
- A：“好，断开吧！”（ACK报文）
（B收到后立刻断开并释放资源，而A还要再等一会，万一这条消息丢失了，B还会再催促。等够一段时间，A就默认B已经收到确认消息了，因而也断开链接，释放资源）
相关阅读：
计算机网络——TCP三次握手详解为何两次不行
TCP链接的三次握手四次挥手——类比异地恋情侣开始交往和分手（通俗易懂）资源