RTMP推流协议深度解析：从握手到传输的工程实践

1. 什么是RTMP推流？它到底在解决什么问题？

RTMP（Real-Time Messaging Protocol）推流，说白了就是把摄像头、麦克风或者本地视频文件这些“源头活水”，实时、稳定、低延迟地送到远端服务器的过程。它不是简单地把一个大文件拖过去，而是一边采集、一边编码、一边切割成小数据包、一边发出去——整个过程像一条高速运转的流水线，任何一环卡顿，下游观众看到的画面就会卡住、花屏甚至断连。我第一次在某直播平台做技术对接时，客户一句“推流老掉线”，背后其实是采集设备驱动异常、编码器参数失配、网络抖动误判、服务端接收缓冲区溢出等七八个环节同时在“打架”。RTMP之所以至今仍是行业事实标准，并非因为它多先进，而是它用一套极其务实的设计，把“实时性”和“可靠性”的矛盾平衡到了工程落地的临界点：它基于TCP，天然抗丢包；它内置chunk机制，把大帧拆成小块传输，避免单个大包阻塞整条链路；它用时间戳+序列号双保险，让服务端能精准重组音视频流。你不需要懂Flash时代的历史，但必须明白——今天所有看似“新潮”的SRT、WebRTC、HLS，要么在特定场景下替代它（比如WebRTC主打超低延迟互动），要么在它之后接力（比如RTMP推到CDN边缘节点，再转成HLS分发）。真正决定项目成败的，从来不是协议本身多酷炫，而是你是否清楚每个握手包里藏着什么字段、每个chunk头里哪个bit控制着重传逻辑、每次connect命令失败时，到底是认证token过期还是AMF0序列化格式写错了字节。这就像修车，你不需要造发动机，但得知道火花塞间隙不对会导致点火延迟——RTMP推流也一样，它是一套精密但可触摸的工业级协议，而不是一个黑盒API。

2. RTMP推流交互全流程深度拆解

2.1 握手阶段：三次“暗号交换”建立信任基础

RTMP推流不是上来就发视频，而是先完成三次“握手”——Handshake，这是整个流程最易被忽略却最致命的一环。它不走应用层，而是直接在TCP连接建立后，用纯二进制字节流完成三轮交换：C0/C1/C2 和 S0/S1/S2。很多人以为这只是走个过场，直到某次在某高校实验室部署推流系统时，我们发现所有推流端都卡在“Connecting…”状态，抓包一看，S1响应包根本没发出去。排查三天才发现，是防火墙策略误将长度为1536字节的S1包识别为异常流量并拦截。这提醒我：RTMP握手不是HTTP那种明文可读的GET/POST，它的C1包前8字节固定为0x00000000，紧接着4字节时间戳，再后面1520字节是随机生成的key，而S1包必须用这个key做MD5哈希再拼接——整个过程没有一次字符串比较，全是字节对齐与哈希校验。C0是1字节版本号（0x03），C1是1537字节（8+C1Body），C2是1537字节（8+C2Body），S0/S1/S2同理。关键点在于：C1的time字段必须是客户端本地毫秒时间戳，S1的time2字段必须回填C1的time值，否则服务端会判定为非法连接。我实测过，如果C1.time写成0，90%的开源RTMP服务器（如nginx-rtmp）会静默拒绝，连错误日志都不打。这不是bug，是协议设计者刻意为之的防重放机制——时间戳偏差超过5秒即视为无效。所以你在写自定义推流器时，千万别用gettimeofday()直接取值，要先校准NTP时间，再写入C1头。另外，C1的key部分不能全零，必须包含至少16字节有效随机数据，否则某些CDN厂商的边缘节点会触发安全熔断。这些细节在RFC文档里只有一句话带过，但在真实生产环境里，它们就是推流能否启动的第一道闸门。

2.2 连接阶段：AMF0序列化与connect命令的精确构造

