网络协议和Netty（6）：大白话说四次挥手和用一个数据库关闭连接的例子进行说明

本文主要是介绍网络协议和Netty（6）：大白话说四次挥手和用一个数据库关闭连接的例子进行说明，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

前言：和三次挥手不一样，第一次接触四次挥手的概念的时候，已经有些懵懂，没有再闹出笑话。毕竟经历了“高规格的礼仪”洗礼，有了些警惕性，哈哈。好了不废话了，言归正传。前面说完建立连接时所需要的三次握手的前因后果，这次来说一说，关闭连接时的四次挥手。

提问：

什么是四次挥手？

为什么关闭连接时需要四次挥手？

为什么需要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次。