TCP握手三次，挥手四次，在面试这个锅里倒油，可以说是炸了几千次的老油条。
我们知道TCP是面向连接的。 三次握手是为了建立连接，四次挥手是为了切断连接。
第三次握手会先在上图中：
让我们来看看握手三次的过程：
最初，客户端和服务端都处于关闭状态。 客户端主动打开连接，服务端被动洗牌连接，退出封闭z状态，开始监听，进入侦听状态。一次握手
客户端随机初始化序列号(client_isn )，并将序列号置于TCP标头的“序列号”字段中。 此外，SYN标志的位置为1表示SYN消息。 然后将第一条SYN消息发送到服务器端，表示服务器端已开始连接，该消息不包含APP应用层数据，然后客户端处于同步状态。二次握手
服务端在从客户端接收到SYN消息后，首先服务端也随机初始化自己的序列号(server_isn )，将序列号填写在TCP报头的“序列号”字段中，然后在TCP报头中最后将该消息发送到客户端，该消息中也不包含APP应用层的数据，然后服务端处于SYN-RCVD状态。三次握手
客户端收到服务端消息后，也会在最后一条响应消息中响应服务端。 首先，该响应消息TCP的第一个ACK标志的位置为1，然后在“确认号码”字段中输入server_isn 1，最后向服务端发送消息。 此消息可以携带客户端到服务器的数据，然后客户端进入ESTABLISHED状态。 那么，经过3次握手过程，确认客户端和服务端之间的连接正常，接下来进入ESTABLISHED状态后，服务端和客户端就可以愉快地通信了。
这里有动态进程的图标。
这里有些细节，第三次握手可以传送数据。 这是面试中经常被问到的重点。
那么为什么要三次握手呢？两次不行吗？
为了防止服务器端打开不必要的连接并增加服务器开销，禁用的连接请求消息段会突然发送到服务器端，以防止发生错误。 由于网络传输存在延迟(通过网络光纤和各种中间代理服务器)，在传输过程中，例如客户端开始了SYN=1的第一次握手。
如果服务器端直接创建此连接，并将包含SYN、ACK、Seq等内容的包返回到客户端，则该包将因网络传输而丢失，丢失后客户端将不再接收服务器返回的包。
如果没有第三次握手，服务器端不知道服务器端的客户端是否收到了传输到服务器端的数据。 服务器端意识到此连接可用，端口保持打开，并且客户端超时重新发出请求后，服务器将重新打开端口连接。
这样会浪费很多无效的连接端口，浪费资源。
这个过程可以理解为
另一种情况是，来自失效客户端的请求消息由于某种原因转发到服务器端，在服务器端认为是客户端的有效请求而收到后发生错误。
确认这个过程需要“第三次握手”:
在第三次握手的数据中，客户端告知服务器是否收到了“第二次握手”时发送的数据，以及此连接的序列号是否有效。 如果发送的数据是“收到后没有问题”消息，则接收后服务器将成功建立TCP连接。 否则，TCP连接建立失败，服务器关闭连接端口。 这减少了服务开销和接收吊销请求时出现的错误。
要么挥手四次，要么先拍照：
集散结束时，TCP断开可能以四次挥手方式进行。
双方都可以主动断开连接，断开连接将释放主机中的“资源”。
上图显示客户端正在积极关闭连接。
一次挥手
客户端尝试关闭连接时，发送TCP报头中的FIN标志位设置为1的消息，即FIN消息，然后客户端进入FIN_WAIT_1状态。二次挥手
服务器接收到该消息后，向客户端发送ACK应答消息，接着服务器变为CLOSED_WAIT状态。三次挥手
客户端从服务端收到ACK回复消息后，进入FIN_WAIT_2状态。 等待服务端处理数据后，也会向客户端发送FIN消息，然后服务端进入LAST_ACK状态。四次挥手
客户端从服务端收到FIN消息后返回ACK回复消息，然后进入TIME_WAIT状态，服务收到ACK回复消息后进入CLOSED状态，这样服务端就完成了连接的关闭客户端在经过2MSL的时间后自动进入关闭状态，这样客户端也就完成了连接的关闭。 如您所见，所有方向都需要一个 FIN 和一个 ACK，因此通常为四
次挥手。为什么要挥手四次？
再来回顾下四次挥手双方发 FIN 包的过程，就能理解为什么需要四次了。
关闭连接时，客户端向服务端发送 FIN 时，仅仅表示客户端不再发送数据了但是还能接收数据。服务器收到客户端的 FIN 报文时，先回一个 ACK 应答报文，而服务端可能还有数据需要处理和发送，等服务端不再发送数据时，才发送 FIN 报文给客户端来表示同意现在关闭连接。从上面过程可知，服务端通常需要等待完成数据的发送和处理，所以服务端的 ACK 和 FIN 一般都会分开发送，从而比三次握手导致多了一次。
为什么客户端在TIME-WAIT阶段要等2MSL？
为的是确认服务器端是否收到客户端发出的 ACK 确认报文，当客户端发出最后的 ACK 确认报文时，并不能确定服务器端能够收到该段报文。
所以客户端在发送完 ACK 确认报文之后，会设置一个时长为 2MSL 的计时器。
MSL 指的是 Maximum Segment Lifetime：一段 TCP 报文在传输过程中的最大生命周期。
2MSL 即是服务器端发出为 FIN 报文和客户端发出的 ACK 确认报文所能保持有效的最大时长。
服务器端在 1MSL 内没有收到客户端发出的 ACK 确认报文，就会再次向客户端发出 FIN 报文：
如果客户端在 2MSL 内，再次收到了来自服务器端的 FIN 报文，说明服务器端由于各种原因没有接收到客户端发出的 ACK 确认报文。客户端再次向服务器端发出 ACK 确认报文，计时器重置，重新开始 2MSL 的计时。
否则客户端在 2MSL 内没有再次收到来自服务器端的 FIN 报文，说明服务器端正常接收了 ACK 确认报文，客户端可以进入 CLOSED 阶段，完成“四次挥手”。所以，客户端要经历时长为 2SML 的 TIME-WAIT 阶段;这也是为什么客户端比服务器端晚进入 CLOSED 阶段的原因。
这里同样有个动态过程的图示：
好了，我们的文章到这就……
唉，不对，就这么完了，这会我好像知道了，但过会儿那就说不定了。
没关系，我苦思冥想，找了两个大白话的例子，保准你忘不了。
大白话说三次握手在二十年前的农村，电话没有普及，手机就更不用说了，所以，通信基本靠吼。
zzdhb和radkj是邻居，这天zzdhb下地了，结果家里有事，热心的邻居radkj赶紧跑到村口，开始叫唤radkj。
radkj：zzdhb唉！我是radkj，你能听到吗？zzdhb一听，是radkj的声音：radkjradkj，我是zzdhb，我能听到，你能听到吗？radkj一听，嗯，没错，是zzdhb：zzdhb，我听到了，我有事要跟你说。“你老婆要生了，赶紧回家吧！”
zzdhb风风火火地赶回家，老婆顺利地生了个带把的舒服的草莓。
握手的故事充满了幸福和美满。
大白话说四次挥手假如博主有一个女朋友——只是“假如”，该死的，这不争气的眼泪，怎么止不住地滴在键盘上。
由于博主上班九九六，下班肝博客，导致没有时间陪女朋友，女朋友忍无可忍。
女朋友：臭男人，最近你都不理我，你是不是不爱我了？你是不是外面有别的狗子了？我要和你分手？沙雕博主一愣，怒火攻心：分手就分手，不陪你闹了，等我把东西收拾收拾。沙雕博主小心翼翼地装起了自己的青轴机械键盘。
哼，蠢女人，我已经收拾完了，我先滚为敬，再见！女朋友：滚，滚的远远的，越远越好，我一辈子都不想再见到你。唉，挥手的故事总充满了悲伤和遗憾！
好了，白话纯属娱乐！看在博主费了不少脑子的份上，点个赞再走呗！！
参考：
【1】：两张动图-彻底明白TCP的三次握手与四次挥手
【2】：35 张图解：被问千百遍的 TCP 三次握手和四次挥手面试题
【3】：三次握手+四次挥手，一文搞定所有！