握手成功后，客户端要发送第一个AMF0编码的connect命令，这才是真正意义上的“业务连接”。这里踩过的坑最多：有人把app字段写成live，结果推流到rtmp://server/live/stream1却提示“Application not found”，查了半天才发现服务端配置的是application live_app，而app参数必须严格匹配配置名，大小写都不能错。AMF0是一种紧凑的二进制序列化格式，比JSON省30%以上带宽，但调试极不友好。connect命令结构如下：

• 命令名称（String类型）："connect"
• 事务ID（Number类型）：通常为1，用于后续响应匹配
• 对象（Object类型）：包含app、flashVer、swfUrl、tcUrl、fpad、capabilities、audioCodecs、videoCodecs、videoFunction等键值对

其中tcUrl最关键，它必须是完整URL格式，如"rtmp://192.168.1.100:1935/live?token=abc123"，注意问号后的查询参数会被原样透传给服务端，很多鉴权逻辑就靠这个。audioCodecs和videoCodecs是位掩码，比如0x1000表示支持H.264，0x0040表示支持AAC，如果你的编码器只输出H.264但videoCodecs填了0x0001（Sorenson H.263），服务端会直接断连。我曾遇到一个嵌入式设备，固件里videoCodecs硬编码为0x0001，导致无法接入现代CDN，最后只能通过中间代理层动态改写AMF0字节流才解决。connect命令发完，服务端必须返回_result或_error，且事务ID必须一致。_result里会携带fmsVer（服务端版本）、capabilities（服务能力）、level（状态级别）等字段，其中level为status时，code字段值NetConnection.Connect.Success才是真正的成功标志。很多开发者只检查HTTP状态码，却忽略了AMF0响应体里的code字段，导致“看似连接成功，实则被限速”的诡异现象。

2.3 创建流阶段：createStream命令与流ID的生命周期管理

connect成功后，客户端需发送createStream命令来申请一个逻辑流通道。这个命令本身很简单：{"command":"createStream","transactionId":2,"object":null}，但返回的streamId却是整个推流生命周期的“身份证”。它是一个32位无符号整数，服务端分配后，后续所有音视频数据包、publish命令、deleteStream命令都必须携带此ID。关键陷阱在于：streamId不是全局唯一，而是连接级唯一。也就是说，同一个streamId在不同TCP连接里可以重复使用，但绝不能在同一连接内重复调用createStream获取新ID——否则旧流会被强制关闭。某次在某跨平台系统中，前端页面刷新后未主动调用deleteStream，后台又发起新createStream，导致服务端内存泄漏，持续72小时后OOM崩溃。解决方案是：必须在页面卸载前发送deleteStream，且deleteStream命令必须携带之前获得的streamId，否则服务端无法定位目标流。createStream返回的streamId通常从1开始递增，但不要假设它是连续的——某些高并发场景下，服务端可能跳过某些数字以规避冲突。更隐蔽的问题是streamId的字节序：AMF0规定所有Number类型为大端序（Big-Endian），如果你用小端机器（如x86）直接memcpy，会导致streamId解析错误。我写过一个C++推流库，最初用*(uint32_t*)ptr强转，结果在ARM设备上全乱套，改成be32toh(*(uint32_t*)ptr)才稳定。这再次印证：RTMP不是高级协议，它是字节层面的精密协作，差一个bit，整条链路就停摆。

2.4 发布流阶段：publish命令与音视频编码参数的硬性约束

