前言：和三次挥手不一样，第一次接触四次挥手的概念的时候，已经有些懵懂，没有再闹出笑话。毕竟经历了“高规格的礼仪”洗礼，有了些警惕性，哈哈。好了不废话了，言归正传。前面说完建立连接时所需要的三次握手的前因后果，这次来说一说，关闭连接时的四次挥手。
?
提问：
什么是四次挥手？
为什么关闭连接时需要四次挥手？
为什么需要TIME_WAIT状态？
拓展：
为什么有时候通过抓包工具查看TCP连接时，发现有时候没有四个数据包？
四次挥手介绍：
概述：
四次挥手就是TCP关闭时，客户端和服务端共发送四次数据包来确认连接的断开。这个发起端即可以是服务端也可以是客户端，调用close方法，发送关闭请求。
第一次挥手
图示
第一次挥手时，客户端应用调用close（）方法（注意：这里的close方法，使用TCP提供的具体的实现），向服务端发送FIN（FIN=1）数据包，FIN数据包含有序列值Seq=n。客户端发送FIN数据包后，将自身状态置为FIN_WAIT_1（终止状态1）。
注意：FIN报文的作用是告诉服务端，我将不会主动发起请求。
第二次挥手
图示
第二次挥手
服务端接收到FIN报文，执行passive close(被动关闭) 并将自身状态置为CLOSE_WAIT（半关闭状态）。将序列Seq加1（Ack=n+1），调用read（），向客户端发送ACK返回报文（ACK=1）。
客户端接收到ACK报文，对序列进行校验，无误后，将自身状态置为FIN_WAIT2（终止状态2）。
注意：一旦服务端的TCP发现接收到的报文是FIN报文后，就进入到半关闭状态，将不再接收来自客户端的请求报文。但是服务端依然可以发送请求，客户端也会接收。这个CLOSE_WAIT状态会持续存在一段时间，直到服务端调用close方法。
第三次挥手
图示：
服务端经过一段时间后，会调用close（）方法，向客户端发送FIN报文（FIN=1），同样的FIN报文中包含服务端的一个Seq，然后将自身状态置为LAST_ACK（最终应答）。
第四次挥手
图示：
客户端 TCP确认FIN报文后发出应答确认 ACK 报文，并进入了 TIME_WAIT（时间等待）状态。注意此时 TCP 连接还没有释放，必须经过 2?MSL的时间后，当主动关闭端撤销相应的 TCB 后，才进入 CLOSED 状态。
服务端只要收到了客户端发出的确认，立即进入 CLOSED 状态。同样，撤销 TCB后，就结束了这次的 TCP 连接。可以看到，被动关闭端结束 TCP 连接的时间要比主动关闭端早一些。
关于MSL简单了解下就好: max segement lifetime（最长报文段寿命/最长分节生命期），MSL 是任何 IP数据报能够在因特网中存活的最长时间，任何 TCP 实现都必须为 MSL 选择一个值。RFC1122[Braden 1989]的建议值是 2 分钟，不过源自 Berkelcy 的实现传统上改用 30 秒这个值。这意味着 TIME_WAIT 状态的持续时间在 1 分钟到 4 分钟之间。
总结：TCP断开连接，一共进行四次数据包交互。主动关闭端和被动关闭端都需要向对端发送FIN报文，和接收ACK报文。
提问：为什么TCP断开连接需要四次挥手？
解答：首先我们要知道TCP是一个全双工（客户端和服务端）的连接，只有两端都关闭连接才算真正的关闭。而两边都需要通过FIN报文告诉对方，己方将不会再主动发送请求，等待接收到ACK确认，TCP再进行关闭连接。
加深理解：我们要明确一个思路，当一端先主动发起关闭请求时，只意味着，己方不会再向对方主动发送请求。而对方什么时候不发送主动发送请求，要由对方决定。这就要求对方也需要发送FIN请求。这就要求关闭连接需要四次。
举一个例子：
NO1：
假如你和你女朋友晚上聊天，你想睡觉（或者想玩游戏），然后你会说：“太晚了，我想睡觉。”
NO2：
你老婆正兴奋着聊一个话题，停不下，“我还没说完，你闭嘴，听我说就行了”。
我就想问，你能让她不说，你敢？你能管住自己不说话，但你能管住她？
NO3
一段时间后，你老婆终于说完了，“伦家说累了，要觉觉了。”
NO4
你回复一个ACK：“辛苦”。
此时聊天结束。
提问：为什么需要一个TIME_WAIT状态？
解答：
1.保证可靠的终止连接
我们有没有想过，最后一次挥手如果数据包丢失怎么办？网络上出现丢包是很正常的，如果在最后一次挥手发生丢包现象，那么接收端一直等待，TCP就不会关闭连接。这时候就需要发送端有个TIME_WAIT状态，他会经过一系列处理，发现ACK数据包丢失，然后会再应答一个ACK报文。这样就保证了终止连接的可靠性。
2.保证让迟来的 TCP 报文有足够的时间被识别并丢弃
在 Linux 系统上，一个 TCP 端口不能被同时打开多次，当一个 TCP 连接处于 TIME_WAIT 状态时，我们无法使用该链接的端口来建立一个新连接。反过来思考，如果不存在 TIME_WAIT 状态，则应用程序能过立即建立一个和刚关闭的连接相似的连接（这里的相似，是指他们具有相同的 IP 地址和端口号）。这个新的、和原来相似的连接被称为原来连接的化身。新的化身可能受到属于原来连接携带应用程序数据的 TCP 报文段（迟到的报文段），这显然是不该发生的。这是TIME_WAIT 状态存在的第二个原因。
拓展提问：为什么有时候通过抓包工具查看TCP连接时，发现有时候没有四个数据包？
首先我们知道，我们第一次发起关闭连接请求时，可能正好有个发送请求，此时FIN数据包可能会携带在报文中。所以TCP断开连接就可能只需要三次挥手。
我们知道第三次挥手，需要等待时间，这个等待就是可能被动关闭端仍然有请求发送。那假如没有呢？第二次和第三次就会合并。
总结：实际上我们的TCP连接关闭可能有2次、3次、4次。
关闭一个数据库连接
准备：wireshark（抓包工具），navicat（数据库可视化工具），mysql
说明：mysql的连接是一个TCP连接
1.准备一个已经建立连接的数据库连接
2.用wireshark捕捉一个3306端口
3.准备
这样就可以捕捉3306端口的数据包了
4.关闭数据库连接
7.简单看下
8.我们看后面四个数据包
我们看到，已经抓到了6个数据包，仔细看后面四个数据包是不是对应着FIN、ACK、FIN、ACK四个数据包，和TCP的四次挥手是不是特别相似。
9.第一次挥手
黄色框框是端口为59260向端口为3306端口发送FIN数据包，此时序列值Seq=6。
10.第二次挥手
红色框框是端口3306向端口59260返回ACK数据包，序列值Ack=7。正好是FIN报文Seq的6再加上1，Ack=Seq+1；
11.第三次挥手
此时端口3306向59260发送一个FIN数据包，序列值，Seq=1。
12.第四次挥手
? ? ??
?端口59260向端口3306返回ACK数据包，此时序列值Ack=2，对应着3306端口的序列值Seq为1再加1，Ack=Seq+1
四次握手结束，TCP连接断开。