TCP创建通信前的三次握手（为啥不是两次？）
1.三次握手的过程
- 客户端发送 SYN（同步）报文
- 客户端向服务器发送
SYN标志的数据包，请求建立连接，表示 "你好，我要连接你"。
- 客户端向服务器发送
- 服务器回复 SYN+ACK（同步+确认）报文
- 服务器收到
SYN后，确认收到请求并回复一个包含SYN和ACK标志的数据包，表示 "好的，我同意，建立连接吧，你确定吗？"
- 服务器收到
- 客户端发送 ACK（确认）报文
- 客户端收到服务器的
SYN+ACK后，回复一个ACK确认数据包，表示 "是的，我确定，连接已建立"。
- 客户端收到服务器的
2.为什么 TCP 不使用两次握手？（避免服务端和客户端的资源浪费）
如果采用 两次握手（假设的情景），一般包括以下两个步骤：
- 客户端发送 SYN（同步）请求：客户端向服务器发送
SYN报文，表示 "你好，我要连接你"。 - 服务器回复 SYN+ACK（同步+确认）响应：服务器收到客户端请求后，返回
SYN+ACK报文，表示 "好的，我同意，建立连接吧"。
- 假设客户端发送
SYN请求，但由于网络延迟，这个请求迟迟没有到达服务器，客户端在超时后放弃连接，并重新发送新的SYN请求。 - 旧的
SYN请求后来又因为网络问题到达服务器，如果是两次握手机制，服务器收到后直接建立连接，此时服务器会误以为客户端要建立连接，导致错误的连接建立（僵尸连接）。
两次握手的缺陷：
-
无法确认客户端是否收到了服务器的 SYN+ACK 响应
服务器会认为连接已建立，等待客户端发送数据，而客户端可能未收到SYN+ACK，导致连接不同步。 -
旧的连接请求可能引发问题
由于网络延迟或重复请求，可能会导致服务器误以为客户端要重新建立连接，导致资源占用（僵尸连接）。
因此，TCP 使用三次握手，在第二步后，客户端再发送一次 ACK 确认，确保双方都能正常通信，避免上述问题。