首先需要明确一个概念，TCP 连接是用于保证可靠性和流量控制维护的某些状态信息，这些信息的组合，包括 Socket、序列号和窗口大小称为连接。
因此，重要的是，为什么三次握手才可以初始化 Socket、序列号和窗口大小并建立 TCP 连接。
原因主要是以下三个方面：
- 三次握手才可以阻止重复历史连接的初始化（主要原因）
- 三次握手才可以同步双方的初始序列号
- 三次握手才可以避免资源浪费
原因一：避免历史连接
三次握手的首要原因是为了防止旧的重复连接初始化造成混乱。
【🌰栗子】
客户端先发送了
SYN (seq = 90)报文，然后客户端宕机了，而且这个 SYN
报文还被网络阻塞了，服务端并没有收到，接着客户端重启后，又重新向服务端建立连接，发送了
SYN (seq = 100) 报文（⚠️注意：不是重传 SYN，重传的 SYN
的序列号是一样的）。
客户端连续发送多次 SYN（都是同一个四元组）建立连接的报文，在网络拥堵情况下：
- 一个「旧 SYN 报文」比「最新的 SYN」
报文早到达了服务端，那么此时服务端就会回一个
SYN + ACK报文给客户端，此报文中的确认号是 91（90+1）； - 客户端收到后，发现自己期望收到的确认号应该是 100 + 1，而不是 90 + 1，于是就会回 RST 报文；
- 服务端收到 RST 报文后，就会释放连接；
- 后续最新的 SYN 抵达了服务端后，客户端与服务端就可以正常的完成三次握手了。
上述中的「旧 SYN 报文」称为历史连接，TCP 使用三次握手建立连接的最主要原因就是防止「历史连接」初始化了连接。
如果服务端在收到 RST 报文之前，先收到了「新 SYN 报文」，也就是服务端收到客户端报文的顺序是：「旧 SYN 报文」->「新 SYN 报文」，此时会发生什么？
当服务端第一次收到 SYN 报文，也就是收到 「旧 SYN 报文」时，就会回复
SYN + ACK报文给客户端，此报文中的确认号是 91（90+1）。然后这时再收到「新 SYN 报文」时，就会回 Challenge Ack 报文给客户端，这个 ack 报文并不是确认收到「新 SYN 报文」的，而是上一次的 ack 确认号，也就是91（90+1）。所以客户端收到此 ACK 报文时，发现自己期望收到的确认号应该是 101，而不是 91，于是就会回 RST 报文。
处于 Established 状态的服务端，如果收到了客户端的 SYN 报文（注意此时的 SYN 报文其实是乱序的，因为 SYN 报文的初始化序列号其实是一个随机数），会回复一个携带了正确序列号和确认号的 ACK 报文，这个 ACK 被称之为 Challenge ACK。接着，客户端收到这个 Challenge ACK，发现确认号（ack num）并不是自己期望收到的，于是就会回 RST 报文，服务端收到后，就会释放掉该连接。
如果是两次握手连接，就无法阻止历史连接，那为什么 TCP 两次握手为什么无法阻止历史连接呢？
主要是因为在两次握手的情况下，服务端没有中间状态给客户端来阻止历史连接，导致服务端可能建立一个历史连接，造成资源浪费。
在两次握手的情况下，服务端在收到 SYN 报文后，就进入
ESTABLISHED
状态，意味着这时可以给对方发送数据，但是客户端此时还没有进入
ESTABLISHED
状态，假设这次是历史连接，客户端判断到此次连接为历史连接，那么就会回 RST
报文来断开连接，而服务端在第一次握手的时候就进入
ESTABLISHED
状态，所以它可以发送数据的，但是它并不知道这个是历史连接，它只有在收到
RST 报文后，才会断开连接。
可以看到，如果采用两次握手建立 TCP 连接的场景下，服务端在向客户端发送数据前，并没有阻止掉历史连接，导致服务端建立了一个历史连接，又白白发送了数据，妥妥地浪费了服务端的资源。
要解决这种现象，最好就是在服务端发送数据前，也就是建立连接之前，要阻止掉历史连接，这样就不会造成资源浪费，而要实现这个功能，就需要三次握手。所以，TCP 使用三次握手建立连接的最主要原因是防止「历史连接」初始化了连接。
客户端发送三次握手（ACK 报文）后就可以发送数据了，而被动方此时还是
SYN_RCVD状态，如果 ack 丢了，那客户端发的数据是不是也白白浪费了？不是的，即使服务端还是在
SYN_RCVD状态，收到了客户端发送的数据，还是可以建立连接的，并且还可以正常收到这个数据包。这是因为数据报文中是有 ACK 标识位，也有确认号，这个确认号就是确认收到了第二次握手。
原因二：同步双方初始化序列号
TCP 协议的通信双方， 都必须维护一个「序列号」， 序列号是可靠传输的一个关键因素，它的作用：
- 接收方可以去除重复的数据；
- 接收方可以根据数据包的序列号按序接收；
- 可以标识发送出去的数据包中，哪些是已经被对方接收到的（通过 ACK 报文中的序列号可以得知）。
可见，序列号在 TCP
连接中占据着非常重要的作用，所以当客户端发送携带「初始序列号」的
SYN 报文的时候，需要服务端回一个 ACK
应答报文，表示客户端的 SYN
报文已被服务端成功接收，那当服务端发送「初始序列号」给客户端的时候，依然也要得到客户端的
ACK
应答回应，这样一来一回，才能确保双方的初始序列号能被可靠的同步。
四次握手其实也能够可靠的同步双方的初始化序号，但由于第二步和第三步可以优化成一步，所以就成了「三次握手」。而两次握手只保证了一方的初始序列号能被对方成功接收，没办法保证双方的初始序列号都能被确认接收。
原因三：避免资源浪费
如果只有「两次握手」，当客户端发生的 SYN
报文在网络中阻塞，客户端没有接收到 ACK 报文，就会重新发送
SYN
，由于没有第三次握手，服务端不清楚客户端是否收到了自己回复的
ACK 报文，所以服务端每收到一个 SYN
就只能先主动建立一个连接，这会造成什么情况呢？
如果客户端发送的 SYN 报文在网络中阻塞了，重复发送多次
SYN
报文，那么服务端在收到请求后就会建立多个冗余的无效链接，造成不必要的资源浪费。
即两次握手会造成消息滞留情况下，服务端重复接受无用的连接请求
SYN 报文，而造成重复分配资源。
⚠️注意：此处是在假设「由于没有第三次握手，服务端不清楚客户端是否收到了自己发送的建立连接的
ACK确认报文，所以每收到一个SYN就只能先主动建立一个连接」的场景。
小结
TCP 建立连接时，通过三次握手能够防止历史连接的建立，能够减少双方不必要的资源开销，能够帮助双方同步初始化序列号。序列号能够保证数据包不重复、不丢弃和按序传输。
- 不使用「两次握手」的原因：无法阻止历史连接的建立，会造成双方资源的浪费，也无法可靠的同步双方序列号；
- 不使用「四次握手」的原因：三次握手就已经实现可靠连接建立，所以不需要使用更多的通信次数。