TCP的三次握手四次挥手

三次握手：

所谓三次握手(Three-wayHandshake)，是指建立一个TCP连接时，需要客户端和服务器总共发送3个包。

TCP三次握手是建立TCP连接的过程，通过客户端和服务器之间发送特定的数据包来确认双方的接收能力和发送能力是否正常，从而确保连接建立成功。以下是TCP三次握手的详细过程：

1. 第一次握手：

   刚开始客户端处于 closed 的状态，服务端处于 listen 状态。

   然后客户端向服务器发送一个 SYN 报文，并指明客户端的初始化序列号 ISN，客户端自己进入 SYN-SENT 状态，等待服务端确认。

2. 第二次握手：

   服务器收到客户端的 SYN 报文后，向客户端回复一个 SYN 报文（组合数据包），表示自己已经收到了客户端的 SYN 报文。此时，服务器进入SYN-RECV状态。

   组合数据包 ： 服务器自己的SYN报文（自己的初始化序列号 ISN） + ACK 报文（客户端的 ISN + 1 作为ACK 的值）

   其中，SYN报文用于请求建立连接，ACK报文用于确认已收到客户端的SYN报文（对应客户端发来的SYN）。

3. 第三次握手：

   客户端收到 SYN 报文，再次向服务器发送一个 ACK 报文，表示已经收到了服务端的 SYN 报文，客户端变成了ESTABLISHED状态；

   服务端收到ACK之后，也变成了ESTABLISHED状态，此时，双方已建立起了连接。

此时完成三次握手，TCP连接已经建立成功。随后客户端和服务端就可以进行数据传输。

简单来讲：

1. 客户端CLOSED状态、服务端 LISTEN 状态
2. 客户端向服务器发送一个SYN报文，并进入SYN-SENT 状态（第一次握手）
3. 服务端接收到SYN报文后，向客户端回复一个SYN+ACK的组合数据包，并进入SYN-RECV 状态（第二次握手）
4. 客户端接收到SYN+ACK的组合数据包后，向服务器再次发送一个ACK报文，并进入ESTABLISHED 状态（第三次握手）
5. 服务端收到ACK报文后也变成了ESTABLISHED状态

为什么是三次而不是两次、四次？

三次握手是确定客户端和服务端接收和发送能力都正常(HTTP)的最优次数：

第一次握手：客户端发送网络包，服务端收到了。这样服务端就能得出结论：客户端的发送能力、服务端的接收能力是正常的。

第二次握手：服务端发包，客户端收到了。这样客户端就能得出结论：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。

第三次握手：客户端发包，服务端收到了。这样服务端就能得出结论：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。

• 为什么不是两次？

  根本原因: 无法确认客户端的接收能力。

  如果是两次，你现在发了 SYN 报文想握手，但是这个包滞留在了当前的网络中迟迟没有到达，TCP 以为这是丢了包，于是重传，两次握手建立好了连接。

  看似没有问题，但是连接关闭后，如果这个滞留在网路中的包到达了服务端呢？这时候由于是两次握手，服务端只要接收到然后发送相应的数据包，就默认建立连接，但是现在客户端已经断开了，这就带来了连接资源的浪费。

• 为什么不是四次？

  三次握手的目的是确认双方发送和接收的能力，那四次握手可以嘛？

  当然可以，100 次都可以。但为了解决问题，三次就足够了，再多用处就不大了。

.

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

例如，客户端发送了一个连接请求报文段，但因某些原因在网络中滞留了一段时间，然后到达了服务端。

在两端完成三次握手，并建立了连接之后，这个早已失效的连接请求报文段才到达了服务端。此时服务端会误认为客户端又发起了一个新的连接请求，于是向客户端发出确认报文段，同意建立连接。如果不采用三次握手，那么只要服务端发出确认，新的连接就建立了。

由于现在客户端并没有发出建立连接的请求，因此不会理睬服务端的确认，也不会向服务端发送数据。但服务端却认为新的连接已经建立，并一直等待客户端发来数据。这样，服务端就一直处于等待的状态，造成资源浪费。

四次挥手：

