HTML5播放RTSP抓包分析技巧

HTML5浏览器原生不支持RTSP协议，所谓“HTML5播放RTSP”实质是依赖服务端转流（如转为FLV、HLS或WebRTC）或前端JS库（如flv.js、mpegts.js）实现的间接方案，因此Wireshark抓包看到的几乎总是HTTP、WebSocket、DTLS/SRTP等替代协议，而非原始RTSP；真正捕获原生RTSP交互需绕过浏览器，直接用ffplay或vlc命令行工具连接设备，并配合Wireshark过滤554端口流量，同时注意RTSP明文传输、端口识别和SDP解析等关键细节——理解这一底层转换逻辑，才是高效分析和排障的核心。

HTML5 本身不支持 RTSP，抓包前先确认协议转换是否已做

浏览器原生 标签完全不解析 rtsp:// 地址，直接写 src="rtsp://..." 不会触发任何网络请求，自然也抓不到 RTSP 流。真正能抓到 RTSP 通信的，只可能是前端通过 WebSocket、WebRTC 或自定义 JS 库（如 ffmpeg.wasm、hls.js 配合转流服务）间接发起的底层连接——而这些连接往往早已不是 RTSP 协议本身。

所以第一步必须搞清：你看到的“HTML5 播放 RTSP”，背后实际走的是什么？常见路径有：

• RTSP 流被服务端（如 nginx-rtmp-module、GB28181-SIP server、ffmpeg + nginx + http-flv）转成了 flv、hls 或 webrtc offer/answer
• 前端用 mpegts.js 或 flv.js 加载 HTTP-FLV 或 MPEG-TS，此时抓的是 HTTP 流，不是 RTSP
• 用 WebRTC 接入（如通过 janus-gateway 或 mediasoup），实际走的是 DTLS/SRTP，Wireshark 里看不到明文 RTSP

Wireshark 抓 RTSP 交互，关键看 TCP/UDP 端口和协议识别

如果真有设备或网页在发原生 RTSP 请求（比如某些 IPC 厂商提供的 Web SDK 内嵌了轻量 RTSP 客户端），那它大概率走的是 TCP 554 或 UDP 554。Wireshark 能识别 RTSP，但需要满足两个条件：

• 流量没加密（RTSP 本身无 TLS，rtsps:// 极少见且 Wireshark 需导入证书才能解密）
• Wireshark 的协议解析器没被干扰（例如端口被误标为 HTTP，可右键封包 → “Decode As…” → 强制设为 RTSP）

典型 RTSP 握手包包含 OPTIONS、DESCRIBE、SETUP、PLAY，每条都带 CSeq 序号和 Session ID。注意：DESCRIBE 返回的 SDP 里会声明 RTP 端口（如 m=video 0 RTP/AVP 96），后续音视频数据才从那些端口收发——这部分是 RTP/UDP，Wireshark 默认也能解析，但需确保没丢包、没乱序。

Chrome DevTools 看不到 RTSP 请求，但能验证是否被降级成其他协议

Network 面板过滤 ws、flv、m3u8、api/forward 这类关键词，比盯着 rtsp 有用得多。真实案例中，很多所谓“HTML5 RTSP 播放器”实际做了如下操作：

• JS 发起 fetch("/api/start?stream=cam1")，后端返回一个 ws://xxx/flv?token=... 地址
• 页面用 flv.js 连这个 WebSocket，之后所有数据都是二进制 FLV Tag，跟 RTSP 协议无关
• 控制台报错 Failed to execute 'fetch' on 'Window': Invalid URL，可能是因为你把 rtsp:// 直接传给了 fetch() ——这根本不会发出去

此时在 Network 面板看到的是 ws 或 http 请求，状态码 101 或 200，Response 是空或二进制。别浪费时间右键“Copy as cURL”——它复制不出 RTP 包。

想分析原始 RTSP 流，绕过浏览器直接用 ffplay 或 vlc 抓更可靠

浏览器只是个障眼法。真要验证设备是否输出标准 RTSP，最简单方式是跳过前端，用命令行工具直连：

ffplay -v verbose rtsp://192.168.1.100:554/stream1

加 -v verbose 会打印完整握手过程，包括服务器返回的 SDP 和实际使用的 RTP 端口。再配合 Wireshark 过滤 ip.addr == 192.168.1.100 and (tcp.port == 554 or udp.port == 554)，就能干净地看到 OPTIONS/PLAY 流程。如果 ffplay 成功但网页失败，问题一定出在中间转流环节（比如 Nginx 配置漏了 rtmp_auto_push on），而不是抓包姿势不对。

RTSP 的麻烦从来不在抓包，而在它天生不适合浏览器——每个厂商的 SDP 扩展、RTP 负载类型、时间戳基点都可能不同，同一套抓包结果，换台摄像头就可能解析失败。

理论要掌握，实操不能落！以上关于《HTML5播放RTSP抓包分析技巧》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！