TCP的“三次握手”与“四次挥手”

---

背景：

TCP是面向连接的，TCP通过 “三次握手” 建立连接，通过 “四次挥手” 断开连接。

什么是连接？
eg.结婚,不论办了婚礼还是干嘛，只有有了结婚证（一式两份）才算结婚。

客户端A，服务器B。
建立连接：双方各自需要一个空间存储对方信息（比如ip和端口），当双方都维护好后我们就称A和B建立连接了。
断开连接：清除这个空间。

---

三次握手：

此处每一次通信称为一次“握手”，中间两次合并为一次。
即三次握手本质是“四次”交互，通信双方需要各自向对方发送一次“建立连接”请求，同时对方再回一个ACK。

中间两次能不能不合并？
否，因为封装分用两次的成本比一次高

可以只有两次握手吗？
否，TCP通信双方是全双工的，需要验证双方发送和接收功能是否正常，如果是 2 次握手，不能证明服务器端的发送能力和客户端的接收能力。

小细节：第三次握手即客户端发给服务器 ACK报文 可以携带客户端和服务器交互的数据。

“三次握手”意义：
1.验证通信双方接收和发送能力是否正常
2.握手过程中，双方协商一些重要参数（通信过程中有些数据需要双方同步，此时就可利用“三次握手”来完成数据的同步）

---

四次挥手:

和三次握手类似，通信双方各自向对方发一个断开连接的请求，各自回应。

注： 中间两次通常不能合并，特殊情况下可以合并。

---

为什么三次握手中间两次可以合并而四次挥手不能？

三次握手的交互过程是纯内核完成的，服务器系统内核收到SYN会立刻发送ACK和SYN，因此中间两次发送时间间隔很短，可以合并。

四次挥手中 FIN 的发起不是由内核控制的，而是由应用程序，比如调用socket 的 close 方法或者 进程退出等才会触发 FIN，ACK是由内核控制的，当服务器内核收到 FIN 会立刻返回 ACK ，而服务器要发送 FIN 需要应用程序执行到 close 方法/进程退出才会触发。两次发送间隔时间长系统就不会将其合并，具体间隔时间长短要看代码如何写的。

---

建立连接中的状态（LISTEN，ESTABLISHED）

• 起初，客户端和服务器都处于处于 CLOSED 状态，之后服务器被进程打开，服务器进入 LISTEN 监听状态
• 客户端请求建立连接，发送 SYN 报文，客户端进入SYN-SENT 状态
• 服务器收到 SYN 报文，发送 SYN+ACK 报文，服务器进入 SYN-RCVD 状态
• 客户端收到 SYN+ACK 报文，发送 ACK 报文，客户端进入ESTABLISHED 状态
• 服务器收到 ACK报文，进入 ESTABLISHED 状态。
  
  SYN：把SYN字段为1的报文称为同步报文段
  FIN：把FIN字段为1的报文称为结束报文段
  ACK：把ACK字段为1的报文称为应答报文段

---

断开连接中的状态（CLOSE_WAIT，TIME_WAIT ）

注：与建立连接时不同，建立连接只能由客户端率先发起，而断开连接服务器和客户端都能主动发起。下面以主动发起 FIN 方称作 A，另一方称作 B。

• A发送 FIN 报文，A进入 FIN_WAIT_1 状态
• B收到 FIN 报文，发送ACK报文，B进入 CLOSE_WAIT 状态
• A收到 ACK 报文，A进入 FIN_WAIT_2 状态
• B发送 FIN 报文，B进入 LAST_ACK 状态
• A收到 FIN 报文，发送ACK报文，A进入 TIME_WAIT 状态，等待2MSL，A进入CLOSED 状态
• B收到 ACK 报文，B进入 CLOSED 状态

MSL：指的是互联网上两个节点传输数据消耗的最大时间

---

TIME_WAIT 的意义

站在A的角度，进入 TIME_WAIT 状态时4个步骤已经完成，正常情况下没A的事情了，可是如果A发给B的 ACK 报文出现了丢包，A就又有活儿了，因为站在B角度，B在久久没收到 ACK 时，会以为自己发的 FIN 丢包了，会重新发送 FIN 报文，此时A还得发送 ACK 报文。这个状态就是处理这种情况的一个保障。如果2MSL内A没收到B的 FIN 报文，默认B已经收到ACK报文。

当然，如果说B给A发的 FIN 和 A给B发的 ACK 能一直丢，只能说这网络太拉了，自认倒霉，抓紧换网~~

---