前置知识
首先来看看 TCP 的控制位和状态机,这是理解 TCP 三次握手的基础。
TCP 报文控制位
TCP 报文头部中的控制位用于控制 TCP 连接的状态,可以指示各种控制信息,如连接建立、终止、重置等。
常见的控制位有 6 个:
- SYN (Synchronize Sequence numbers): 请求建立连接 (三次握手),在连接建立时的初始数据包中设置,表明发送端希望建立连接并同步序列号,TCP 是双向通信,所以建立连接时,双方都要发一个 SYN, 虽然 SYN 报文不能携带数据,但要消耗掉一个序号
- ACK (ACKnowledgment field significant): 确认接收到的数据,ACK 标识设置后,接收端会在确认字段中填入下一个期望接收的序列号,ACK 报文如果不携带数据,则不消耗序号
- FIN (No more data from sender): 请求终止连接 (四次挥手),在数据发送完毕后的数据包中设置,通知接收 (对) 方: 发送 (己) 方已发送完所有数据,TCP 是双向通信,所以关闭连接时,双方都要发一个 FIN, 虽然 FIN 报文不携带数据,但要消耗掉一个序号
- RST (Reset the connection): 重置连接,用于异常或错误的连接终止,当接收端收到 RST 标识时,会立即终止连接,不做任何数据确认,例如 之前的文章中提到的 TIME_WAIT 问题,注意: 生产环境中出现 RST 包往往意味着潜在的问题
- PSH (Push Function): 提示接收端将接收到的数据立即交付应用层,表明数据应当被快速处理,而不需要等待更多的后续数据到达
- URG (Urgent Pointer field significant): 指示数据具有高优先级,接收端应尽快处理
- ECE (ECN-Echo): 指示通信双方在三次握手时,协商两端是否都支持显示拥塞控制
Sequence Number (序号)
TCP 是双向通信,所以单个连接中的双方都可以向对方发送数据,所以需要各自维护自己的 Seq
字段。
Seq
是动态随机生成的,这样可以避免被伪造的报文重置连接 (RST 攻击)。
TCP 提供有序的传输,所以每个数据报文段都要加上一个 Seq
序号字段:
- 当接收端收到乱序的包时,可以根据 Seq 重新排序
- 当接收端收到重复的包时,可以根据 Seq 去重
如图所示,序号增长方式 (重要):
- 数据段 1 起始 Seq 号为1,长度为 1448 (单位: 子节),那么数据段 2 的 Seq 号就等于 1 + 1448 = 1449
- 数据段 2 的长度也是 1448,所以数据段 3 的 Seq 号为 1449 + 1448 = 2897
也就是说,一个 Seq 号的大小是根据上一个数据段的 Seq 号和长度相加而来的。
所以在 TCP 数据传输过程中,任意一方发出的数据段应该是连续的: 后一个包的 Seq 号等于前一个包的 Seq + Len (三次握手和四次挥手除外)。
Len (数据段长度)
需要注意的是: Len
不包括 TCP 头部长度,所以不要认为 Len = 0
的数据包没有意义,TCP 头部本身携带的信息也很多。
ACK (确认号)
接收端告诉发送端自己已经收到了哪些数据段 (Seq
序号)。
- 发送端 发送了
Seq:1 Len:100
的数据到 接收端, 然后 接收端 回复的ACK
就是1 + 100 = 101
, 表示自己收到了 101 之前的所有数据 - 发送端 发送了
Seq:101 Len:50
的数据到 接收端, 然后 接收端 回复的ACK
就是101 + 50 = 151
, 表示自己收到了 151 之前的所有数据
比如甲发送了“Seq:x Len:y”的数据段给乙,那乙回复的确认号就是x+y,这意味着它收到了x+y之前的所有字节。
结论 (重要): 接收端回复的 ACK
号正好等于发送端的下一个 Seq
号,所以我们可以看到 10377 号包的 ACK
正好等于 10378 号包的 Seq
。
如果通信中任意一方没有发送任何数据,那么对方返回的 ACK
号也不会发生变化 (也就是三次握手时的初始值)。
TCP 状态机
下面是经典的 TCP 状态机,每个 TCP 连接从最初建立到最后断开,整个生命周期中的所有状态都囊括其中。
下面是来自维基百科的彩色版本:
三次握手示例
下面是一个典型的三次握手示例图。
- 第一次握手:客户端发起连接请求,设置请求报文控制位
SYN = 1
, 同时初始化一个随机序列号 (ISN)Seq = x
, 发送请求报文SYN
后,客户端进入SYN-SENT
状态 - 第二次握手:服务端收到客户端的连接请求后,初始化一个随机序列号 (ISN)
Seq = y
, 同时设置应答报文控制位SYN = 1
, 确认控制位ACK = x + 1
, 发送应答报文SYN-ACK
后,服务端进入SYN-RECEIVED
状态 - 第三次握手:客户端收到服务端的应答后,设置应答确认控制位
ACK = x + 1
, 发送应答报文ACK
后,客户端进入ESTABLISHED
状态,服务端收到客户端的ACK = y + 1
报文后,进入ESTABLISHED
状态,TCP 连接建立完成
在整个连接过程中,客户端和服务端的状态变化如下图所示:
从图中可以看到,对于 ESTABLISHED (连接已建立)
这个状态,客户端和服务端的感知时间是不一样的:
- 对于客户端来说,两次握手完成后,连接建立完成
- 对于服务端来说,三次握手完成后,连接建立完成
Wireshark 抓包
为了更直观的感受 TCP 的三次握手过程,这里使用 Wireshark 进行抓包:
打开 WireShark 开始抓包,然后在终端执行下列命令:
$ curl -I -H "Connection: close"
切换到 Wireshark 操作界面,使用 tcp
进行包过滤,可以看到如下的 TCP 三次握手过程,其中 192.168.3.68 是本级的局域网 IP 地址。
- 第一次握手:客户端发起连接请求时,使用的
Seq
字段为 3123802190 - 第二次握手:服务端发起应答报文时,使用的
Seq
字段为 1071295171,ACK = x + 1
, 也就是 3123802191 - 第三次握手:客户端发起应答报文时,使用的
ACK = y + 1
, 也就是 1071295172
Tips: Wireshark 默认情况下,显示的是 Seq
的相对值 (从 0 开始),如果想看到客户端和服务端的真实随机 Seq
值,可以在 Wireshark 操作界面的菜单进行如下设置:
Edit > Preferences > Protocols > TCP取消勾选: Relative Sequence numbers
证明 (粗糙版本)
讲完了 TCP 三次握手的理论基础之后,接下来可以分析并证明如下命题:
TCP 建立连接时,至少需要三次握手。
这里我们使用一个非常基础的数学证明方法:反证法,既然至少需要三次握手?那么我们的反证命题如下:
TCP 建立连接时,不需要三次握手。
具体来说,我们假设 TCP 握手次数 N 少于三次就可以建立连接,这里又可以将 N 分为三种范围区间:
下面对三种范围区间分别进行证明。
1. N < 1
当 N < 1
时,意味着双方都不发起第一次握手,此时双方甚至都不知道彼此的存在,更别谈建立连接进行通信了,所以 N < 1
不成立,此时进入下一个命题: N == 1
。
2. N == 1
当 N == 1
时,意味着双方需要一次握手,也就是 发送端 向 接收方 发起连接建立请求 (SYN
),但是请求发出后就没有下文了,所以连接还是无法建立。
因为没有收到接收端的应答报文,所以 发送端 此时无法确认两件事情:
发送 | 接收 | |
---|---|---|
发送端 | ❌ | ❌ |
接收端 | ❌ | ❌ |
- 发送端 (自己) 的发送功能是否正常 (否可以将数据正常发送到接收端)
- 接收端的接收功能是否正常 (包括是否监听了对应的端口、数据缓冲区是否正常等)
因为无法确认这两件事情,所以发送端认为连接还未建立,自然也就不会向接收方继续发送数据了。所以 N == 1
不成立,此时进入下一个命题: N == 2
。
3. N == 2
当 N == 2
时,意味着双方需要两次握手,我们在 N == 1
的基础上继续证明。
在第一次握手后,接收端 收到 发送端 的连接建立请求报文后,会回复一个连接建立应答报文 (SYN-ACK
),但是和 发送端 的报文一样,接收端 的应答发出后就没有下文了,所以连接还是无法建立。
1. 发送端 (自己) 的发送功能是否正常 (否可以将数据正常发送到接收端)
2. 接收端的接收功能是否正常 (包括是否监听了对应的端口、数据缓冲区是否正常等)
对于 N == 1
中存在的两个问题,此时已经得到了确认:
发送 | 接收 | |
---|---|---|
发送端 | ✅ | ❌ |
接收端 | ❌ | ✅ |
- 发送端的发送功能是正常的
- 接收端的接收功能是正常的
因为没有收到 发送端 的 (确认) 应答报文,所以 接收端 此时无法确认两件事情:
- 接收端 (自己) 的发送功能是否正常 (是否可以将数据正常发送到发送端)
- 发送端的接收功能是否正常
原命题证明
通过前文中的反证法,可以证明 TCP 建立连接时,至少需要三次握手。
我们沿着前文中的思路,来看看 N == 3
时,发送端 和 接收端 对应的状态变化。
在第二次握手后,发送端 收到 接收端 的连接建立应答报文后,会回复一个连接建立应答报文 (ACK
)。
1. 接收端 (自己) 的发送功能是否正常 (是否可以将数据正常发送到发送端)
2. 发送端的接收功能是否正常
对于 N == 2
中存在的两个问题,此时已经得到了确认:
发送 | 接收 | |
---|---|---|
发送端 | ✅ | ✅ |
接收端 | ✅ | ✅ |
- 接收端的发送功能是正常的
- 发送端端接收功能是正常的
证明 (正确版本)
前文中通过 (粗糙地) 反证法 + TCP 报文状态 证明了 TCP 建立连接时,至少需要三次握手,除此之外,也可以利用 TCP 序列号 (严谨地) 证明。
为了实现可靠数据传输,TCP 协议的通信双方都必须维护一个序列号 Seq
,用来标识发送出去的数据包中哪些是已经被对方收到的。
三次握手的过程等于: 通信双方相互发送初始序列号,并确认对方已经收到了初始序列号的必要过程。
- 如果只有一次握手,接收端 没有发送初始序列号
- 如果只有两次握手,只有 发送端 的初始序列号可以被确认,接收端 的初始序列号无法得到确认
除此之外,在只有两次握手的情况下,可能还会出现一种异常情况: 延迟包导致的无效连接。
如图所示,某个网络有多条路径,客户端建立连接请求的第一个数据包,正好被传输到一条延迟严重的路径,所以迟迟没有到达服务器。
客户端发送超时后,认为第一个数据包丢失了,于是重新发起请求,第二个请求被传输到正常的路径,所以很快就完成了连接。
对于客户端来说,本次通信过程似乎已经结束了,但是此时它的第一个数据包,延迟到达了服务器。因为服务器并不知道这是一个旧的无效请求,所以按照正常情况回复应答。
如果 TCP 只有两次握手,服务器上此时就建立了一个无效的 (过期的重复) 连接。
但是在 TCP 三次握手的机制下,客户端收到服务器的回复后,发现这个 (已经超时的) 连接不是它想要的,所以就应答一个 RST
数据包,服务器收到 RST
数据后,同时关闭连接。
重点: 三次握手,到底握的是什么?发送方和接收方的初始化 Seq 值 (ISN, Initial Sequence Number), 通过这个值就可以区分当前的本次连接和历史旧连接。
结论
理论上讲 3 次以上,不论握手多少次,都无法确认一个 TCP 连接是 “完全可靠” 的。
但通过 3 次握手,至少可以确认连接是 “基本可用” 的,再增加握手次数,也只不过是提高 “连接可用” 这个结论的可信程度而已。
TCP 3 次握手后,发送端 和 接受端状态变化如下:
- 发送端确认了: 自己发送、接收正常,对方发送、接收正常
- 接收端确认了: 自己发送、接收正常,对方发送、接收正常
发送 | 接收 | |
---|---|---|