TCP的三次握⼿中为什么是三次？为什么不是两 次、四次？
TCP 三次握手（Three-way Handshake）是为了在不可靠的网络环境中建立可靠的、双向的连接。之所以选择三次握手，而不是两次或四次，是为了在效率和可靠性之间取得平衡。
三次握手的过程：
-
SYN (Client -> Server):
- 客户端选择一个初始序列号（client_isn，通常是随机生成的）。
- 客户端发送一个 SYN 报文段（SYN=1，seq=client_isn）到服务器。
- 客户端进入 SYN_SENT 状态。
-
SYN + ACK (Server -> Client):
- 服务器收到客户端的 SYN 报文段。
- 服务器选择自己的初始序列号（server_isn，通常是随机生成的）。
- 服务器发送一个 SYN+ACK 报文段（SYN=1, ACK=1, seq=server_isn, ack=client_isn+1）到客户端。
- SYN=1 表示这是一个 SYN 报文段。
- ACK=1 表示这是一个 ACK 报文段。
- seq=server_isn 表示服务器的初始序列号。
- ack=client_isn+1 表示服务器期望接收的下一个序列号（即客户端的初始序列号加 1）。
- 服务器进入 SYN_RCVD 状态。
-
ACK (Client -> Server):
- 客户端收到服务器的 SYN+ACK 报文段。
- 客户端发送一个 ACK 报文段（ACK=1, seq=client_isn+1, ack=server_isn+1）到服务器。
- ACK=1 表示这是一个 ACK 报文段。
- seq=client_isn+1 表示客户端的下一个序列号。
- ack=server_isn+1 表示客户端期望接收的下一个序列号（即服务器的初始序列号加 1）。
- 客户端进入 ESTABLISHED 状态。
- 服务器收到客户端的 ACK 报文段后，也进入 ESTABLISHED 状态。
为什么不是两次握手？
两次握手无法防止历史连接的建立，可能导致错误。
-
场景：
- 客户端发送 SYN 报文段（请求建立连接），但该报文段在网络中滞留了。
- 客户端超时重传 SYN 报文段，并成功与服务器建立了连接，完成了数据传输，然后关闭了连接。
- 滞留的 SYN 报文段最终到达了服务器。
- 服务器收到 SYN 报文段后，回复 SYN+ACK 报文段（如果只有两次握手，此时服务器认为连接已建立）。
- 客户端收到 SYN+ACK 报文段，但发现这是一个过期的连接请求，因此会忽略它（或者发送 RST 报文段重置连接）。
- 服务器不知道客户端已经丢弃了这个连接请求，会一直等待客户端发送数据，导致资源浪费。
-
问题： 两次握手无法让客户端确认服务器是否收到了它的 SYN 报文段，也无法让服务器知道客户端是否已经放弃了连接请求。
三次握手如何解决两次握手的问题：
- 在第三次握手中，客户端发送 ACK 报文段，确认收到了服务器的 SYN+ACK 报文段，并携带了正确的序列号。
- 服务器收到客户端的 ACK 报文段后，才能确认连接已建立。
- 如果服务器没有收到客户端的 ACK 报文段（例如，因为客户端已经放弃了连接请求），服务器会超时重传 SYN+ACK 报文段，或者最终放弃连接。
为什么不是四次握手？
理论上，四次握手也可以建立可靠的连接，但三次握手已经足够了，四次握手会增加不必要的开销。
-
四次握手的一种可能形式：
- Client -> Server: SYN
- Server -> Client: ACK (确认收到 SYN)
- Server -> Client: SYN
- Client -> Server: ACK (确认收到 SYN)
-
问题： 第二次和第三次握手可以合并为一次（SYN+ACK），因为它们都是由服务器发送的，并且都与服务器的初始序列号有关。
三次握手的本质：
- 同步序列号： 客户端和服务器需要交换彼此的初始序列号 (ISN)，以便进行可靠的数据传输。
- 确认收到： 双方都需要确认收到了对方的 SYN 报文段。
- 防止历史连接： 防止过期的连接请求被错误地建立。
总结：
- 两次握手无法防止历史连接的建立，可能导致错误。
- 三次握手是建立可靠连接所需的最小次数，它既能同步序列号，又能确认双方的接收能力，还能防止历史连接。
- 四次握手可以建立可靠连接，但没有必要，会增加开销。
三次握手是在可靠性和效率之间取得平衡的结果。它确保了连接的可靠建立，同时又避免了不必要的开销。