网络模型基础：OSI七层模型与TCP/IP四层模型，RTP/RTCP协议栈定位
做WebRTC流控，绕不开网络模型。很多人觉得这是基础课，直接跳过去看代码。我个人习惯是，先把地基打牢。你想想看，流控策略本质上就是在跟网络层打交道，不理解网络模型，调优的时候很容易抓瞎。
这一章，我们就把OSI七层模型和TCP/IP四层模型掰开揉碎了讲清楚，然后重点看看RTP/RTCP这对兄弟在协议栈里到底站在什么位置。
2.1 OSI七层模型：理想化的通信蓝图
OSI七层模型，全称是开放系统互连参考模型。它是个理论框架，定义了网络通信的七个层次。每个层各司其职，下层为上层提供服务。
我刚开始接触网络时，觉得这七层太抽象。后来在项目中排查一个视频卡顿问题，从应用层一路追到物理层，才真正体会到分层的好处——每一层的问题都可以独立排查。
| 层级 | 名称 | 核心职责 | 典型协议/设备 |
|---|---|---|---|
| 7 | 应用层 | 为用户提供网络应用服务 | HTTP, FTP, SIP |
| 6 | 表示层 | 数据格式转换、加密、压缩 | SSL/TLS, JPEG |
| 5 | 会话层 | 建立、管理、终止会话 | NetBIOS, RPC |
| 4 | 传输层 | 端到端可靠传输、流量控制 | TCP, UDP |
| 3 | 网络层 | 路由选择、逻辑寻址 | IP, ICMP, 路由器 |
| 2 | 数据链路层 | 帧封装、介质访问控制、差错检测 | 以太网, PPP, 交换机 |
| 1 | 物理层 | 比特流传输、电气特性 | 网线, 光纤, 集线器 |
关键理解：OSI是概念模型，实际工程中很少完全照搬。但它教会我们一件事——分层解耦。每一层只关心自己的事，出了问题也只在那一层解决。
2.2 TCP/IP四层模型：互联网的实战派
OSI七层模型太理想化了。互联网真正跑起来，用的是TCP/IP四层模型。它把七层压缩成了四层，更贴近实际工程。
说白了，TCP/IP模型就是互联网的「实战派」。它去掉了表示层和会话层，把应用层以上的东西全塞进了一层。
| TCP/IP四层 | 对应OSI层级 | 核心协议 |
|---|---|---|
| 应用层 | 5/6/7 | HTTP, SIP, RTP, RTCP |
| 传输层 | 4 | TCP, UDP |
| 网络层 | 3 | IP, ICMP |
| 网络接口层 | 1/2 | 以太网, WiFi |
注意看，RTP和RTCP在TCP/IP模型里被归到了应用层。但严格来说，它们更像是「半传输层」的协议。为什么这么说？往下看。
2.3 RTP/RTCP协议栈定位：站在UDP肩膀上的实时传输双雄
RTP（实时传输协议）和RTCP（实时传输控制协议）是WebRTC的命根子。它们俩是双胞胎，一个负责运数据，一个负责反馈质量。
它们的协议栈位置，我画了张图，你一看就明白。
这张图里，RTP/RTCP被单独拎出来放在应用层和传输层之间。为什么这么画？
因为RTP虽然跑在UDP之上，但它做的事情远不止「传输」那么简单。它要处理时间戳、序列号、负载类型标识、SSRC同步源标识等等。这些功能，严格来说已经超出了传输层的范畴。
我的经验：在WebRTC源码里，RTP/RTCP的实现是在应用层完成的。但调试的时候，我习惯把它们当作「传输层扩展」来看待。这样更容易理解为什么流控算法要同时关注RTP的发送速率和RTCP的反馈报文。
2.4 RTP与RTCP的分工协作
RTP和RTCP共用同一个UDP端口对（一个偶数端口给RTP，下一个奇数端口给RTCP）。它们的分工非常明确：
- RTP：负责搬运媒体数据。音频帧、视频帧，都封装成RTP包发出去。它不保证可靠传输，也不保证顺序到达。实时性优先。
- RTCP：负责反馈信道质量。发送端报告（SR）、接收端报告（RR）、源描述（SDES）、BYE报文等。流控算法全靠RTCP的反馈来调整发送策略。
我记得有一次线上问题，用户反馈视频卡顿。我抓包一看，RTCP的接收端报告里丢包率飙到了15%。但RTP流本身还在正常发。这就是典型的「RTP埋头苦干，RTCP喊救命」的场景。
避坑指南：我曾经遇到过一个坑——RTCP的反馈周期默认是5秒。对于WebRTC这种毫秒级流控来说，5秒太长了。等RTCP报告过来，网络状况早就变了。所以实际工程中，我们会把RTCP的发送间隔压缩到1秒甚至更短。但要注意，RTCP报文本身也会占用带宽，不能压得太狠。
2.5 为什么WebRTC选择UDP而不是TCP？
这个问题面试经常问。答案其实很简单：实时性。
TCP有重传机制，丢包了会等重传，这会导致延迟不可控。WebRTC做的是实时通信，延迟超过400ms，用户就能感觉到明显的卡顿。所以WebRTC选择UDP，丢包了不重传，而是通过FEC（前向纠错）和流控算法来补偿。
但UDP也有缺点——它没有拥塞控制。这就是为什么WebRTC要在应用层自己实现一套流控机制。GCC（Google Congestion Control）、REMBB、Transport-CC，这些都是为了弥补UDP在拥塞控制上的缺失。
| 特性 | TCP | UDP | WebRTC的选择 |
|---|---|---|---|
| 可靠性 | 可靠，有重传 | 不可靠，无重传 | UDP + 应用层补偿 |
| 延迟 | 高（重传导致抖动） | 低（无重传） | UDP |
| 拥塞控制 | 内置（慢启动、拥塞避免） | 无 | 应用层实现（GCC等） |
| 适用场景 | 文件传输、网页浏览 | 实时音视频、在线游戏 | 实时通信 |
一句话总结：WebRTC选择UDP，是因为它把「实时性」放在了「可靠性」前面。丢包可以忍，延迟不能忍。而RTP/RTCP就是在这个UDP的「快车道」上，自己建了一套「交通管制系统」。
2.6 本章小结
这一章我们理清了网络模型的基础。OSI七层是理论框架，TCP/IP四层是实战模型。RTP/RTCP站在UDP的肩膀上，一个负责运数据，一个负责反馈质量。理解了这个定位，后面讲GCC算法、Transport-CC时，你就能知道它们到底在哪个层级发挥作用。
嗯，基础打牢了，后面才能跑得快。