createStream拿到streamId后，终于进入核心动作——publish。命令格式为：{"command":"publish","transactionId":0,"object":null,"streamName":"stream1","type":"live"}。注意transactionId设为0，因为这是单向命令，无需响应。streamName就是最终URL里的路径名，如rtmp://server/app/stream1中的stream1，它必须符合服务端正则校验（常见限制：长度≤64，仅含字母数字下划线）。type字段决定流行为："live"表示实时直播（丢帧不重传），"record"表示录制存档（服务端会写磁盘），"append"表示追加录制。绝大多数场景用live。但真正决定推流成败的，是publish之后紧随其后的元数据（onMetaData）和首帧数据。onMetaData是一个AMF0 Object，必须包含duration（0表示无限长）、width、height、framerate、videocodecid（H.264为7）、audiocodecid（AAC为10）、avcprofile、avclevel、samplerate、samplesize、channels等字段。这里有个致命细节：videocodecid和audiocodecid必须与实际发送的音视频帧Header里的codec ID完全一致，否则服务端会静默丢弃所有后续帧。我曾调试一个FFmpeg推流，发现画面卡在第一帧，抓包发现onMetaData里videocodecid写成6（AVC），但实际H.264 Annex B帧的NALU Header里nal_ref_idc字段被错误置位，导致服务端解析失败。解决方案是：在FFmpeg命令中显式指定-vcodec libx264 -x264opts keyint=60:min-keyint=60:scenecut=0，确保IDR帧间隔稳定，且NALU结构合规。音频同理，audiocodecid为10时，AAC ADTS头必须存在且profile、sampling_frequency_index、channel_configuration字段与onMetaData严格对应。这些参数不是“建议”，而是RTMP服务端解析器的硬性输入契约——错一个，整条流就失效。

2.5 数据传输阶段：Chunk Stream与Message的分层封装逻辑

RTMP真正的数据传输，是建立在Chunk Stream（块流）之上的。它把应用层的Message（如视频帧、音频帧、onMetaData）切割成最大128字节的Chunk（块），再按优先级分发到不同Chunk Stream ID（CSID）上。为什么这么设计？因为TCP是字节流，没有消息边界。如果直接发一个1MB的I帧，网络抖动时整个TCP窗口会被堵死，后续音频包全积压。而Chunk机制让小音频包（通常<200字节）能插在大视频Chunk之间发送，保障音频实时性。Chunk结构分三部分：

• Basic Header（1~3字节）：包含CSID和Format字段。CSID标识块所属的逻辑通道（1-65599），Format决定Chunk Header长度（0=12字节，1=8字节，2=4字节，3=1字节）
• Message Header（0/4/8/12字节）：取决于Format，包含timestamp（相对时间戳）、message length（消息总长）、message type id（如8=音频，9=视频，18=AMF0命令）、message stream id（即createStream返回的streamId）
• Extended Timestamp（0/4字节）：当timestamp>=0xFFFFFF时启用，存储高位时间戳

关键规则：同一Message的多个Chunk必须使用相同CSID，且第一个Chunk（Format=0）必须包含完整Message Header，后续Chunk（Format=1/2）可省略部分字段以节省带宽。我实测过，当设置chunk size为64字节时，一个150KB的H.264 IDR帧会被切成约2343个Chunk，每个Chunk平均耗时0.8ms发送，而设为1024字节时仅需147个Chunk，但单个Chunk发送延迟升至12ms——这就是典型的带宽与延迟权衡。生产环境推荐初始chunk size设为512，再根据网络RTT动态调整：RTT<50ms用256，50-150ms用512，>150ms用1024。另外，CSID分配有约定俗成：2用于协议控制（如set_chunk_size），3用于命令消息（connect/publish），6用于音频，7用于视频，8用于onMetaData。虽然协议没强制，但所有主流服务端（nginx-rtmp、SRS、Wowza）都遵循此惯例，自定义推流器必须对齐，否则服务端无法正确路由。

2.6 心跳与保活：set_chunk_size与ping/pong的生存法则

RTMP连接建立后，若长时间无数据，中间防火墙或NAT设备会自动回收连接。因此必须周期性发送保活包。RTMP提供两种机制：

• set_chunk_size：修改chunk size的命令，本身不携带业务数据，但会触发服务端响应。标准做法是每30秒发送一次，将chunk size设为当前值（如512），服务端收到后回复set_chunk_size确认。
• ping/pong：更轻量的保活，ping是Message Type ID=6的控制消息，payload为2字节时间戳（毫秒），服务端必须回复pong（Type ID=7），payload相同。

