做流媒体这几年,我接到的求助里有一大半都跟 RTSP 服务器逻辑有关。有人拿现成组件搭了一套,客户端能连上,画面也能出,但一上并发就开始花屏;有人自己写协议栈,OPTIONS 和 DESCRIBE 都通了,SETUP 之后 PLAY 一发,客户端直接断连;还有人更冤,服务端日志显示一切正常,客户端就是黑屏,最后发现是 SDP 里的 track 标识和 SETUP 请求里的 URL 对不上。这些问题表面看是"某个接口不通",根子上是把 RTSP 服务器当成一个"转发视频的管道"来理解,忽略了它本质上是一台有状态的控制协议服务端。这篇文章我想把 RTSP 服务器逻辑从上到下拆一遍:协议栈里控制面和数据面怎么分工、会话状态机怎么设计、每个方法收到之后服务端应该做哪些校验和应答、RTP 打包和分发怎么走、并发和回收怎么做,以及出问题的时候按什么顺序排查。内容偏向服务端实现与运维视角,不管你是用现成框架做二次开发,还是打算自己撸一套,或者只是被线上卡顿折腾得够呛,应该都能找到能直接抄的部分。文中涉及的具体参数和代码是我按常见工程实践补的,不是某套特定产品的实现,拿去做参考方案没问题,照抄到生产环境前记得按自己的场景重新验证。
1. RTSP 服务器到底在做什么:先把控制面和数据面分开
1.1 一个被误解的协议定位
很多人第一次接触 RTSP,会下意识拿它跟 HTTP 类比,觉得"不就是个带状态的 HTTP 吗"。这个类比只对了一半。RTSP 确实借用了 HTTP 的报文语法,请求行、头部、状态码那一套几乎一样,连 CSeq 这种序列号机制都是同源的。但 RTSP 的定位是远程控制,不是传输。它负责的事情是:让客户端告诉服务端"我要看哪个流""用哪种方式传""现在开始放""暂停一下""我走了把资源还回来"。真正的音视频数据走的是 RTP,质量反馈走 RTCP,这三者是一套组合拳。
理解这一点非常关键,因为它直接决定了服务端的职责边界。如果你的服务器逻辑只在 RTSP 通道上做报文应答,却不管理 RTP 的发送节奏、不维护 RTCP 的反馈,那客户端大概率能连上、能收到几帧,然后就开始抱怨卡顿和马赛克。反过来,如果你把 RTSP 当成数据通道,把所有逻辑都塞进一次请求的响应里,那会话一多,请求处理线程就会被发送逻辑拖死。所以我个人在设计时的第一条原则就是:控制面和数据面彻底解耦,RTSP 线程只做状态变更和指令下发,真正的数据发送由独立的发送器或者事件驱动层负责。
这套分离还有个好处是便于排查。线上出问题的时候,你能立刻判断是"控制面没走通"还是"数据面没发出去"。控制面问题的特征很明显:客户端在某个方法上卡住、收到 4xx/5xx、或者干脆收不到响应;数据面问题则是控制面全绿、日志里 PLAY 也返回 200,但客户端画面不动。这两类问题的排查路径完全不同,混在一起查会浪费大量时间。
1.2 一次完整会话的时序与各阶段的服务端动作
我把一次典型的点播会话拉直来看,服务端在每个阶段要做的事情其实相当明确。下面这个流程是按最常见的拉模式(pull)写的,也就是客户端主动来拉流,服务端作为媒体源的分发方。
| 阶段 | 客户端请求 | 服务端核心动作 | 常见失败点 |
|---|---|---|---|
| 能力探测 | OPTIONS | 返回支持的 Public 方法列表 | 方法列表与实际实现不一致 |
| 媒体描述 | DESCRIBE | 生成 SDP,分配媒体索引 | track 标识与后续 SETUP 对不上 |
| 建立传输 | SETUP | 分配会话、绑定端口或通道、创建发送器 | 传输参数不支持、端口被占 |
| 启动播放 | PLAY | 启动发送器、记录基准时间戳 | 首帧时间戳处理错误 |
| 维持会话 | GET_PARAMETER / OPTIONS | 刷新会话存活时间 | 心跳不刷新导致会话被回收 |
| 暂停恢复 | PAUSE / PLAY | 暂停发送、重置时间基准 | 恢复后时间戳跳变 |
| 结束释放 | TEARDOWN | 关闭发送器、释放端口、销毁会话 | 资源未回收导致句柄泄漏 |
这张表看起来简单,但每一行背后都有坑。比如 OPTIONS 返回的 Public 列表,我见过不少实现图省事,直接把一堆方法全列上去,结果客户端按列表里的方法去调,服务端根本没实现,直接返回 501,客户端就判定这个服务器不靠谱。再比如 DESCRIBE 返回的 SDP 里,a=control字段写的是track1,而 SETUP 的时候客户端拼出来的 URL 是rtsp://host/stream/track1,如果你的路由解析没处理好尾部和斜杠,就会匹配失败,返回 404。这类问题在实际项目里出现的频率高得惊人,而且从日志上看往往只是"一个 404",很容易被忽略过去。
我的习惯是在服务端把每个请求的完整 URL、CSeq、Session、Transport 四个头部都打出来,尤其是 URL。因为 RTSP 的 URL 结构比 HTTP 复杂,它带着媒体级别的路径后缀,SETUP 请求打过来的时候那个 URL 已经不是 DESCRIBE 时的那一个了。不打日志,你根本不知道客户端拼出来的是什么。
提示:DESCRIBE 之后客户端会基于 SDP 里的 control 字段拼接 SETUP 的 URL,服务端必须保证这两处的标识体系一致。最稳妥的做法是服务端自己生成一个稳定的媒体 ID,同时把 SDP 里的 control 和路由解析规则都绑定到这个 ID 上,不要依赖客户端拼出来的字符串做模糊匹配。
2. 会话状态机:RTSP 服务器的骨架
2.1 五个状态与它们之间的迁移关系
如果让我只保留一个东西来说明 RTSP 服务器的逻辑核心,那一定是会话状态机。RFC 里定义的状态是 Init、Ready、Playing、Recording 这几个,工程上我一般会再加一个隐式的 Closed 状态,用来表示会话已经销毁但还有残留引用。整个服务器的正确性,很大程度上取决于你有没有严格按状态机去拒绝非法请求。
状态迁移的逻辑是这样的:客户端发起 SETUP 之前,会话还不存在,服务端在收到第一个 SETUP 时创建会话并把状态置为 Ready;PLAY 请求把状态从 Ready 推到 Playing,同时启动数据发送;PAUSE 把 Playing 退回 Ready,但会话本身和传输参数都保留;TEARDOWN 从任何状态直接进入 Closed,释放全部资源。核心原则是:任何在当前状态下不合法的请求,必须明确拒绝,标准做法是返回 455 Method Not Valid in This State。
我踩过的一个典型坑是:早期实现为了"兼容性",对 PLAY 请求没有做状态校验,客户端重复发 PLAY 也照样返回 200 并重新启动发送器。结果是客户端因为网络抖动重发了一次 PLAY,服务端启动了两个发送器往同一个通道推数据,客户端收到的 RTP 序列号完全乱套,画面直接雪崩。这个问题的根因就是状态校验缺失。所以后面我在这块加了一条硬规则:PLAY 只在 Ready 状态下有效,Playing 状态下再收到 PLAY,要么幂等返回 200 不做任何动作,要么返回 455,但绝对不能重复启动发送逻辑。
这里有个细节值得展开。幂等返回和拒绝返回,哪种更好?我的经验是看客户端类型。如果对接的是标准化程度高的客户端,严格返回 455 更安全,因为它能明确暴露客户端的行为异常;如果对接的是一堆来源不明的设备,那幂等返回 200 更稳妥,因为有些设备会把 455 当成致命错误直接断开。工程上我一般做成可配置项,默认幂等,调试期打开严格模式。
2.2 每个方法的入参校验:别只做表面应答
写协议服务端最容易犯的错,就是只关心"返回什么",不关心"收到了什么"。RTSP 的每个方法都带着若干必须校验的头部,漏掉任何一个都可能埋雷。下面按方法过一遍我在实现里必做的校验。
OPTIONS 相对简单,但要注意它的 URL 可能是通配的*,也可能是具体的流地址。服务端应该都能处理,并且返回的 Public 列表要和真实能力一致,不要虚标。
DESCRIBE 的关键是 Accept 头。客户端可能只接受application/sdp,也可能带别的类型。如果服务端没法提供客户端能接受的格式,应该返回 406 Not Acceptable,而不是硬塞一个 SDP 过去。另外 DESCRIBE 阶段还没有会话,不需要 Session 头,如果客户端带了,忽略即可。
SETUP 是整个协议里校验最重的。首先要解析 Transport 头,典型格式类似RTP/AVP;unicast;client_port=5000-5001,也可能带interleaved=0-1表示走 TCP 交织。服务端要做的判断包括:传输协议是否支持、单播还是组播、客户端端口是否在合法范围、如果是 TCP 交织通道号是否冲突。任何一项不满足,应该返回 461 Unsupported Transport,并可以在响应里带上服务端支持的 Transport 列表,方便客户端降级重试。校验通过之后才分配 Session ID,并在响应里回带Transport和Session。
PLAY 主要看 Range 头。客户端可能请求npt=0-表示从头播,也可能请求npt=30-60表示从第 30 秒播到第 60 秒,还可能是npt=now-表示从当前位置开始。服务端要能解析这些形式,并且真的按请求的区间去切数据,而不是一律从头推。如果请求的时间点超出媒体时长,按标准应该返回 457 Invalid Range。这里我见过不少实现直接把 Range 忽略掉,结果就是客户端点进度条跳转没反应,体验极差。
PAUSE 和 TEARDOWN 相对轻,但要保证 PAUSE 之后发送器真的停了,而不是缓冲里还在往外冒数据;TEARDOWN 之后要保证端口和句柄真的释放了,这个后面在资源回收那节还要展开。
2.3 SDP 生成:这不是拼字符串,是拼契约
SDP 在 RTSP 里的地位被严重低估了。很多实现把它当成一段固定模板,媒体参数写死,结果遇到不同编码、不同分辨率就出问题。实际上 SDP 是服务端和客户端之间的一份媒体能力契约,里面每个字段都在告诉客户端"我打算怎么给你发数据"。
关键的几个字段我逐个说一下。m=行声明媒体类型、端口和负载类型,RTSP 场景下端口通常写 0,因为真实端口在 Transport 头里协商。a=rtpmap把负载类型映射到具体编码,比如a=rtpmap:96 H264/90000,这里的 90000 是 H.264 的固定时钟频率,写错了会导致客户端算出来的播放时间完全错乱。a=fmtp放编码相关的参数,H.264 最典型的是sprop-parameter-sets,里面是 SPS 和 PPS 的 Base64 编码,客户端靠它来初始化解码器。如果这个字段缺失或者内容错误,很多客户端会直接黑屏,而且不会报任何错。
a=control是另一个重灾区。每个媒体段都要有一个 control 标识,客户端会拿它去拼 SETUP 的 URL。这个标识可以是相对的(比如trackID=0),也可以是绝对的完整 URL。相对标识更灵活,但要求客户端和服务端的拼接规则一致;绝对标识更省事,但服务端得知道自己对外的地址,在有反向代理或者多网卡的场景下容易出错。我一般用相对标识,同时把服务端的 URL 解析做得宽容一些,尾部斜杠、大小写、查询参数都做标准化处理再匹配。
音视频双流的场景还要注意 SDP 里的时间基准。视频时钟 90000,音频常见 48000 或 44100,两路时间戳的量纲不一样,客户端做同步的时候依赖 RTCP 的 SR 包把 RTP 时间戳映射到统一的墙上时间。这就意味着服务端在发 RTCP SR 的时候必须带上正确的 NTP 时间戳和对应的 RTP 时间戳,否则客户端做音画同步就没有依据,表现出来就是唇音不同步,而且越播越偏。
注意:很多轻量实现为了省事完全不发 RTCP,只发 RTP。单流纯视频场景下这样勉强能用,但一旦有音频、或者客户端依赖 RTCP 做抖动缓冲和丢包统计,问题就会集中爆发。我的建议是 RTCP 至少要支持 SR 和 RR,成本不高,收益很大。
3. 传输通道与数据分发:真正决定体验的部分
3.1 UDP 与 TCP 交织的取舍逻辑
RTSP 协商传输方式的时候,服务端要能同时支持 UDP 和 TCP 交织,并且根据客户端请求做出选择。这两种方式没有绝对优劣,关键看部署环境。
UDP 的优点是延迟低、没有队头阻塞,一个包丢了就是丢了,后续包照常到达,客户端靠 RTP 序列号自己处理丢包。缺点是过 NAT 和防火墙麻烦,需要客户端和服务端之间打通一组端口,而且 RTCP 还要单独一组端口,端口数量翻倍。在公网或者复杂内网环境里,UDP 打不通是常态。
TCP 交织的做法是把 RTP 和 RTCP 数据直接塞进 RTSP 的那条 TCP 连接里,用$符号加通道号加长度前缀做帧定界。这样做的好处是只需要一条 TCP 连接就能穿透绝大多数网络环境,不需要额外开端口。代价是 TCP 的重传机制会带来队头阻塞,一旦网络抖动导致丢包,后续所有数据都要等重传,延迟会累积,严重的时候会看到画面"顿一下然后快进"。另外 TCP 连接本身有发送缓冲区,如果服务端写得太快而客户端消费不过来,缓冲区会堆积,内存会涨,延迟也会涨。
实际工程里的策略通常是:优先 UDP,失败或客户端显式要求时降级到 TCP 交织。服务端在 SETUP 阶段解析 Transport 头,按客户端给的顺序一路尝试,第一个能用的就采纳,并在响应里明确告知。这里有个细节,如果客户端请求 UDP 但服务端因为端口耗尽之类的原因分配不了,不要直接断开,应该返回 461 并附上服务端支持的传输方式,让客户端重新发起 SETUP。这样一次完整的降级流程就能在协议层内完成。
| 对比维度 | UDP 传输 | TCP 交织 |
|---|---|---|
| 延迟特性 | 低,无队头阻塞 | 有队头阻塞风险 |
| NAT 穿透 | 需要额外端口映射 | 单连接即可穿透 |
| 丢包处理 | 依赖客户端基于序列号恢复 | TCP 保证有序,但会累积延迟 |
| 服务端内存压力 | 较低 | 发送缓冲区可能堆积 |
| 适用场景 | 局域网、可控内网 | 公网、跨网段、复杂网络 |
3.2 RTP 打包:时间戳和序列号是命门
RTP 打包看着机械,但它是整个数据面正确性的基础。每一路媒体流对应一个 SSRC,这个值是随机生成的,用来在复用场景下区分不同的源。序列号从随机值开始,每发一个包递增一,客户端靠它检测丢包和乱序。时间戳的增量则是采样点数,不是毫秒。视频 90kHz 的时钟下,一帧 25fps 的画面,帧间隔对应的时间戳增量是 90000/25 = 3600。这个换算如果搞错,客户端算出来的帧间隔就不对,表现出来就是播放速度异常。
音频的时间戳更要注意。AAC 常见的采样率是 44100 或 48000,一个 AAC 帧通常是 1024 个采样点,所以每帧的时间戳增量就是 1024,跟实际时长无关。如果中间有编码参数变化导致帧长变化,时间戳增量要跟着变,不能用固定值。
还有一个容易被忽略的点是分片。一帧 H.264 数据如果超过 MTU,需要按 RFC 6184 的方式做 FU-A 分片,每个分片都有自己的 RTP 头,但时间戳相同,只有 Marker 位在最后一个分片上置 1。分片大小要留出 IP 和 UDP 头的余量,常见做法是把单包负载控制在 1400 字节以内。分片做得不对,客户端解码就会报错,表现为花屏或者整帧丢弃。
3.3 多客户端分发:引用计数与共享缓冲
一台服务器要同时服务多个客户端的时候,分发逻辑的设计直接决定了资源占用。最朴素的做法是每个客户端都独立读一遍媒体源,这在文件点播场景下还行,但如果是实时源,比如一个摄像头一路流,那就是 N 倍的开销,很快就会撑不住。
合理的做法是源共享 + 引用计数。服务端为每个媒体源维护一个读取实例和一份环形缓冲,第一个客户端订阅时启动读取,后续客户端直接挂到这同一个实例上,只维护各自的发送游标。当最后一个客户端 TEARDOWN 时,引用计数归零,读取实例停止并释放。这套模型的难点在于缓冲的管理:缓冲开太小,慢客户端会追不上,导致数据被覆盖;缓冲开太大,内存占用高,延迟也大。
我的经验是缓冲深度按"最慢客户端的可接受延迟"来定。比如设定 2 秒缓冲,那就按码率乘以 2 算出缓冲字节数,再加一定余量。同时要给每个客户端设置一个落后阈值,一旦某个客户端的发送游标落后于最新数据的距离超过缓冲深度,说明它已经跟不上了,这时候要么丢帧追上去,要么把这个客户端踢掉。前者体验好一些,后者更稳妥,具体看业务场景。实时监控场景我倾向于丢帧,点播场景倾向于放慢一点让客户端缓过来。
提示:共享缓冲一定要用无锁的环形结构或者读写分离的设计,发送侧只读、读取侧只写,用原子游标同步。如果用互斥锁把整个缓冲锁住,并发一高就会成为瓶颈,而且容易出现某个慢客户端拖住所有客户端的情况。
4. 媒体源接入:幕后的搬运工决定了上限
4.1 源类型与解复用的处理策略
RTSP 服务器背后的媒体源五花八门,常见的有本地文件、实时采集设备、上游推流、转封装后的网络流。不同源的处理方式差别很大,服务端需要有清晰的抽象层。
本地文件是最简单的,关键是解复用。一个 MP4 或者 TS 文件里通常有视频轨和音频轨,需要先解析出轨道信息,拿到编码参数、时长、关键帧索引,才能在 DESCRIBE 阶段生成正确的 SDP,在 PLAY 阶段按时间区间精确读取。这里最重要的是关键帧索引,因为客户端从任意时间点开始播放时,必须从该时间点之前最近的一个关键帧开始发,否则解码器没有参考帧,画面会花。所以服务端在建索引的时候要把每个关键帧的时间戳和文件偏移都记下来,PLAY 时二分查找定位。
实时采集设备的特点是数据源源不断,没有明确时长,时间戳由设备或采集模块生成。这时候服务端要处理的是时间戳的连续性和单调性。有些设备在启动或者断线重连之后时间戳会跳变,服务端必须做归一化,否则客户端收到的 RTP 时间戳会突然倒退或者大幅跳跃,播放直接乱掉。我的做法是在服务端维护一个基准时间戳,对外发送的时间戳都基于这个基准做增量计算,设备原始时间戳只作为内部参考,这样即使设备侧有抖动也不会传导到客户端。
上游推流接入的场景,服务端实际上同时扮演了接收方和分发方。接收环节要处理的是解析推上来的封装格式、校验数据完整性、处理推流中断。分发环节就是前面说的共享缓冲加多客户端订阅。这里的坑在于推流端的编码参数可能中途变化,比如分辨率切换、SPS/PPS 更新,服务端要能识别并在合适的时机通知客户端,通常是通过 SDP 更新或者带内参数集插入的方式。如果处理不好,客户端会在一段时间后突然黑屏。
4.2 转码与转封装的取舍
服务端要不要做转码,这是个典型的成本与兼容性的权衡。转码意味着解码再编码,CPU 开销大,延迟也会增加,但好处是能适配不同客户端的解码能力和带宽。转封装则是只换容器不换编码,开销小得多,但要求客户端支持原始编码格式。
我的判断逻辑是:如果目标客户端都是受控的、能力已知的,优先转封装,尽量不动编码;如果需要对接各种来源不明的客户端,或者需要做多档码率适配,才考虑转码。而且转码最好做成按需触发,只有当客户端的请求参数和源参数不匹配时才启动转码实例,匹配的话直接走透传。这样大部分流量走的是低成本路径,只有少数特殊请求才付出转码代价。
转封装里最常见的场景是 H.264 裸流或者 TS 封装转成 RTP 发送。这个过程中要处理的是 Annex-B 起始码和 AVCC 长度前缀两种格式的转换,以及 SPS/PPS 的提取和注入。H.264 在文件里通常是长度前缀格式,而 RTP 打包要求的是 Annex-B 风格的裸 NALU,这个转换做错了,客户端收到的就是一堆垃圾数据。
4.3 按需拉流与预加载的平衡
服务端什么时候启动媒体源读取,这是个影响资源利用率的决策。全预加载的意思是所有配置的流一启动就全部拉起来,好处是客户端来的时候响应快,坏处是大量没人看的流也在占用带宽和 CPU。按需拉流是客户端订阅时才启动,省资源,但第一个客户端会等待更久,而且如果多个客户端几乎同时来,还要处理启动竞态。
我一般用的是按需加短暂保持的策略:第一个客户端订阅时启动,最后一个客户端离开后不立即停止,而是等一个可配置的宽限期,比如 30 秒,期间如果又有客户端来就直接复用,超过宽限期才真正停止。这样既避免了频繁启停,又不会让闲置流长期占用资源。宽限期的长短要按业务特点调,点播场景可以短一些,直播监控场景可以长一些。
竞态的处理也要注意。两个客户端几乎同时请求同一路流,如果两个线程都判断"当前没有读取实例"然后各自去创建,就会出现两个实例,资源翻倍。解决办法是给每个媒体源加一把创建锁,或者用原子状态机做"未启动/启动中/已启动"的三态转换,启动中的请求等待而不是重复创建。
5. 并发模型、鉴权与稳定性兜底
5.1 线程模型的选择与取舍
RTSP 服务器的并发模型基本就三种:每连接一线程、事件循环加少量工作线程、以及异步框架。每连接一线程写起来最直观,但连接数一上去线程切换开销就压不住了,而且每个线程的栈空间也是实打实的开销。事件循环模型能扛很高的连接数,但代码复杂度高,尤其是发送逻辑里有阻塞操作的时候容易把整个循环卡住。
我实际用下来比较稳的是混合模型:网络 IO 用事件循环,协议解析和状态机在循环线程里跑,耗时的媒体读取和转码放到独立的工作线程池,通过队列和回调交互。这样既保证了 IO 的高效,又不会因为媒体处理阻塞控制面。关键是队列要做容量控制,工作线程处理不过来的时候要有明确的背压策略,比如拒绝新的订阅请求,而不是无限堆积任务。
不管哪种模型,有一条红线不能碰:绝对不能在 RTSP 请求处理路径上做阻塞的媒体操作。我见过有实现直接在 PLAY 的处理函数里去打开文件、读关键帧、初始化解码器,结果一个慢磁盘就把整个服务器的响应能力拖垮了。正确的做法是 PLAY 只做状态变更和指令下发,实际的数据准备在发送器侧异步完成,首帧还没准备好的时候客户端会短暂等待,但不影响其他请求。
5.2 鉴权与会话安全边界
RTSP 的鉴权机制跟 HTTP 类似,支持 Basic 和 Digest。Basic 是明文传输用户名密码,安全性差,只适合完全可信的内网。Digest 通过 nonce 和哈希避免明文传输,是更常见的选择。服务端在需要鉴权的时候返回 401 并带上WWW-Authenticate头,客户端用凭据计算响应后重发请求。
实现上要注意 nonce 的管理。nonce 不能是固定值,否则重放攻击就没有门槛了;但也不能每次请求都换,那样客户端每次都要重新计算,某些客户端会处理不好。常见做法是 nonce 带时间戳和签名,有效期设置成一个合理区间,比如几分钟,过期后返回 401 让客户端重新认证。同时要维护一个已用 nonce 的记录或者依赖时间戳判断,防止重放。
会话本身也要有防串号的设计。Session ID 必须是足够随机的,不能是可预测的递增整数,否则攻击者可以猜测别人的会话 ID 直接劫持。同时服务端要校验请求里的 Session 和客户端来源是否一致,虽然 RTSP 没有强制的来源绑定机制,但至少可以在会话创建时记录对端地址,后续请求地址不一致时给出告警或者直接拒绝。
5.3 超时、心跳与资源回收
RTSP 会话是有生命周期的。服务端在 SETUP 的响应里会带一个Session头,后面跟着timeout参数,告诉客户端这个会话多少秒没有活动就会被回收。客户端有义务在这个时间内发送保活请求,通常用 GET_PARAMETER 或者 OPTIONS。服务端要维护每个会话的最后活动时间,定时扫描过期会话并清理。
这里最常见的线上问题是:客户端其实还活着,但在保活上偷懒或者实现有 bug,导致会话被服务端回收,客户端那边还以为是网络问题,一直重连。表现出来的现象就是"每隔一段时间断一次"。排查的时候看服务端日志,会看到会话过期清理的记录,而客户端那边的保活请求根本没有发出来。解决办法要么是服务端把 timeout 调大,要么是在客户端侧修保活逻辑。我一般会把 timeout 设成 60 秒左右,并且在自己可控的客户端里确保 30 秒左右发一次保活,留足余量。
资源回收的完整性是另一个容易出问题的地方。一个会话涉及的东西包括:TCP 连接、UDP 端口、发送器实例、共享缓冲的引用、可能的转码实例、文件句柄。TEARDOWN 的时候这些都要按依赖顺序释放,任何一个漏掉都会累积成泄漏。我的做法是给会话对象实现一个统一的销毁流程,把所有资源挂在会话下面,销毁时统一遍历释放,并且加上泄漏检测,在压测环境里跑长时间后检查句柄数和内存曲线。
注意:超时清理和客户端主动 TEARDOWN 可能同时发生,要保证销毁流程是幂等的。我见过因为并发销毁导致重复释放、程序崩溃的案例,加一把会话级的锁或者用引用计数配合原子状态标记,能避免这类问题。
6. 常见问题与排查实录
6.1 从现象倒推:几条固定的排查路径
线上问题排查最怕没有章法,东看一点西看一点,时间全浪费了。我总结了几条固定的路径,按现象分类,基本能覆盖八成以上的情况。
客户端连不上或者卡在某个方法上,先看控制面。抓包或者看服务端日志,确认请求有没有到达、服务端有没有返回、返回的状态码是什么。如果请求到了但没返回,大概率是处理逻辑阻塞了,去看线程栈。如果返回了 4xx,按状态码定位:404 多半是 URL 匹配问题,454 是 Session 不存在或者已过期,455 是状态机拒绝,461 是传输参数不支持。这几个码能覆盖大部分控制面故障。
能连上但画面不出来,先看 SDP。确认 DESCRIBE 返回的 SDP 里m=行、a=rtpmap、a=fmtp、a=control四个字段是否完整正确,尤其是 H.264 的sprop-parameter-sets有没有带上。再看 SETUP 的响应里 Transport 是否和请求匹配,端口或者通道号有没有回带正确。如果这几步都对,再去抓 RTP 包看有没有数据发出来、序列号和时间戳是否正常递增。
画面出来但花屏或者卡顿,基本就是数据面的问题。花屏通常是分片处理错误、关键帧丢失、或者 SPS/PPS 没有正确注入导致的。卡顿要看是周期性卡还是随机卡:周期性卡往往和关键帧间隔、缓冲区大小有关;随机卡可能是网络丢包或者发送阻塞。这时候抓 RTP 序列号看丢包分布,看服务端发送队列的积压情况,基本能定位到是网络问题还是服务端发送能力不足。
音画不同步是单独一类问题,根因基本都指向 RTCP SR 的缺失或者时间戳映射错误。检查服务端有没有定期发 SR,SR 里的 NTP 时间和 RTP 时间戳是否对应同一时刻。如果没有 SR,客户端只能靠自己的估算做同步,误差会随时间累积。
| 现象 | 优先排查方向 | 高频原因 |
|---|---|---|
| 卡在 SETUP 无响应 | 传输参数解析、端口分配 | Transport 头格式未兼容、端口耗尽 |
| PLAY 返回 455 | 会话状态机 | 重复 PLAY、会话已过期、SETUP 未完成 |
| 有响应但黑屏 | SDP 内容、RTP 首包 | 参数集缺失、control 标识不匹配 |
| 花屏 | 分片、关键帧 | FU-A 分片错误、从非关键帧起播 |
| 周期性卡顿 | 缓冲与发送节奏 | 缓冲过小、发送线程阻塞 |
| 音画不同步 | RTCP SR | SR 未发送、时间戳基准不一致 |
| 每隔一段时间断连 | 会话保活 | 客户端未发心跳、timeout 过短 |
| 并发升高后崩溃 | 资源回收、并发安全 | 句柄泄漏、重复释放、锁竞争 |
6.2 压测与可观测性:上线前必须做的事
功能跑通只是起点,真正决定这套服务器能不能用的,是压测和可观测性。压测要看的不只是"能扛多少个连接",更要看连接数上升过程中各项指标的变化曲线。我关注的核心指标包括:每路流的发送码率是否稳定、发送队列的积压深度、单连接的 CPU 占用、内存增长趋势、以及首帧耗时。
首帧耗时特别值得单独盯。它受很多因素影响:媒体源的启动速度、关键帧的等待时间、SDP 的生成、发送器的初始化。我见过首帧耗时从几百毫秒到好几秒不等的实现,差距主要在于有没有做关键帧预缓存。如果服务端在启动源读取的时候就缓存最近一个关键帧,新客户端进来可以立刻从这个关键帧开始发,首帧时间能压到很低。不做这个缓存,就得等下一个关键帧,如果关键帧间隔是 2 秒,那平均首帧时间就是 1 秒。
可观测性方面,至少要有的东西是:每个会话的生命周期日志、每个方法的请求响应日志、RTP 发送统计(包数、字节数、丢包重传情况)、以及资源使用情况。日志要有 trace 标识能把一次会话的所有请求串起来,不然并发场景下日志就是一团乱麻。指标要能按流、按客户端维度聚合,出问题的时候能快速定位到是全局问题还是个别流的问题。
6.3 几条踩过才知道的经验
最后分享几条我觉得文档里基本不会写、但实际很值钱的经验。
第一条,别迷信"标准兼容"。RTSP 的客户端实现质量参差不齐,有些设备发出来的请求头大小写混乱、格式不标准、甚至缺字段。服务端的解析器要做得宽容一些,该标准化的地方做标准化,该容错的地方容错,但拒绝的时候要明确,不要含糊地返回一个 200 然后什么都不做。含糊的兼容比明确的拒绝更难排查。
第二条,给每个可配置项都留一个合理的默认值,并且在文档里写清楚什么场景该改。我见过太多因为 timeout 设得太短、缓冲设得太小导致的"玄学问题",最后发现都是配置不当。默认值应该按最常见的场景调优,特殊场景再改。
第三条,把会话 ID 和媒体源的标识打在每一行关键日志里。排查问题的时候,你手上往往只有一个客户端的反馈时间和一个模糊的现象描述,能靠日志快速圈定是哪个会话、哪路流,效率差十倍。
第四条,首帧和关键帧的处理值得单独写测试用例。这两个地方出问题的概率极高,而且一旦出问题就是"完全不可用"级别的,不是性能问题。多花点时间在这块的单元测试和集成测试上,回报很高。
第五条,如果你用的是现成的流媒体组件做二次开发,先把它的会话管理逻辑读一遍,搞清楚它在什么情况下会回收会话、什么情况下会拒绝请求。很多"诡异"的问题根源都在组件的默认行为上,不看源码永远猜不到。
详解：原理、实现与应用场景)
