网络协议：IP，TCP详细介绍，以及应用层HTTP与RTMP的区别-深圳市維司達科技有限公司

我们将从底层的 IP 讲起，经过传输层的 TCP，最后抵达应用层的 HTTP 与 RTMP，帮助你构建清晰的全栈网络知识体系。

深入拆解网络协议：从 IP 到 TCP，再到 HTTP 与 RTMP

当我们点开一个网页，或者观看一场直播时，数据在网络中是如何精准、可靠且实时地传输的？这背后离不开一套分层设计的协议体系。今天，我们将从最基础的“寻址与路由”开始，到“可靠传输”的建立，再到最熟悉的“网页浏览”和“直播推流”，逐一剖析IP、TCP、HTTP 和 RTMP这四个至关重要的协议。

一、IP 协议：互联网的邮政系统

IP（Internet Protocol，互联网协议）工作在网络层，是整个 TCP/IP 协议族的核心。它的任务很简单：尽最大努力将数据包从源主机传送到目的主机。

1. 核心职责：寻址与路由

IP 地址：每台接入网络的设备都有一个逻辑地址，如192.168.1.1或2001：：1。它好比“上海市浦东新区XX路1号”，让数据知道该往哪里走。
路由：数据包在路由器之间跳跃。每个路由器都维护着一张路由表，查表决定下一跳（Next Hop）是谁。整个过程就像快递经过多个中转站，最终到达目的地。

2. 无连接、不可靠

IP 协议是一个无连接协议，发送数据前不需要建立端到端的连接。它也是不可靠的，不做任何差错恢复——数据包可能丢失、重复、乱序，IP 本身一概不管。这种“尽力而为”的简单设计，将可靠性工作交给了上层的 TCP。

3. 数据包结构一览

一个 IP 数据包由首部和数据两部分组成。首部中几个关键字段：

版本：IPv4 还是 IPv6。
TTL（生存时间）：每经过一个路由器减1，归零则丢包，防止数据包在网络中无限漫游。
协议：指明上层协议，如 6 代表 TCP，17 代表 UDP。
源/目的 IP 地址：收发双方的逻辑地址。
分片标识：当数据包大于链路 MTU（最大传输单元）时，会被分片传输，到达目的地后重组。

小结：IP 只解决“能不能送到”的问题，不解决“送得稳不稳”。后者，是 TCP 的事。

二、TCP：可靠的传输管道

IP不是端到端的，IP只管往前发。TCP是端到端的。

TCP（Transmission Control Protocol，传输控制协议）工作在传输层，建立在 IP 之上。它把不可靠的 IP 变成了一条可靠的、面向连接的字节流通道。

1. 三次握手：建立连接

为什么是三次？因为要确认双方的收发能力均正常。

第一次：客户端发送SYN包，表示“我想和你建立连接”。
第二次：服务端回复SYN+ACK包，表示“我收到了，我也准备好连接了”。
第三次：客户端发送ACK包，表示“我确定你收到我的请求了”。
至此，连接建立，数据可以可靠传输。

2. 四大可靠传输机制

确认应答（ACK）：接收方每收到数据，就发回一个确认号，告诉发送方“下一个我要收第 N 号字节”。若发送方超时未收到确认，就重传。
滑动窗口：不必每发一个包就等一次 ACK，发送方可以一次发送窗口大小的数据量。窗口大小由接收方动态告知（流量控制），既保证了速度，又防止接收方缓冲区溢出。
拥塞控制：为了防止网络拥堵，TCP 会动态调整发送速率，经历慢启动、拥塞避免、快重传等阶段。一旦丢包，窗口减半，再慢慢爬升。
按序到达：每个 TCP 报文都带有序列号，接收方可以按序重组数据，丢弃重复的。

3. 四次挥手：优雅断开

由于 TCP 是全双工（双方可同时收发），断开需要四次交互：

客户端发FIN，表示“我说完了，但我还能听”。
服务端回ACK，表示“知道你说完了”。
服务端也发FIN，表示“我也说完了”。
客户端回ACK，进入 TIME_WAIT 状态，等待一段时间确保最后的 ACK 被收到。

小结：TCP 通过序列号、确认、重传和窗口控制，在无连接的 IP 层上搭建了一条逻辑上的可靠管道。HTTP 和 RTMP 都行驶在这条管道之上。

三、HTTP：万维网的基石

HTTP（HyperText Transfer Protocol，超文本传输协议）是应用层协议，基于 TCP 的 80 端口（或 HTTPS 的 443 端口）。

1. 无状态与请求-响应模型

HTTP 的核心设计是无状态的：每次请求都是独立的，服务器不记得你上次是否来过。这简化了架构，但也催生了 Cookie、Session 等状态保持手段。
通信模式：客户端发送一个请求，服务器返回一个响应，然后连接可以关闭或复用。

2. HTTP 请求与响应的结构

一条典型的 HTTP 报文都由起始行、首部字段和可选的消息体组成。

请求示例：

POST /api/login HTTP/1.1 Host： www.example.com Content-Type： application/json Content-Length： 28 {"username"："neo"，"password"："123"}

请求方法：GET（获取）、POST（提交）、PUT（更新）、DELETE（删除）等。
URL：标识请求的资源路径。
首部字段：承载元信息，如主机名、接受格式、Cookie 等。

响应示例：

HTTP/1.1 200 OK Content-Type： text/html Set-Cookie： session=abc <html>...</html>

