为什么TCP握手是三次握手而不是两次

提示：文章写完后，目录可以自动生成，如何生成可参考右边的帮助文档

---

简介

TCP连接需要三次握手，旨在通过同步两方之间交换的消息来建立可靠的通信。

---

1. 三次握手

在TCP中，三次握手使用 SYN 和 ACK 消息在两方之间建立连接。但是，除了提供它们的序列号之外，服务端和客户端还相互确认序列号，确认序列号的动作避免了 SYN 重复错误的发生。

下图演示了三次握手的过程：

首先，客户端（或称连接发送方）将带有客户端的序列号 (X) 的 SYN 消息发送到服务端（或称连接接收方）。服务端回复包含服务端序列号 (Y) 并确认客户端的序列号 (X) 的 SYN-ACK。之后，客户端发送 ACK 消息确认服务端的序列号（Y），最终建立连接。

这是三次握手的过程，这个过程中，大家可能会想到，如果是为了让双方都能拿到客户端和服务端的序列号，其实两次握手可以拿到，为什么需要三次握手呢？下面我们就演示一下两次握手。

2. 两次握手

两次握手是一种简单的协议，用于在想要通信的两方之间建立连接。与三次握手一样，该协议也使用同步 (SYN) 和确认 (ACK) 消息。

简而言之，SYN 消息需要一个连接，并通知对方一个序列号来控制数据交换。实际上，TCP序列号是在特定流上传递的字节的计数器。反过来，ACK 消息用于确认收到（使用序列号）传入消息。

考虑到客户端/服务端模型，为了完成两次握手，客户端向服务端发送一个序列号为X的SYN消息。然后，服务端应确认（ACK）SYN 消息，提供另一个序列号 Y 并建立联系。 因此，序列号 X 将确认从客户端到服务端的消息，而序列号 Y 将确认从服务端到客户端的消息，如此一来，双方都能拿到客户端和服务端的序列号。

下图描述了两次握手过程：

3. 两次握手的问题

根据RFC793中的描述，之所以三次握手是必须的，就是存在一种情况：当来自服务端的 ACK 消息延迟太多，双向握手会带来潜在的问题。此时客户端认为发生连接超时（Timeout），会向服务端发送另一个带有新序列号（例如Z）的 SYN 消息。但是，如果服务端之前发送了一个 ACK（在收到X之后稍微延迟发送给客户端但是在Z之前），它将丢弃这个带有新序列号（例如Z）的 SYN 消息。反过来，客户端接收到延迟的 ACK 并假设它引用了最后发送的 SYN 消息。这是错误发生的地方：客户端将发送序列号为 Z 的消息，而服务端期望消息遵循序列号X。

下图显示了概述的问题：

总结

而三次握手过程很明显能解决所描述的两次握手问题，能够在发起消息的时候使用正确的序列号。

它们在两方之间建立了可靠的消息交换，我们可以得出结论，握手协议是当前网络通信的关键资源。