RTMP 协议的三次握手和 TCP 的三次握手

原创于 2025-11-12 15:53:33 发布 · 777 阅读

CC 4.0 BY-SA版权

文章标签：

31 篇文章

订阅专栏

RTMP 协议的三次握手和 TCP 的三次握手是发生在不同网络层次、目的完全不同的两个过程。

现在我们来详细拆解。

所在层级： OSI 模型的传输层。
根本目的： 在客户端和服务器之间建立一条可靠的、面向连接的 TCP 通道。这是几乎所有网络通信（HTTP、FTP、RTMP等）的基础。
过程（简单回顾）：
1. SYN： 客户端发送一个 SYN 包（同步序列编号）到服务器，说：“我想和你建立连接。”
2. SYN-ACK： 服务器收到后，回复一个 SYN-ACK 包，说：“我同意建立连接，你也准备好。”
3. ACK： 客户端再回复一个 ACK 包，说：“好的，连接建立成功，我们可以开始传数据了。”
本质： 交换初始序列号，确认双方的发送和接收能力正常。这个过程对所有基于 TCP 的协议都是通用的。

对应比喻： 电信公司为你和你的朋友之间接通了一条物理电话线，你拿起话筒能听到拨号音，证明线路是通的。

所在层级： OSI 模型的应用层。
根本目的： 在已经建立好的 TCP 连接之上，进行 RTMP 协议本身的版本校验和随机数挑战，以确保对端也是一个合法的 RTMP 端点。
过程（详细解释）：
1. C0+C1（客户端 -> 服务器）
  - C0： 1 个字节，发送 RTMP 版本号（例如 3）。
  - C1： 1536 个字节，包含一个时间戳和一个随机填充数据块。
2. S0+S1+S2（服务器 -> 客户端）
  - S0： 1 个字节，回复支持的版本号（通常是 3）。
  - S1： 1536 个字节，服务器也生成自己的时间戳和随机数据块。
  - S2： 1536 个字节，这是一个响应。服务器将客户端发来的 C1 数据块几乎原样拷贝回来，以证明“我收到了你的挑战”。
3. C2（客户端 -> 服务器）
  - C2： 1536 个字节。客户端将服务器发来的 S1 数据块几乎原样拷贝回去，以证明“我也收到了你的挑战”。
本质： 这是一个复杂的“对暗号”过程，充满了无实际意义的随机数据交换。它不传输任何有效的音视频数据，纯粹是协议开销。

对应比喻： 电话接通后…

特性	TCP 三次握手	RTMP 三次握手
协议层级	传输层	应用层
依赖关系	RTMP 握手的前提。先完成 TCP 握手，建立连接，才能进行 RTMP 握手。	依赖于已建立的 TCP 连接。
主要目的	建立可靠的、双向的字节流通道。解决网络通不通、可不可靠的问题。	验证对端身份和协议兼容性。解决“你是不是我要找的 RTMP 服务器”的问题。
数据量	很小。几个包含序列号的 TCP 报文。	巨大。共 3 * 1536 + 2 * 1 ≈ 4.5 KB 的无用数据。
产生的延迟	1个RTT（Round-Trip Time，往返延迟）。	1.5个RTT（C0C1 -> S0S1S2 -> C2）。
必要性	绝对必要。没有 TCP 连接，一切免谈。	对于 RTMP 协议是必要的，但设计上被认为过于繁琐和低效，是 RTMP 的缺点之一。

这完美地解释了 “为什么 HTTP-FLV 比 RTMP 延迟更低” 的其中一个原因。

RTMP 建立连接总延迟：
- TCP 握手：1 RTT
- RTMP 握手：**~1.5 RTT**
- 总计：~2.5 RTT 后，才能开始传输真实的音视频数据。
HTTP-FLV 建立连接总延迟：
- TCP 握手：1 RTT
- HTTP 请求：客户端发送一个完整的 HTTP GET 请求。
- HTTP 响应：服务器返回 HTTP 头，并立即开始流式传输 FLV 数据。
- 总计：~1 RTT 后，就开始传输真实的音视频数据了。