三次握手

## 1 什么是三次握手

![](/media/202206/2022-06-13_204722_588546.png)

1. 假定**主机 $A$ 运行的是 TCP 客户程序**，而 $B$**运行 TCP 服务器程序**，**最初两端的 TCP 进程都处于 `CLOSED`**（关闭）**状态**，在本例中，$A$**主动打开连接**，而 $B$**被动打开连接**。
2. 一开始，$B$**的 TCP 服务器进程先创建传输控制块**（Transmission Control Block, TCB），**准备接受客户进程的连接请求**，**然后服务器进程就处于 `LISTEN`**（收听）**状态**，**等待客户的连接请求**，**如有**，**即做出响应**。
3. $A$**的 TCP 客户进程也是首先创建传输控制模块**，然后，**在打算建立 TCP 连接时**，**向 $B$ 发出连接请求报文段**，**这时首部中的同步位 $SYN = 1$**，**同时选择一个初始序号 $seq = x$**，TCP 规定，$SYN$**报文段**（即 $SYN = 1$ 的报文段）**不能携带数据**，但要**消耗掉一个序号**，这时，**TCP 客户进程进入 `SYN-SENT`**（同步已发送）**状态**。
4. $B$**收到连接请求报文段后**，**如同意建立连接**，**则向 $A$ 发送确认**，**在确认报文段中应把 $SYN$ 和 $ACK$ 位都置 1**，**确认号是 $ack = x + 1$**，**同时也为自己选择一个初始序号 $seq = y$**，需要注意的是，**这个报文段也不能携带数据**，但同样**要消耗掉一个序号**，**这时 $TCP$ 服务器进程进入 `SYN-RCVD`**（同步收到）**状态**。
5. **TCP 客户进程收到 $B$ 的确认后**，**还要向 $B$ 给出确认**，**确认报文段的 $ACK$ 置 1**，**确认号 $ack = y + 1$**，**而自己的序号 $seq = x + 1$**，TCP 的标准规定，**ACK 报文段可以携带数据**，**但如果不携带数据则不消耗序号**，**在这种情况下**，**下一个数据报文段的序号仍是 $seq = x + 1$**，这时，**TCP 连接已经建立**，$A$**进入 `ESTABLISHED`**（已建立连接）**状态**。
6. **当 $B$ 收到 $A$ 的确认后**，**也进入 `ESTABLISHED` 状态**。
   > **传输控制块**（Transmission Control Block, TCB）**存储了每一个连接中的一些重要信息**，如**TCP连接表**、**指向发送和接收缓存的指针**、**指向重传队列的指针**、**当前的发送和接收序号**等。
   >

## 2 三次握手的必要性

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

## 3 TCP 连接可以两次握手吗

不可以，主要有两个原因：

1. **可能会出现已失效的连接请求报文段又传到了服务器端。**
   1. 正常情况下 $A$**发出连接请求**，但**因连接请求报文丢失而未收到确认**，于是 $A$ 再**重传一次连接请求**，后来**收到了确认**，**建立了连接**，**数据传输完毕后**，就**释放了连接**，$A$ 共**发送了两个连接请求报文段**，其中**第一个丢失**，**第二个到达了 $B$**，**没有**「**已失效的连接请求报文段**」。
   2. 现假定出现一种异常情况，即 $A$**发出的第一个连接请求报文段并没有丢失**，**而是在某些网络节点长时间滞留了**，以致**延误到连接释放以后的某个时间才到达 $B$**，这本来是一个早已失效的报文段，但 $B$**收到此失效的连接请求报文段后**，就**误认为是 $A$ 又发出一次新的连接请求**，于是就**向 $A$ 发出确认报文段**，**同意建立连接**，假定**不采用报文握手**，那么**只要 $B$ 发出确认**，**新的连接就建立了**。
   3. 由于现在 $A$**并没有发出建立连接的请求**，因此**不会理睬 $B$ 的确认**，**也不会向 $B$ 发送数据**，但 $B$**却以为新的传输连接已经建立了**，并**一直等待 $A$ 发来数据**，$B$**的许多资源就这样白白浪费了**。
   4. 采用**三次握手**的办法，可以防止上述现象的发生，例如在上面的异常情况下，$A$**不会向 $B$ 的确认发出确认**，$B$**由于收不到确认**，**就知道 $A$ 并没有要求建立连接**。
2. **无法保证 `Client` 正确接收第二次握手的报文（`Server` 无法确认 `Client` 是否收到），也无法保证 `Client` 和 `Server` 之间成功互换初始序列号**。

## 4 可以采用四次握手吗

可以，但是会**降低传输的效率**。

1. 四次握手是指：**第二次握手 `Server` 只发送 `ACK` 和 `acknowledge number`**，而 `Server` **的 `SYN` 和初始序列号在第三次握手时发送**，**原来协议中的第三次握手变为第四次握手**。
2. 出于**优化的目的**，**四次握手中的二**、**三可以合并**。

## 5 第三次握手中，如果客户端的 ACK 未送达服务器，会怎样

* **Server 端：** 由于没有收到 `ACK` 确认，因此会**重发之前的 `SYN+ACK`**（**默认重发 5 次**，**之后自动关闭连接进入 `CLOSED` 状态**），`Client` **收到后会重新传 `ACK` 给 `Server`**。
* **Client 端：**
  1. **在 `Server` 进行超时重发的过程中**，**如果 `Client` 向服务器发送数据**，**数据头部的 `ACK` 是为 1 的**，所以**服务器收到数据之后会读取 `ACK Number`**，**进入 `ESTABLISHED` 状态**。
  2. **在 `Server` 进入 `CLOSED` 状态之后**，**如果 `Client` 向服务器发送数据**，**服务器会以 `RST` 包应答**。

## 6 如果已经建立了连接，但客户端出现了故障怎么办

1. **除时间等待计时器外**，**TCP 还设有一个保活计时器**（Keepalive Timer），**服务器每收到一次客户端的数据**，**服务器就发送一个探测报文段**，**以后则每隔 75 秒钟发送一次**，**若一连发送 10 个探测报文段后客户端仍没有响应**，**服务器就认为客户端出现了故障**，**接着就关闭这个连接**。

## 7 初始序列号是什么

1. `TCP` 连接的一方 `A`，**随机选择一个 32 为序列号**作为发送数据的初始序列号，比如为 1000，然后以该序列号为原点，对要传送的数据进行编号：1001、1002...。
2. 三次握手时，把这个序列号传送给另一方 `B`，以便在数据传输时，`B` 可以**确认什么样的数据编号是合法的**。
3. 同时在进行数据传输时，**`A` 还可以确认 `B` 收到的每一个字节**，如果 `A` 收到了 `B` 的确认编号是 2001，就说明编号为 1001-2000 的数据已经被 `B` 成功接受。

## 参考文献

1. [什么是三次握手 (three-way handshake)？](https://github.com/wolverinn/Waking-Up/blob/master/Computer%20Network.md#%E4%BB%80%E4%B9%88%E6%98%AF%E4%B8%89%E6%AC%A1%E6%8F%A1%E6%89%8B-three-way-handshake)。
2. [关于三次握手与四次挥手你要知道这些](https://mp.weixin.qq.com/s?__biz=MzUyNzgyNzAwNg==&mid=2247483765&idx=1&sn=70179fa0e28aacd42d4c15dbd08bc6fc)。