接手一个把几十路网络摄像机接进内部平台的活儿时我原以为最难的是解码和转码。结果真正让我连着熬了三个晚上的是RTSP 服务器逻辑这套看着简单、实际处处是坑的交互流程——OPTIONS 回了、DESCRIBE 也回了、SETUP 也对上了PLAY 之后画面就是不出来偶尔出来了跑两分钟开始花屏再偶尔一切正常但客户端一多内存跟开了闸一样往上飙。这些问题没有一个是协议字段写错了能概括的绝大多数是逻辑层的取舍出了问题会话该活多久、RTP 怎么打包、多路客户端怎么共享同一路源、丢包了要不要补、缓冲堆多深。这篇就把这套逻辑摊开讲从状态机到打包从并发布局到排查手段都是能直接抄进项目里的东西。适合谁看正在写流媒体接入网关的、要对接摄像机/NVR 的、做录播和转发服务的、以及被拉流卡顿花屏折磨过的后端和嵌入式同行。我尽量不写成协议手册字段细节只挑那些真正影响代码结构的讲剩下的你自己查 RFC 更快。1. 先把 RTSP 服务器想清楚它到底在解决什么问题1.1 控制面与数据面分离这是理解一切的起点RTSP 本身不传流它只是个遥控器。真正跑数据的是 RTP控制反馈走 RTCP媒体描述走 SDP。我第一次写的时候栽就栽在这——以为 PLAY 之后服务器要用 RTSP 这条连接把视频数据吐出去结果客户端一直等到超时。不是的。RTSP 只负责告诉对端准备好收、往哪个端口收、什么时候开始、什么时候停、什么时候拆。数据走的是另一条通道要么是独立的 UDP 端口对要么是复用同一条 TCP 连接做交织。这个分离带来的第一个结构性决策就是连接对象和会话对象必须是两个独立的东西。连接是 TCP 层面的——一个 socket、一个读缓冲、一个解析状态、一个待发送队列会话是媒体层面的——一个媒体源引用、一组接收端、一个播放状态、一个鉴权上下文。一条 RTSP 连接上可以挂多个会话一个会话理论上也能被多条连接引用。你要是在代码里把这两者揉进同一个结构体后面加同一路流被多个播放器拉、播放中途客户端重连这类需求时会非常难受基本等于重写。还有一个新手常犯的错把 RTSP 当成长连接推送协议来设计想着服务器主动往里灌数据。它不是。RTSP 的每条请求都是独立的、带 CSeq 的服务器必须能对同一会话并发处理多条请求或者至少保证不串号。真机上有客户端会在 PLAY 的同时发 GET_PARAMETER 保活你要是单线程串行处理又没有队列CSeq 就会对不上客户端直接判定协议错误。注意别用一个全局大锁把整个服务器串起来。RTSP 请求本身很轻每秒撑死一两条但 RTP 是每秒几百上千个包锁粒度搞错表现就是单路流畅、十路卡死。1.2 一个最小可用的 RTSP 服务器需要哪几块拼图我习惯把它拆成六块缺一块就会在某个具体场景里露馅。这张表是我自己项目里的模块划分你可以对照着看自己缺哪块模块核心职责缺了会怎样连接管理socket 生命周期、读缓冲、请求头解析大包被截断、粘包解析出错会话管理session id、超时、状态机、鉴权上下文客户端重连后状态错乱、旧会话泄漏媒体源管理流的注册/查找/下线、源与订阅者关系源重启后客户端拉不到SDP 生成媒体描述、编码、参数集、控制属性客户端解析失败根本不发 SETUPRTP 打包发送分片、时间戳、序号、发送队列花屏、卡顿、延迟越拉越大RTCP 处理SR 发送、RR 接收、NTP 同步音视频不同步、丢包无从反馈前四块是逻辑后两块是数据。绝大多数人写的第一个版本逻辑部分能跑通数据部分全是暗病——因为逻辑错误会立刻报错数据错误只是画面上偶尔闪一下很难定位。所以下面篇幅会明显往数据面倾斜。1.3 先确定你的服务器是哪种角色再谈实现这一步很多人跳过直接开写写到一半发现方向不对。RTSP 服务器至少有三副面孔逻辑差别很大第一种拉流服务端Play 模式。你持有媒体源客户端来 DESCRIBE、SETUP、PLAY你往外推 RTP。摄像机接入网关、NVR 对外提供流都是这种。核心难点是一路源对多个客户端的分发。第二种推流服务端Announce/Record 模式。客户端 ANNOUNCE 一段 SDP 过来SETUP 协商好然后 RECORD由客户端往你这里灌 RTP你负责收、解包、落地或转出。核心难点是接收侧的重排序、丢包检测和参数集缓存打包逻辑反过来变成了拆包逻辑。第三种中转/级联。一路进来、多路出去典型的是把摄像机流分发给多个下游。它实际上是前两种的组合但在结构上要求你把源和订阅者彻底解耦中间可能还要加一层转封装比如把私有封装转成标准 RTP。我在实际项目里吃过亏一开始只按拉流服务端设计数据结构源对象里直接塞了发送队列。后来要加推流接入发现接收缓冲没地方放只能硬塞越写越乱。后来重构时把**源Source和订阅Subscription**拆开一个源管采集和解封装每个订阅管自己的发送队列和序号状态代码一下清爽了多客户端共享同一路源也变成天然支持的事。2. 协议交互链路拆解从 OPTIONS 到 TEARDOWN 的每一步2.1 方法语义与状态机设计RTSP 的状态机不复杂一共就三个有效状态初始化Init→ 就绪Ready→ 播放中Playing加上暂停回退和拆除终止。但很多人写状态机时把它写成了请求类型判断而不是状态迁移结果就是各种非法序列处理不干净。我推荐的做法是用一张二维表来描述当前状态下收到某个方法该怎么响应代码里就是查表 分发。方法Init 状态Ready 状态Playing 状态说明OPTIONS200200200任何时候都回列出支持的方法DESCRIBE200 SDP200 SDP200 SDP幂等别限制状态SETUP200 → Ready200可重协商455 或 200同一会话重复 SETUP 要谨慎PLAY454200 → Playing200已经播放中再 PLAY 也回 200PAUSE455455200 → Ready很多客户端不发但要支持TEARDOWN200200200必须无条件清理GET_PARAMETER200200200最常用的保活手段SET_PARAMETER200200200部分客户端用来设置静音等几个实际踩过的点DESCRIBE 不要限制状态有些客户端会在 PLAY 之后重新 DESCRIBE 用于刷新信息PLAY 在播放中重复收到要回 200 而不是报错否则某些播放器会直接判定断流TEARDOWN 必须无条件成功哪怕会话已经超时被清理也要回 200回 454 会让客户端重试白白占资源。状态迁移本身还要配套一个非法请求的统一处理CSeq 缺失、Session 头无效、URL 不匹配这几种要回 400 而不是 500。很多人一律回 500客户端日志里一片报错排查起来很费劲。2.2 SDP 协商描述写不好后面全白搭SDP 是整个链路里最容易被低估的一环。我见过太多服务器逻辑没毛病就是拉不出画面的案例最后定位到 SDP 里的acontrol少了一个斜杠客户端拼出来的 SETUP URL 根本不存在。一个视频流的典型描述长这样我按行解释v0 o- 1234567890 1 IN IP4 0.0.0.0 sLive cIN IP4 0.0.0.0 t0 0 acontrol:* mvideo 0 RTP/AVP 96 artpmap:96 H264/90000 afmtp:96 packetization-mode1;sprop-parameter-setsZ0LAHtkDxWhAAAADAEAAAAwDxYuS,aMuMsg acontrol:trackID0o行的会话 ID 和版本号建议用时间戳 递增计数器别用固定值某些客户端会缓存c写0.0.0.0是标准做法表示地址由传输层决定实际地址在 SETUP 的 Transport 头里再定mvideo 0里的端口写 0因为端口要到 SETUP 才协商。afmtp里的sprop-parameter-sets是 SPS 和 PPS 的 Base64 编码逗号分隔这是能否出首帧的关键。如果客户端拿不到参数集它就无法初始化解码器表现就是连接正常、有 RTP 包、画面全黑。我的做法是源对象里常驻缓存最近一次的 SPS/PPSDESCRIBE 时直接填进去如果源还没出关键帧就先回 SDP 但不给参数集等出了第一个 I 帧再补——但更稳妥的是等参数集就绪再允许 DESCRIBE 成功宁可让客户端多等两百毫秒。acontrol有两种写法*表示聚合控制trackID0表示单轨控制。SETUP 时客户端会把 URL 拼成rtsp://host/path/trackID0你的 URL 路由必须能解析出这个后缀。我一般把acontrol显式写成完整的相对路径避免客户端拼接规则不一致。音频轨要额外注意maudio 0 RTP/AVP 97配artpmap:97 MPEG4-GENERIC/44100/1和afmtp:97 streamtype5;profile-level-id1;modeAAC-hbr;sizelength13;indexlength3;indexdeltalength3;config1210。config字段就是 AudioSpecificConfig 的十六进制写错一个字节声音就是噪音。2.3 会话标识、超时与心跳最容易埋雷的地方Session ID 的生成规则没什么讲究但要求两点全局唯一和不可预测。我用的是随机 8 字节 单调计数器再转换成十六进制字符串长度控制在 16 位以内太长有些老客户端会截断。超时是重灾区。SETUP 的响应里必须带超时Session: 1A2B3C4D;timeout60这个 60 是秒意思是客户端 60 秒没有任何请求服务器就可以回收会话。客户端收到后会按这个节奏发保活。但实际环境里各种客户端的保活行为差异极大有的每 25 秒发一次 GET_PARAMETER有的 50 秒发一次 OPTIONS还有的完全不发只在 PLAY 之后一路收数据。如果你严格按超时清理那些不发保活的客户端会在 60 秒后被你踢掉用户看到的就是看一分钟必断。我的处理是把收到 RTCP RR也算作保活。客户端在收流时必然周期性发接收报告这本身就是活着的最好证明。实现上每次收到该会话的 RTCP 包就刷新一下最后活跃时间比等 RTSP 请求可靠得多。提示清理会话的定时器不要用每个会话一个定时器线程几百个会话就是几百个线程。用一个时间轮或者 1 秒一跳的扫描任务扫一遍所有会话判断超时成本可以忽略。2.4 鉴权与 URL 路由别等到上线才补鉴权放在哪一层我建议放在DESCRIBE 之前。OPTIONS 不需要鉴权客户端通常拿它探测服务器能力但从 DESCRIBE 开始所有方法都要校验。用摘要认证比明文认证靠谱流程是第一次请求回 401 带WWW-Authenticate客户端用 nonce 算摘要后重发。实现上有两个细节nonce 要带时效比如 60 秒过期过期后回 401 让客户端重新申请qopauth时的计算包含 cnonce 和 nc算错一个字段客户端就一直 401你会以为是密码错其实是算法错。URL 路由则是把rtsp://host:554/live/cam01/trackID0映射到一个具体的源。我一般把路径拆成三段/{业务类型}/{源标识}/{控制后缀}用一个前缀匹配的哈希表找源避免正则匹配带来的开销。找不到源就回 404别回 500——这直接影响客户端重试策略。3. 数据面实现RTP/RTCP 的组织方式决定体验3.1 打包与分片MTU 算不准花屏跑不了RTP 包有大小上限超过 MTU 就要在 IP 层分片一旦分片丢一个就整包废掉。所以应用层必须先分片。算一下以太网 MTU 1500减 IP 头 20、UDP 头 8、RTP 头 12剩 1460。但中间可能有 PPPoE减 8、可能有隧道封装所以实践值取 1400 甚至 1200。我自己的默认值是 1400做成可配置遇到特殊链路再调。以 H.264 为例一个 NAL 单元小于阈值就单包发Single NAL Unit大于就切成 FU-A 分片。FU-A 的规则是原始 NAL 头拆成 FU indicator保留 F 和 NRI类型置 28和 FU headerS 位标记首片、E 位标记末片、原始类型放低 5 位。这里最容易错的是同一帧的所有分片必须共用同一个 RTP 时间戳序号连续递增并且末片要设 M 位Mark bit表示帧结束。搞错了解码器就等着补齐画面卡住不动。// 关键片段FU-A 分片maxPayload 已扣除 RTP 头 bool pack_fu_a(const uint8_t* nal, size_t len, std::vectorPacket out, uint32_t ts, uint16_t seq, uint32_t ssrc, size_t maxPayload) { if (len maxPayload) { Packet p; build_rtp_header(p, 12, nal[0], ts, seq, ssrc, false); p.append(nal, len); out.push_back(p); return true; } const size_t chunk maxPayload - 2; // 扣掉 FU indicator FU header size_t offset 1; // 跳过原始 NAL 头 bool first true; while (offset len) { size_t n std::min(chunk, len - offset); Packet p; // FU indicatorF|NRI 沿用原 NAL 头类型固定 28 uint8_t fu_ind (nal[0] 0xE0) | 28; // FU header首片置 S末片置 E中间类型放低 5 位 uint8_t fu_hdr (nal[0] 0x1F); if (first) fu_hdr | 0x80; if (offset n len) fu_hdr | 0x40; bool last (offset n len); build_rtp_header(p, 12, fu_ind, ts, seq, ssrc, last); p.push(fu_hdr); p.append(nal offset, n); out.push_back(p); offset n; first false; } return true; }H.265 的分片单位是 FU头结构不一样两字节头 三字节 NAL 头拆分别把 H.264 的代码直接改个类型就复用我见过有人这么干结果 265 的流只出第一帧。音频侧则是另一种逻辑AAC 要加 AU-headers-length 和 AU-header 前缀Opus 直接按包发时间戳时钟也不一样。3.2 时间戳、序号与 SSRC每个订阅必须独立这里是我认为整个服务器逻辑里最关键的一条经验当一路源被多个客户端拉取时每个客户端必须拥有独立的序号空间和独立的时间戳基线。原因很简单RTP 的序号是用来检测丢包和重排序的。如果你把同一批包原样复制给三个客户端其中一个网络抖动丢了两个包它的接收报告里就会出现丢包而你无法知道是哪个链路丢的。更严重的是如果某个客户端期待从它 SETUP 时的随机序号开始你给的是源自己的连续序号加解密或者校验严格的客户端会直接丢弃。所以正确做法是源只负责产生逻辑帧带一个单调递增的 DTS 和编码数据每个订阅在发送时自己组装 RTP 头——序号自己加、SSRC 自己生成、时间戳按 90kHz 基准折算。时间戳的换算视频时钟固定 90000Hz一帧的增量是90000 / fps。25fps 就是 360030fps 是 3000。注意这个值必须是整数累加时用整数累加而不是每次用浮点乘浮点累积误差跑几个小时就能导致音视频错位几百毫秒。我的做法是维护一个pts_90k累加器每帧加上帧率对应的整数值遇到非整数帧率如 29.97用分子分母的形式做定点累加。还有一个隐蔽的坑B 帧的时间戳会乱序。有 B 帧的流DTS 是单调的但 PTS 不是。你的发送顺序必须按 DTS但 RTP 时间戳要填 PTS。如果源本身是带 B 帧的你就要在解封装层做 PTS/DTS 分离如果不想处理就在编码参数里关掉 B 帧——绝大多数监控场景根本不需要 B 帧关掉能省一大堆麻烦。3.3 RTCP不发 SR音视频就永远不同步很多人只发 RTP不管 RTCP结果就是音频和视频大概对得上但看久了嘴型会有几百毫秒偏差。根因是没有 SR发送者报告来告诉客户端NTP 时间 X 对应 RTP 时间戳 Y。RTCP SR 里有两个关键字段NTP 时间戳64 位秒的高 32 位 小数低 32 位和对应的 RTP 时间戳。客户端用这两者的映射关系把音频和视频对齐到同一个墙上时间。我一般每 5 秒发一次 SR这个间隔是经验值太频繁占带宽太稀疏客户端同步精度差。发送 SR 的时候要填准packet_count是到此刻为止发送的 RTP 包总数octet_count是载荷字节数不含 RTP 头。这两个值客户端拿去做丢包率估算填错了你会在客户端日志里看到丢包率 300%这种荒唐数字。接收侧也一样重要。客户端发来的 RR 里带丢包率和累计丢包数。我在实际项目里用这个做链路质量监控某个订阅的丢包率连续 5 秒超过 5%就降级——要么把码率上限调低要么把 UDP 切成 TCP 交织。这个自动降级逻辑上线之后用户投诉卡顿的工单少了一大半。3.4 TCP 交织模式不是备胎是刚需UDP 在公网或者复杂内网里经常打不通尤其是客户端在 NAT 后面、或者有防火墙策略。这时要用 RTSP over TCP 的交织模式SETUP 时 Transport 写成RTP/AVP/TCP;unicast;interleaved0-1之后 RTP 数据直接复用到 RTSP 那条 TCP 连接上。格式很简单一个$字符0x24跟着 1 字节通道号、2 字节大端长度、然后是 RTP 包本体。通道号 0 是 RTP1 是 RTCP对应interleaved0-1的约定。实现上有两个必须注意的点第一发送时要保证原子性不能一个线程写 RTP、另一个线程写 RTSP 响应否则字节流交错客户端解析直接崩。要么加发送锁要么用一个统一的发送队列由一个写线程出队。第二TCP 是有背压的客户端处理不过来会导致你的发送缓冲堆积进而让延迟越滚越大。所以交织模式下必须设一个水位线队列超过阈值就丢帧——而且丢的时候要整帧丢不能只丢一半。4. 并发与资源管理多路接入时的稳定性设计4.1 线程模型一连接一线程撑不住但也别一步跨到全异步我试过三种模型说说各自的真实体感。一连接一线程写起来最快跑十路以内没问题。但每路线程里有阻塞读加上每个订阅的定时发送线程数很容易上到几百。上下文切换一多表现就是CPU 不高但就是卡。而且线程栈默认 8MB几百个线程光虚拟内存就吃掉几个 G。IO 多路复用 小线程池这是我现在的默认选择。用一个 epoll或对应平台的等价机制管所有 RTSP 连接和 TCP 交织的数据发送业务逻辑在事件回调里跑重活解封装、转封装丢给固定的几个工作线程。连接数几百、会话数上千CPU 占用很稳。代价是状态机必须写成非阻塞的读缓冲要自己管理——收到半条请求要存着等下一批数据拼起来。每路源一个线程 每订阅非阻塞发送源侧的解封装通常是阻塞式的等下一帧所以给每个源配一个线程是合理的。订阅侧只往队列里塞数据由统一的发送线程出队避免订阅数增长带来线程数增长。这里有个细节发送队列必须是每订阅独立的且容量有上限。我吃过一次亏队列不限长某个客户端网络断了但 TCP 连接还没断数据一直往里堆十分钟后进程内存涨到 4G 被系统干掉。后来加了硬上限按秒数算比如缓存 2 秒的量超了就丢最旧的整个 GOP。4.2 GOP 缓存新客户端接入为什么要等首帧客户端 PLAY 之后如果源当前正在发 P 帧它收到的第一批包全是参考帧缺失的垃圾解码器要么报错要么出绿屏直到下一个 I 帧到来才恢复正常。25fps、GOP 50 的情况下最坏要等 2 秒。用户体感就是点了播放黑屏两秒才出画面。解决方案是在源侧缓存最近一个 GOP 的头从最近一个 I 帧含 SPS/PPS开始缓存遇到下一个 I 帧时清空重置。新订阅接入时先把缓存里的这一组帧按自己的时间戳基线重打包发出去然后接上实时流。这么做有两个副作用要处理第一缓存会带来内存开销一个 4Mbps 的流缓存 2 秒就是 1MB几十路就是几十 MB可接受但要设上限比如最多缓存 60 帧或者 2MB超了就从中间截断只保留 I 帧和参数集其余丢弃让客户端自己等下一个 I 帧。第二缓存帧的时间戳要整体平移让第一帧的 PTS 成为该订阅的基线否则客户端会认为你的时间戳倒退直接重置。4.3 定时器、超时与资源回收服务器里跑着的定时任务至少有四类会话超时清理、RTCP SR 周期发送、发送队列水位检查、源的存活探测。这四类都别用独立线程 sleep一是精度差二是数量一多就乱。我的做法是一个 100ms 粒度的调度轮把所有定时任务注册成下次执行时间 回调每轮扫一遍到期就执行。会话超时用 1 秒粒度就够了SR 用 5 秒水位检查用 20ms——不同粒度可以在同一轮里做只要记录上次执行时间。资源回收的重点是引用计数。源被订阅引用订阅被连接引用任何一环提前释放都会导致野指针而这种崩溃往往延迟几分钟才发生堆栈完全对不上。我的经验是源只由源管理器持有连接只持有订阅的 ID 而不是指针所有跨线程访问都通过 ID 查表 加锁。多一层间接但换来的是不会莫名其妙崩。5. 常见问题与排查技巧实录5.1 拉不出画面先分清是信令问题还是数据问题排查顺序我固定成三步看 RTSP 交互有没有走完、看 RTP 有没有到、看包内容对不对。信令层面最常见的三个错误一是 SDP 的acontrol和后缀路由对不上客户端 SETUP 到你没实现的路径回 404二是 Transport 头解析时没处理client_port和interleaved二选一的情况导致回应里给的端口跟客户端期待的不一致三是 Session 头没在 SETUP 响应里返回客户端后续请求带的是空 Session被判定为非法。数据层面如果抓包能看到 UDP 包往外发但客户端不显示画面八成是 SPS/PPS 没给对。这时候去对比一下实际流的 SPS 和你 SDP 里写的 Base64 是否一致。有个很隐蔽的坑SPS 长度必须按 4 字节对齐的 Base64 编码中间不能有换行多个参数集用逗号分隔——某些编码器输出的 SPS 里带了 emulation prevention 字节直接 Base64 会错要先还原。5.2 花屏、绿屏、马赛克几乎都是打包问题按出现规律可以快速定位现象大概率原因排查手段整块绿、只有部分区域对SPS/PPS 中的分辨率/裁剪参数与实际流不符对比参数集与解码输出尺寸随机位置马赛克几秒后恢复分片丢包MTU 太大导致 IP 分片把打包阈值降到 1200 试试固定位置一直花某个 NAL 单元被截断或长度算错检查 FU-A 末片 E 位和长度字段画面卡住不动日志无异常分片时 M 位没设解码器等帧结束核对末片的 Mark bit首帧黑之后正常GOP 缓存没从 I 帧开始检查缓存重置逻辑的触发条件我印象最深的一次某型号编码器输出的 SPS 里带了 VUI 参数我们的解析器只认固定长度把后面的 PPS 吃掉了导致部分通道花屏、部分正常因为分辨率不同。定位方法是把原始码流 dump 出来用通用工具解一遍确认码流本身没问题再逐个字段比对。5.3 延迟越跑越大一定是缓冲在偷偷累积这个问题特别典型刚开始延迟 200ms看半小时变成 5 秒。根因永远是某一级缓冲只进不出。第一处检查发送队列。如果你用阻塞写或者不设上限网络慢一点队列就开始涨。加水位线超了就丢整帧别心疼——对实时监控来说旧画面比没画面更糟糕。第二处检查源侧的采集缓冲。有些解封装接口默认带深度缓冲你读得慢它就攒着读到的是几十秒前的数据。要么把缓冲深度设成 0 或 1要么每次读之前判断时间戳落后超过阈值就跳到最新。第三处检查TCP 交织模式下的内核发送缓冲。这个最阴因为你在应用层看不到。判断方法是看SO_SNDBUF相关指标或者干脆在应用层做端到端延迟测量——发送时记录帧的采集时刻客户端如果能配合上报接收时刻差值就是真实延迟。我一般会在测试阶段用这个办法量一遍确认延迟稳定在 300ms 以内才敢上线。5.4 内存缓慢上涨多半是会话没回收干净跑了三天内存涨 200MB重启就好这种问题最难查。我总结的排查清单会话表只增不删超时清理任务因为异常没跑起来或者判断条件写错比如用创建时间而不是最后活跃时间。订阅没解绑客户端断连后 TCP 连接被回收了但订阅还挂在源上源的订阅列表越来越长。缓存无上限GOP 缓存、参数集缓存、日志缓冲任何一个没有上限都会慢慢涨。RTCP 统计表只增不减每个订阅维护的丢包统计如果按 SSRC 建表而不清理长跑必涨。我的做法是在服务里内置一个/stats之类的内部接口输出当前连接数、会话数、订阅数、各队列深度、缓存字节数。上线后每天看一眼曲线比出事之后再查强一百倍。6. 落地经验与参数速查6.1 参数表这些值我基本不调了参数推荐值理由RTP 打包上限1400 字节兼容 PPPoE 和常见隧道封装会话超时60 秒兼顾客户端保活差异和资源回收速度SR 发送间隔5 秒同步精度与带宽的平衡点GOP 缓存上限2MB 或 60 帧首帧等待与内存的折中订阅发送队列2 秒的帧量超时即丢防止延迟累积定时器粒度100ms足够覆盖所有周期任务请求头大小上限8KB防止恶意大包打爆内存TCP 交织写超时5 秒超时即判定客户端僵死并断开这些值不是拍脑袋来的每一条背后都对应过一次线上问题。比如那个 8KB 的请求头上限是有客户端在 GET_PARAMETER 里塞了超长的自定义头直接把解析缓冲区撑爆进程段错误。加了上限之后回 414客户端乖乖降级。6.2 日志与观测出了问题能自己说话RTSP 服务器的日志有几个原则按会话打标签、按阶段记录、错误带上下文。我一般每条日志前缀带会话 ID 的前 8 位这样一条链路上的 DESCRIBE、SETUP、PLAY 能串起来看。必打的几个点SETUP 成功时记录协商出的传输方式和端口PLAY 成功时记录当前 GOP 缓存状态是否命中、从第几帧开始每 10 秒打一条统计发送包数、字节数、队列入队/出队速率、丢弃帧数断开时打一条汇总持续时长、平均码率、丢帧总数。这套日志在排查时太值钱了。有一次用户反馈某路流看几分钟就断日志里那条会话的汇总显示播放 65 秒、丢帧 0、发送正常——那就是客户端主动断的问题在客户端侧省了我半天的排查。最后分享一个小技巧也是我这些年最受用的一条任何实时流系统都要给自己留一条可以绕过所有缓冲的通路。调试时用它验证源是否正常比一层层怀疑中间环节快得多。我通常会在源对象上加一个直通模式把解封装出来的一帧直接吐到本地文件或者发给一个固定地址确认码流没问题后再回头查分发逻辑。这个开关平时关着出事时一开基本五分钟能定位到底是谁的锅。