状态码：200成功，301/302重定向，404未找到，500服务器错误等。
首部字段：返回服务器信息、内容类型、缓存策略等。
消息体：实际的 HTML、图片、JSON 数据。

3. 版本演进：从 1.1 到 3

HTTP/1.1：支持持久连接（Keep-Alive）、管道化请求（虽然队头阻塞问题很严重），仍然是目前最主流的基础协议。
HTTP/2：引入二进制分帧、多路复用（在单个 TCP 连接上并行传输多个请求/响应，解决队头阻塞）、头部压缩和服务器推送，显著提升 Web 性能。
HTTP/3：底层放弃 TCP，改用基于 UDP 的 QUIC 协议，彻底解决 TCP 层的队头阻塞，并实现了 0-RTT 快速建立连接。目前已有大量应用。

小结：HTTP 是信息的载体，专注于资源的表述和传输，而将可靠性完全委托给 TCP。它适合按需拉取的离散资源（网页、图片、API 数据），但对于连续、实时的流媒体则有些笨重。

四、RTMP：实时消息的管道

RTMP（Real-Time Messaging Protocol）是由 Macromedia/Adobe 开发的应用层协议，专门为 Flash 播放器与服务器之间的音视频流传输而设计。如今虽然 Flash 已谢幕，但 RTMP 凭借其低延迟和成熟稳定的特性，依然活跃在直播推流和流媒体分发领域。

1. 与 HTTP 的本质差别

连接方向：RTMP 是有状态、持久连接，双方可以在同一连接上长时间收发多条消息流，不存在“请求-响应”的对应关系。
数据分片：RTMP 将音视频数据进一步封装为带时间戳的块（Chunk），在同一个 TCP 连接上可以交错传输视频、音频和控制指令，并通过消息流 ID复用，避免音频阻塞视频。
传输模式：支持推（Publish）、拉（Play）、共享对象等模式，专为连续流设计。

2. 工作流程：握手、连接、流

握手：客户端与服务器先后交换 C0/C1 和 S0/S1/S2 包，协商版本并确认对端可达。握手还携带了时间戳用于后续的时钟同步。
建立连接：客户端发送connect命令，指定应用名（如live），服务器响应_result同意建立。
创建流：客户端发送createStream，服务器返回一个流 ID（如 1），代表一条逻辑通道。
发布或播放：
- 推流：客户端发送publish命令（带上流名，如stream_key），然后持续发送音视频数据。
- 拉流：客户端发送play命令，服务器开始持续推送数据。

3. RTMP 块的分装

RTMP 会将大的音视频消息拆成小的 Chunk（默认 128 字节），通过 TCP 发送。每个 Chunk 头部包含：

Chunk Stream ID：逻辑流通道 ID，可以在一个 TCP 连接中同时传输多个流（如同时推送音频和视频，各占一个 Chunk ID）。
Timestamp：时间增量，用于播放时重建时序。
Message Type：标示是音频、视频还是控制命令。

这种对实时连续流的拆分和交错，保证了播放端能以极低的延迟还原出流畅的音视频，典型的端到端延迟能控制在 1-3 秒。

4. RTMP 的变体与应用

RTMP 本身：基于 TCP 的 1935 端口，明文传输。
RTMPS：RTMP 跑在 TLS/SSL 之上，加密传输。
RTMPE：Adobe 私有加密。
RTMPT：将 RTMP 包裹进 HTTP 请求以穿透防火墙。

当今的通用直播架构一般是：

主播设备 → 推流（通过 RTMP）→ CDN 边缘节点 → 转协议/分发 → 观众（通过 HTTP-FLV、HLS、WebRTC 等观看）

RTMP 在“推流到服务器”这一环依然坚挺，原因就是它的持久连接、低延迟和极佳的生产环境兼容性。

五、协议栈的协作全景

来把上面讲的全串起来，看一个典型的浏览器访问网页和一次直播推流是如何层层协作的。

场景	HTTP 网页访问	RTMP 直播推流
应用层	HTTP/2，请求网页与资源	RTMP，发送`publish`命令与音视频
传输层	TCP，保证 HTML 文件可靠传输	TCP，保证音视频数据块可靠传递
网络层	IP，将数据包路由到目标 Web 服务器	IP，将数据包路由到推流服务器
链路/物理层	以太网 / Wi-Fi，在物理介质上传输比特	同左

共同的设计哲学

分层解耦：应用层只关心业务语义（HTTP 的 URL、状态码；RTMP 的推拉流命令），不用关心包是否丢、怎么寻址。
下层为上层服务：TCP 把不可靠的 IP 变成可靠的流，HTTP 和 RTMP 则用这份可靠来构建各自的应用逻辑：一个专注于资源的获取与表示，一个专注于实时消息和流的同步。

理解从 IP 的“尽力送达”，到 TCP 的精巧控制，再到 HTTP 的无状态请求和 RTMP 的有状态流式管道，你就掌握了互联网通信最底层的脉络。无论未来上层协议如何变化（HTTP/3 转向 QUIC，WebRTC 的兴起），这一层层的抽象与分工依然是网络世界稳定运行的基石。

如果你觉得这篇梳理有帮助，欢迎分享给更多对网络原理感兴趣的朋友。如有疑问或想了解更深层的细节（如 TCP 拥塞控制算法对比、HTTP/3 的 QUIC 详解），欢迎在评论区留言讨论！