TCP 三次握手和四次挥手

首先 TCP 传输数据过程大致如下。在传输数据之前，就需要经历三次握手。断开数据需要经历四次挥手。

图片截自：https://www.cnblogs.com/brady-wang/p/9768040.html

三次握手

在建立一个 TCP 连接时，需要客户端和服务器总共发送3个报文。过程如下

图片截自：https://juejin.cn/post/7356434494511890468

1.客户端向服务端发送信息，服务端收到。服务端确认客户端发送正常，服务端接收正常

2.服务端向客户端发送信息，客户端收到。客户端确认客户端发送正常，接收正常；服务端接收正常，发送正常。

3.客户端向服务端发送消息，服务端收到。服务端确认客户端接受正常，服务端发送正常。

为什么需要三次握手，而不是二次握手？

三次握手的目的是为了防止已失效的连接请求突然又传送到了服务端，而产生错误。

假设采用两次握手建立连接，客户端第一次向服务端发送建立连接请求，因为网络延迟的原因，一直没有到达服务器。于是客户端再次向服务端重新发送建立连接请求，这次服务端收到连接请求后，向客户端回复确认，建立连接。但是这时网络延迟恢复，服务端又收到客户端第一次发送的连接请求，服务端认为客户端又发起了一次连接，再次回复确认，又建立了一个连接。

服务端认为有两个连接，客户端认为有一个连接，造成数据状态不一致。

至于为什么不像断开连接一样采用四次握手，因为服务端把确认连接请求和向客户端发送的建立连接请求合并成一次请求，发送给客户端了。

四次挥手

四次挥手是指断开一个 TCP 连接时，需要客户端和服务端总共发送4个报文以确认连接的断开。过程如下：

图片截自：https://juejin.cn/post/7356434494511890468

第一次挥手（发送FIN）：客户端向服务端发送FIN，表示没有数据再发送，需要关闭连接时，它会发送一个FIN（结束）报文段，进入FIN_WAIT_1 状态（无论是客户端还是服务端，任何一方都可以主动发起关闭连接的请求）

第二次挥手（发送ACK）：服务端收到FIN报文段后，发送一个ACK报文段作为回应，同意客户端的断开连接的请求，并进入CLOSE-WAIT状态。客户端收到ACK后，进入FIN-WAIT-2状态。这时候已经断开了客户端与服务端的连接，服务端依然可以继续向客户端发送数据。

第三次挥手（发送FIN）：服务器端完成数据传输后，发送一个FIN报文段，请求关闭连接，进入LAST-ACK状态。

第四次挥手（发送ACK）：客户端收到服务器的 FIN 包后，发送ACK报文段作为回应，并进入TIME-WAIT状态。服务器端收到客户端的确认包 ACK 后进入CLOSED 状态，连接被最终关闭。经过 2MSL 但服务端没回应后，客户端才进入 CLOSED 状态。

为什么需要四次挥手？

由于TCP连接是全双工的，即数据可以在两个方向上流动，因此每个方向都必须要单独进行关闭，关闭一个方向上的连接需要一次请求和一次确认，最终需要四次请求。

为什么不能是三次，不能像建立连接那样把第二次和第三次合并成一次？

因为在第二次请求时服务端向客户端发送确认关闭连接，此时服务端可能还有一些数据没有传输完成，需要继续向客户端发送数据，不能跟合并服务器向客户端发送的关闭连接请求，所以需要拆分成两个连接请求。

Start by checking the repository's existing note structure to determine where this TCP article belongs. Use the issue body as the proposed content, preserve the referenced diagrams and sources, and consider the work done when the three-way handshake and four-way termination explanation is published consistently with the surrounding notes.