我在线上环境发现，单纯依赖ping/pong在弱网下不可靠：某次4G网络抖动，ping发出后3秒未收到pong，但连接状态仍显示“ESTABLISHED”，导致推流无声无画长达2分钟。最终方案是双保险：每25秒发ping，若1.5秒内无pong则立即发set_chunk_size，两者间隔错开5秒。ping的payload时间戳必须是单调递增的，不能重复，否则服务端可能忽略。另外，set_chunk_size的value字段必须是1~2147483647之间的整数，且不能频繁变更（建议变更间隔>10秒），否则某些CDN节点会触发流控。保活不只是“维持连接”，更是健康探测——当连续3次ping超时，客户端应主动断连重试，而不是傻等。我在某安防项目中，把保活超时阈值从5秒降到2秒，配合快速重连（退避算法：1s, 2s, 4s, 8s），使设备离线恢复时间从平均47秒降至6.3秒，客户验收时专门表扬了这点。

3. 核心参数配置与实操避坑指南

3.1 推流端关键参数：从FFmpeg到自研SDK的硬核调优

推流质量70%取决于推流端参数配置，而非服务端。以最常用的FFmpeg为例，一条看似简单的命令ffmpeg -re -i input.mp4 -c:v libx264 -c:a aac -f flv rtmp://server/app/stream，背后有12个关键参数决定成败：

• -re：必须开启，否则FFmpeg会以最快速度“倾倒”文件，导致服务端缓冲区爆炸。它让输入按原始帧率读取，模拟实时采集。
• -vsync 1：强制视频同步模式为“复制”，避免FFmpeg自动插帧/删帧导致时间戳错乱。某次客户投诉“画面快进”，查出是-vsync 0（passthrough）导致B帧顺序混乱。
• -g 60：关键帧间隔（GOP），必须是-r帧率的整数倍。设为60意味着每2秒一个I帧（假设30fps），太小增加带宽，太大导致seek延迟高。直播场景推荐-g 60（2秒）或-g 120（4秒）。
• -keyint_min 60：最小关键帧间隔，防止场景切换时强制插入I帧打乱GOP结构。
• -sc_threshold 0：禁用场景切换检测，避免非预期I帧。
• -b:v 2000k：视频码率，必须与-maxrate配合。单独设-b:v不生效，需加-maxrate 2000k -bufsize 4000k，否则CBR模式会失效。
• -profile:v baseline：H.264档次，移动端兼容性首选baseline（level 3.1），避免main/high档次导致低端手机解码失败。
• -preset veryfast：编码速度与压缩率的平衡点，ultrafast画质损失严重，slow延迟过高，veryfast是直播最优解。
• -tune zerolatency：专为低延迟优化，禁用B帧、减小参考帧数。
• -ar 44100：音频采样率，必须与-ac 2（双声道）匹配，某些服务端对48000Hz支持不完善。
• -acodec aac -b:a 128k：AAC音频，128k是清晰度与带宽的黄金分割点。
• -f flv：强制输出FLV封装格式，RTMP的载体，不可省略。

对于自研SDK，必须手动处理NALU分隔符。H.264裸流以0x00000001或0x000001开头，但RTMP要求每个视频Chunk必须以0x17（I帧）或0x27（P/B帧）开头，后跟时间戳和NALU长度字段。我见过最惨的案例：某团队直接把H.264 Annex B流原样塞进RTMP Chunk，导致服务端解析出数千个“伪I帧”，CPU飙升至100%。正确做法是：先找到0x00000001，跳过4字节，读取NALU类型，再按RTMP规范封装。音频同理，AAC必须去掉ADTS头，只保留原始AAC帧，并在RTMP Chunk Header里标明audiocodecid=10。这些底层细节，决定了你的推流是“能用”还是“好用”。