TCP四次挥手是连接的终止过程，也称为TCP四次分手或TCP四次断开。
是用于释放已建立的TCP连接的一种机制。
当数据传输完毕，双方都可释放连接。这个过程需要四个步骤，因此通常被称为“四次挥手”。

1. 第一次挥手：

   起初两端都处于 ESTABLISHED 状态

   客户端向服务器发送 FIN 报文，用来关闭客户端到服务器的数据传送，客户端进入FIN-WAIT-1状态，等待服务端的确认。

   这时候客户端同时也变成了 half-close (半关闭)状态，即无法向服务端发送报文，只能接收。

2. 第二次挥手：

   服务端收到FIN报文后，向客户端发送一个ACK，服务端进入 CLOSED-WAIT（关闭等待） 状态。

   此时TCP连接处于半关闭状态，即客户端已经没有要发送的数据了，但服务器若发送数据，则客户端仍要接受。这个状态还要持续一段时间，也就是整个CLOSE_WAIT状态持续的时间。

   客户端收到服务端的ACK后，进入 FIN-WAIT-2 状态，等待服务端发出的连接释放报文段。

3. 第三次挥手：

   服务端向客户端发送FIN，服务端进入LAST-ACK（最后确认）状态，等待客户端的确认。

4. 第四次挥手：

   客户端收到FIN报文后，进入 TIME-WAIT（时间等待）状态，然后向服务端发送一个ACK报文。

   服务端确认后进入CLOSED 状态，客户端完成第四次挥手

   此时 TCP 未释放掉，客户端会进入TIME_WAIT状态，等待2MSL（最长报文段寿命）的时间后才会进入CLOSED状态。
   这是为了防止已失效的连接请求报文段突然又传送到了服务端，从而产生错误。

简单来讲：

1. 客户端 ESTABLISHED 状态、服务端 ESTABLISHED 状态
2. 客户端向服务端发送 FIN 报文，客户端进入 FIN-WAIT-1 状态（第一次挥手）
3. 服务端收到FIN报文后，向客户端发送一个ACK报文，服务端进入 CLOSED-WAIT 状态（第二次挥手）
4. 客户端收到ACK报文后，进入 FIN-WAIT-2 状态
5. 服务端向客户端发送FIN报文，服务端进入 LAST-ACK 状态（第三次挥手）
6. 客户端收到FIN报文后，进入 TIME-WAIT 状态，然后向服务端发送一个ACK报文
7. 服务端收到ACK报文后，服务端进入CLOSED 状态（第四次挥手）
8. 客户端会进入 TIME_WAIT 状态，等待2MSL（最长报文段寿命）的时间后才会进入CLOSED状态

为什么是四次挥手而不是三次？

因为服务端在接收到FIN, 往往不会立即返回FIN, 必须等到服务端所有的报文都发送完毕了，才能发FIN。
因此先发一个ACK表示已经收到客户端的FIN，延迟一段时间才发FIN。这就造成了四次挥手。

如果是三次挥手会有什么问题？

等于说服务端将ACK和FIN的发送合并为一次挥手，这个时候长时间的延迟可能会导致客户端误以为FIN没有到达客户端，从而让客户端不断的重发FIN。

状态含义

• LISTEN - 侦听来自远方TCP端口的连接请求；

• SYN-SENT - 在发送连接请求后等待匹配的连接请求；

• SYN-RECEIVED - 在收到和发送一个连接请求后等待对连接请求的确认；

• ESTABLISHED - 代表一个打开的连接，数据可以传送给用户；

• FIN-WAIT-1 - 等待远程TCP的连接中断请求，或先前的连接中断请求的确认；

• FIN-WAIT-2 - 从远程TCP等待连接中断请求；

• CLOSE-WAIT - 等待从本地用户发来的连接中断请求；

• CLOSING - 等待远程TCP对连接中断的确认；

• LAST-ACK - 等待原来发向远程TCP的连接中断请求的确认；

• TIME-WAIT - 等待足够的时间以确保远程TCP接收到连接中断请求的确认；

• CLOSED - 没有任何连接状态；