45 lines
3.1 KiB
Markdown
45 lines
3.1 KiB
Markdown
## 三次握手的具体流程
|
||
|
||
|
||
TCP三次握手的流程如下：
|
||
|
||
1. **第一次握手**
|
||
客户端发送SYN（同步序列号）报文（SYN=1，seq=x）到服务器，请求建立连接，并进入`SYN_SENT`状态。
|
||
|
||
2. **第二次握手**
|
||
服务器收到SYN报文后，回复SYN+ACK报文（SYN=1，ACK=1，seq=y，ack=x+1），确认客户端的请求，并进入`SYN_RCVD`状态。
|
||
|
||
3. **第三次握手**
|
||
客户端收到SYN+ACK后，发送ACK报文（ACK=1，seq=x+1，ack=y+1）给服务器，双方进入`ESTABLISHED`状态，连接建立完成。
|
||
|
||
**核心作用**：通过三次交互，双方同步初始序列号（ISN）并验证双向通信能力，确保数据可靠传输。
|
||
|
||
|
||
|
||
|
||
## TCP为什么要三次握手 两次不行吗 四次不行吗
|
||
TCP 三次握手的设计是为了在可靠性和效率之间取得平衡。以下详细解释为什么两次握手不行，四次握手也没必要：
|
||
|
||
### 1. **为什么两次握手不行？**
|
||
两次握手无法确保双方的通信能力都被验证，可能导致历史连接或无效连接的问题：
|
||
- **无法防止历史连接的建立**：如果只有两次握手，客户端发送 SYN 请求后，服务器直接返回 ACK 确认并进入连接状态。但如果这个 SYN 是一个延迟的历史请求，客户端可能已经不再需要这个连接，导致服务器浪费资源。
|
||
- **无法可靠同步双方序列号**：TCP 需要通过握手过程同步双方的初始序列号（ISN）。两次握手只能保证一方的序列号被确认，而另一方的序列号可能未被正确接收和确认，这会影响数据传输的可靠性。
|
||
|
||
### 2. **为什么四次握手没必要？**
|
||
四次握手虽然也能完成连接建立，但它是冗余的：
|
||
- 在 TCP 握手过程中，服务器收到客户端的 SYN 请求后，会同时发送自己的 SYN 和对客户端 SYN 的 ACK 确认。这两个动作可以合并为一次操作（SYN+ACK），从而将四次握手优化为三次握手。
|
||
- 四次握手增加了不必要的网络开销，降低了连接建立的效率。
|
||
|
||
### 3. **三次握手的优点**
|
||
三次握手是理论上最少且最高效的连接建立方式，能够满足以下需求：
|
||
- **双向通信能力验证**：通过三次握手，客户端和服务端都能确认对方的发送和接收能力正常。
|
||
- **序列号同步**：三次握手确保双方的初始序列号（ISN）都被正确接收和确认，从而支持后续可靠的数据传输。
|
||
- **避免无效连接**：第三次握手（客户端发送 ACK）可以确保客户端也认可了连接的建立，避免了因历史请求或网络异常导致的无效连接。
|
||
|
||
### 总结
|
||
- **两次握手不可靠**：无法验证双方的通信能力和同步序列号，可能导致资源浪费和数据传输问题。
|
||
- **四次握手不高效**：可以通过优化将 SYN 和 ACK 合并，减少一次交互。
|
||
- **三次握手最佳**：既能保证可靠性，又能提高效率，是最优的设计选择。
|
||
|
||
# 嫑（biao）
|
||
嬲 |