3.2 服务端配置要点：nginx-rtmp与SRS的差异化实践

服务端选型直接影响推流稳定性。nginx-rtmp模块轻量、成熟，适合中小规模；SRS（Simple Realtime Server）功能更全，支持WebRTC转换。配置陷阱比比皆是：

• nginx-rtmp的live应用配置：

  application live { live on; record off; allow publish all; # 必须显式允许，否则默认拒绝 allow play all; exec_push /usr/bin/ffmpeg -i rtmp://localhost:1935/live/$name -vcodec copy -acodec copy -f flv rtmp://backup-server/live/$name; # 备份推流，但-exec进程崩溃会导致主推流中断 }

  关键点：allow publish必须明确指定IP段或all，否则connect会返回NetConnection.Connect.Rejected。exec_push虽方便，但FFmpeg子进程异常退出时，nginx不会自动重启，需配合supervisord守护。

• SRS的vhost配置：

  vhost __defaultVhost__ { cluster { mode local; } http_remux { enabled on; mount [vhost]/[app]/[stream].flv; } rtc { enabled on; # 启用WebRTC转换 bframe discard; # 丢弃B帧，降低RTC延迟 } }

  SRS的rtc.bframe discard是救命参数——H.264的B帧依赖前后帧，WebRTC传输时若丢包，B帧无法解码，导致花屏。直接丢弃B帧，用P帧替代，画质微损但稳定性飙升。

• 通用陷阱：

  • 时间戳校验：所有服务端默认校验音视频时间戳单调递增。若推流端时间戳跳变（如设备休眠后唤醒），服务端会断连。解决方案是在SDK中加入时间戳平滑算法：记录上一帧时间戳，当前帧若偏差>500ms，则线性插值过渡。
  • 缓冲区溢出：push_reconnect参数决定断连后重推策略，push_reconnect 3s比1s更稳妥，避免网络抖动时高频重连压垮服务端。
  • 鉴权绕过：on_connect和on_publish回调脚本必须用exit 0表示允许，exit 1拒绝。某次因脚本权限问题返回exit 2，服务端静默拒绝，日志只显示“callback failed”。

3.3 网络层调优：MTU、TCP参数与QoS策略的实战选择

RTMP跑在TCP上，网络层配置不当，再好的应用层优化也白搭。某次在某物联网项目中，4G模组推流卡顿，抓包发现大量TCP Retransmission，根源竟是MTU不匹配：模组默认MTU=1500，但运营商APN设置了PPPoE封装，实际可用MTU仅1492。解决方案是：在推流端执行ifconfig eth0 mtu 1492，卡顿立刻消失。TCP参数同样关键：

• net.ipv4.tcp_rmem和net.ipv4.tcp_wmem：分别控制TCP接收/发送缓冲区。直播场景建议设为4096 65536 16777216（min/default/max），避免小缓冲区导致ACK延迟。
• net.ipv4.tcp_slow_start_after_idle：设为0，禁用空闲后慢启动，防止长连接突然提速失败。
• net.ipv4.tcp_congestion_control：BBR算法比Cubic更适合直播，echo "net.core.default_qdisc=fq" >> /etc/sysctl.conf && echo "net.ipv4.tcp_congestion_control=bbr" >> /etc/sysctl.conf。

QoS策略常被忽视。企业内网中，RTMP流量应标记为DSCP=EF（Expedited Forwarding），确保路由器优先转发。Linux下用tc命令：

tc qdisc add dev eth0 root handle 1: htb default 30 tc class add dev eth0 parent 1: classid 1:1 htb rate 100mbit tc class add dev eth0 parent 1:1 classid 1:10 htb rate 50mbit tc filter add dev eth0 parent 1: protocol ip u32 match ip dport 1935 0xffff flowid 1:10

这条命令将所有目的端口1935的流量归入高优先级队列。实测在千兆内网中，开启QoS后，RTMP流在FTP大文件传输时的延迟波动从±80ms降至±12ms。

4. 常见故障排查与独家调试技巧

4.1 连接失败类问题：从抓包到日志的逐层定位法

推流连接失败，90%源于前三步（握手、connect、createStream）。我的标准化排查流程：

1. TCP层确认：telnet server 1935，若不通，检查防火墙、端口、服务进程。
2. 握手层验证：用Wireshark过滤tcp.port==1935 and tcp.len==1537，看C0/C1/C2和S0/S1/S2是否完整往返。若S1缺失，必是服务端未启动或防火墙拦截。
3. AMF0层解析：安装rtmpdump工具，执行rtmpdump -v -r "rtmp://server/app" -o /dev/null，它会详细打印每一步AMF0交互。若卡在Connecting...，说明connect命令未被正确解析。此时用-z参数开启debug，查看connect的AMF0字节流是否符合规范。
4. 服务端日志：nginx-rtmp看error.log，搜索client connected和connect failed；SRS看srs.log，关注RTMP connect和publish事件。某次发现日志里有invalid app name，但推流URL明明正确，最后发现是Nginx配置里application名字末尾多了个空格。

独家技巧：写一个Python脚本，用socket手动发送C0/C1，再解析S0/S1，绕过所有高级库，直击协议本质。这招帮我定位过三次硬件编码器固件bug。

4.2 卡顿与花屏类问题：时间戳、GOP与网络抖动的三角关系

卡顿不是单一原因，而是时间戳、GOP、网络三者的耦合故障。诊断公式：
卡顿 = |推流端时间戳 - 服务端接收时间戳| > 缓冲区阈值

• 时间戳问题：用ffprobe -v quiet -show_entries frame=pkt_pts_time -of csv input.flv提取所有帧时间戳，检查是否单调递增、间隔是否稳定。若出现-1或跳变，必是编码器问题。
• GOP问题：ffprobe -v quiet -show_entries packet=pts_time,duration -of csv input.flv | grep "I"，看I帧间隔是否恒定。若忽大忽小，需检查-g和-keyint_min是否匹配。
• 网络抖动：mtr --report-cycles 100 server，看Loss%和Avg列。若Loss%>1%或Avg>100ms，需优化网络或启用FEC。

花屏90%是NALU损坏。用ffmpeg -i input.flv -c copy -f null -，若报Invalid NAL unit size，说明推流端NALU分隔符错误。此时用hexdump -C input.flv | head -20，检查是否以00 00 00 01开头。

4.3 鉴权与安全类问题：Token时效、HTTPS回调与签名算法的严苛校验

现代推流必做鉴权，常见方案是URL参数?token=xxx或on_connect回调。陷阱在于：

• Token时效：服务端校验token时，必须用UTC时间，而非本地时区。某次客户部署在东八区，token有效期2小时，但服务端用time()获取的时间是UTC，导致token提前16小时失效。
• HTTPS回调证书：on_connect若指向HTTPS地址，服务端必须信任该证书。自签名证书需在nginx配置中添加ssl_trusted_certificate /path/to/ca.crt。
• 签名算法：常见HMAC-SHA256，但密钥拼接顺序极易出错。标准格式：sha256(app + stream + timestamp + secret)，其中app和stream必须URL decode后参与计算，timestamp为10位Unix时间戳。我写过一个校验脚本，发现70%的签名失败是因为前端JS的encodeURIComponent对/编码为%2F，而后端PHP的urldecode未处理，导致app值不一致。

4.4 兼容性问题：老旧设备、浏览器与CDN的隐性协议差异

• Flash遗留问题：某些老CDN仍要求flashVer="WIN 32,0,0,0"，若填"FMLE/3.0 (compatible; Lavf58.12.100)"会被拒绝。
• iOS Safari限制：不支持RTMP直接播放，必须转HLS。SRS的http_remux模块可自动生成.m3u8，但需注意hls_fragment设为2秒，hls_window设为6秒，否则iOS会报MEDIA_ERR_SRC_NOT_SUPPORTED。
• 机顶盒兼容性：某款国产机顶盒只认videocodecid=7（AVC），若推流端误设为12（AV1），画面全黑。解决方案是服务端配置video_codec强制转码，但会增加CPU负载。

5. 实战复现：从零搭建一个可验证的RTMP推流环境

5.1 环境准备：三台机器的最小可行架构

要真正吃透RTMP，必须亲手搭建闭环环境。我推荐三机架构，避免单机自环的干扰：

• 推流端（Ubuntu 22.04）：安装FFmpeg 6.0，用USB摄像头或测试文件推流。
• 服务端（CentOS 7）：部署SRS 5.0，配置vhost支持RTMP和HLS。
• 播放端（Windows 10）：VLC播放器，验证多终端兼容性。

安装SRS：

wget https://github.com/ossrs/srs/releases/download/5.0.0/srs-5.0.0-d7e12a4-ubuntu20.04-amd64.tar.gz tar -xzf srs-5.0.0-d7e12a4-ubuntu20.04-amd64.tar.gz cd trunk ./objs/srs -c conf/srs.conf

关键配置项：

listen 1935; max_connections 1000; srs_log_tank file; srs_log_file ./objs/srs.log; http_api { enabled on; listen 1985; } http_server { enabled on; listen 8080; dir ./objs/nginx/html; } vhost __defaultVhost__ { hls { enabled on; hls_fragment 2; hls_window 6; hls_path ./objs/nginx/html; hls_m3u8_file [app]/[stream].m3u8; hls_ts_file [app]/[stream]-[seq].ts; } }

5.2 推流命令与参数验证：一条命令覆盖所有核心场景

在推流端执行：

ffmpeg -f v4l2 -i /dev/video0 \ -f alsa -i hw:0,0 \ -c:v libx264 -g 60 -keyint_min 60 -sc_threshold 0 \ -b:v 1500k -maxrate 1500k -bufsize 3000k \ -profile:v baseline -level 3.1 -preset veryfast -tune zerolatency \ -c:a aac -b:a 128k -ar 44100 -ac 2 \ -f flv "rtmp://192.168.1.100:1935/live/stream1?token=abc123"

此命令涵盖：

• 实时采集（v4l2+alsa）
• GOP稳定（-g 60）
• 码率控制（-b:v/-maxrate）
• 兼容性（baseline level 3.1）
• 低延迟（-tune zerolatency）
• 鉴权（URL token）

验证方法：

• 服务端tail -f objs/srs.log，确认publish日志。
• 播放端VLC打开http://192.168.1.100:8080/live/stream1.m3u8，观察HLS播放。
• 同时用ffplay -i "rtmp://192.168.1.100:1935/live/stream1"验证RTMP直连。

5.3 故障注入与修复演练：模拟真实世界的10种崩坏场景

真正的掌握，来自亲手制造并修复故障。我设计了10个必练场景：

1. 修改推流端时间戳：在FFmpeg源码中篡改pkt.pts，观察服务端日志如何报错。
2. 伪造错误AMF0：用Python socket发送connect命令，故意把app字段长度写错1字节，看服务端是否返回_error。
3. 网络限速：tc qdisc add dev eth0 root tbf rate 500kbit latency 50ms burst 5kb，测试推流在500Kbps下的表现。
4. 强制关键帧：在推流中插入-force_key_frames "expr:gte(t,n_forced*2)"，验证GOP是否被破坏。
5. 服务端宕机：kill -9 $(pgrep srs)，观察推流端是否自动重连（需FFmpeg加-reconnect 1 -reconnect_at_eof 1 -reconnect_streamed 1 -reconnect_delay_max 5）。
6. 防火墙拦截：`iptables -A OUTPUT -p tcp --