前言：
TCP 的 3 次握手 4 次挥手是一个非常经典的问题，相信各位从事 Java 的朋友在职业生涯中没少被问到这个问题，本篇我们就展开分析一下 TCP 为什么是 3 次握手 4 次挥手。
TCP 协议
要搞清楚 TCP 为什么是 3 次握手 4 次挥手我们需要先搞清楚 TCP 协议，TCP（Transport Control Protocol）是一个传输层协议，提供 Host-To-Host（从一台主机发送数据给另外一台主机） 数据的可靠传输，支持全双工，是一个连接导向的协议。
TCP/IP 协议
我们上面提到了 TCP 协议提供 Host-To-Host 的数据可靠传输，也就是主机到主机的数据可靠传输，也可以说是从一台设备到另外一台设备，因为不仅仅是主机还有手机、平板等，所以说 TCP 是设备到设备之间的通讯协议，而设备是应用的载体，设备上安装了应用，例如微信、微博、百度等应用，因此 TCP 的上层是应用，而应用间有对应的传输协议，但应用需要依赖设备，因此需要用到设备的 TCP 协议，需要告诉 TCP 使用的是哪个应用，也就是对应的端口号。
TCP 要实现设备到设备的通讯，就需要知道设备的网络 IP 地址，但 TCP 协议不负责网络 IP 地址之间的数据传输，TCP 把网络地址之间的数据传输交给底层的网络层处理，网络层之间的通讯协议就是 IP 协议，网络层解决了解决了数据在两个网络 IP 地址之间的传输，但是网络层不处理数据在设备之间的传递，因此又有了数据链路层和物理层。
以上就是 TCP/IP 协议的 5 层模型。
TCP 协议的 3 次握手和 4 次挥手
TCP 协议的 3 次握手示意图如下：
我们来分析三次握手的过程，如下：
- 第一次握手：客户端发送 SYN（Synchronization）信号给服务端，请求建立连接。
- 第二次握手：服务端收到客户端的 SYN 信号后，响应客户端，同时服务端也发送一个 SYN 信号给客户端，这一步也叫 SYN-AKC（同步和确认），表示服务端准备好了并且也想和客户端建立连接。
- 第三次握手：客户端收到服务端的 SYN 后，给服务端发送一个 ACK，表示自己也准备好了。
以上就是三次握手的过程。
为啥是 3 次握手？2 次握手可以吗？
我们从 3 次握手的作用来分析为什么需要三次握手，如下：
- 第一次握手：客户端发送 SYN 到服务端，这可以证明客户端的发送能力是正常的。
- 第二次握手：服务端发送 SYN 和 ACK 到客户端，到此时就可以证明客户端的发送能力、服务端的接受能力和发送能力是正常的。
- 第三次握手：客户端响应 ACK 到服务端，证明客户端端的接受能力是正常的。
- 我们发现只有经过三次握手，才可以证明客户端和服务端的发送接受能力都正常，只有客户端和服务端的发送接受能力都正常，才可以进行数据的可靠性传输。
假设只有两次握手会有什么情况？
如果只有两次握手，服务端无法确定客户端是否已经收到自己发送的报文，如果第二次握手报文丢失，那么客户端就无法知道服务端的初始序列号，那么 TCP 的可靠性就无从谈起了。
TCP 协议的 4 次挥手示意图如下：
我们来分析 4 次挥手的过程，如下：
- 第一次挥手：客户端要求断开连接，发送一个断开的请求（FIN）。
- 第二次挥手：服务端收到请求后，给客户端一个 ACK 信号，表示自己收到了客户端的断开信号。
- 第三次挥手：服务端给客户端一个 FIN 信号，告诉客户端可以断开了。
- 第四次挥手：客户端收到了服务端的 FIN 信号，再给服务端一个 ACK 信号。
以上就是四次挥手的全过程。
为啥需要四次挥手？可以三次挥手吗？
前面我们提到 TCP 协议是全双工的，客户端要求断开发送 FIN 后，服务端还可以向客户端发送数据，服务端收到客户端的 FIN 请求后，可能还有一些数据需要处理响应，因此不能马上向客户端响应 FIN，只能向客户端发送一个 ACK，等服务端把剩余的数据处理完成之后，再向客户端发送一个 FIN 信号，服务端需要知道客户端是否收到了自己发送的 FIN 信号，因此还需要客户端向服务端发送一个 ACK 信号。
总结：本篇简单分享了 TCP 协议的 3 次握手 4 次挥手，并从协议交互的层面上分析了为什么是 3 次握手 4 次挥手，希望可以帮助到有需要的小伙伴。
如有不正确的地方欢迎各位指出纠正。
