4、传输协议选型：TCP vs UDP 在图像传输中的取舍、RTSP/RTMP协议详解、MQTT在轻量级场景的应用
各位工程师朋友，这一章我们来聊聊传输协议。说实话，协议选型这事儿，我见过太多人一上来就拍脑袋。有人觉得TCP稳，就全用TCP；有人听说UDP快，就一股脑上UDP。结果呢？要么图像卡成PPT，要么丢包丢到怀疑人生。
我个人习惯是，先搞清楚场景再选协议。你想想看，一个产线上的机械臂视觉引导，和一个远程监控的摄像头，它们对传输的要求能一样吗？
4.1 TCP vs UDP：图像传输中的取舍
先说说TCP。TCP是面向连接的协议，有重传机制，能保证数据不丢、不乱序。听起来很完美对吧？但问题来了——图像传输最怕的不是丢包，而是延迟。
我在项目中遇到过一件事。一个客户要做实时缺陷检测，图像分辨率是200万像素，帧率要求30fps。他们一开始用TCP传输，结果发现画面经常卡住。为什么？因为TCP一旦丢包，就会停下来等重传。这一等，后面的帧全堵住了。你想想看，检测算法等不到图像，整个产线都得停。
核心结论：
- TCP适合：图像需要完整保存、不允许任何像素丢失的场景。比如医疗影像、档案扫描。
- UDP适合：实时性要求高、可以容忍少量丢帧的场景。比如视频监控、机器人视觉引导。
那UDP就没有缺点吗？当然有。UDP不保证数据到达，也不保证顺序。你可能会收到一张缺了半截的图像，或者帧顺序全乱了。怎么办？我一般会在应用层做两件事：
- 加序列号——每帧图像带一个递增的ID，接收端按ID排序。
- 加校验——用简单的CRC校验，发现数据损坏就直接丢弃这一帧，等下一帧。
说白了，UDP是把可靠性交给了应用层。你愿意多写几行代码，就能换来更低的延迟。
我的经验：如果网络环境稳定（比如局域网内），UDP + 应用层重传是个很好的组合。我曾经在一个产线项目里，用UDP传输1080p图像，延迟控制在5ms以内，丢帧率不到0.1%。
4.2 RTSP/RTMP协议详解
聊完底层协议，咱们看看上层协议。RTSP和RTMP，这两个名字你肯定不陌生。但它们的区别，很多人其实没搞清楚。
4.2.1 RTSP：实时流传输协议
RTSP，全称Real Time Streaming Protocol。它本质上是一个控制协议，不是传输协议。什么意思呢？RTSP负责「播放」、「暂停」、「快进」这些操作，而真正的视频数据，是通过RTP（Real-time Transport Protocol）来传的。
我记得有一次，一个客户问我：「为什么我用RTSP拉流，画面总是延迟好几秒？」我一看，他用的是TCP作为RTP的传输层。嗯，问题就在这里。RTSP默认用UDP传RTP数据，延迟很低。但如果网络有防火墙，UDP被堵住了，就会回退到TCP。这一回退，延迟就上去了。
RTSP的典型应用场景：
- IP摄像头、NVR（网络录像机）
- 安防监控系统
- 需要远程控制播放的设备
4.2.2 RTMP：实时消息协议
RTMP是Adobe搞出来的，最初是为了Flash播放器。现在Flash没了，但RTMP还活着。为什么？因为它延迟低、兼容性好。
RTMP基于TCP，但它有自己的打包方式。它会将视频数据切成小块，每个块带一个时间戳。接收端收到后，按时间戳播放。这样做的好处是，即使网络波动，画面也不会突然卡死，而是会「跳帧」——丢掉一些旧帧，追上新帧。
我在做直播推流时，经常用RTMP。它的延迟通常在1-3秒，比RTSP的几百毫秒要差一些，但胜在稳定。而且，RTMP可以穿透大多数防火墙，因为它的端口是1935，很多网络设备默认放行。
| 特性 | RTSP | RTMP |
|---|---|---|
| 传输层 | 通常基于UDP（RTP） | 基于TCP |
| 延迟 | 200-500ms | 1-3秒 |
| 控制能力 | 强（播放、暂停、快进） | 弱（主要是推流/拉流） |
| 防火墙穿透 | 较差 | 较好 |
| 典型场景 | 安防监控、实时视觉 | 直播推流、视频会议 |
注意：RTMP在2020年后，Adobe已经停止更新。但很多开源项目（如nginx-rtmp-module）还在维护。如果你要上新产品，建议考虑WebRTC或SRT等新协议。
4.3 MQTT在轻量级场景的应用
最后聊聊MQTT。你可能觉得，MQTT不是物联网协议吗？跟图像传输有什么关系？
嗯，这里要注意。MQTT确实不适合传大图像，但它非常适合传控制指令和小尺寸图像。
举个例子。我在做一个智能相机项目时，相机每隔10秒拍一张图，然后通过MQTT把缩略图（比如320x240）发到服务器。服务器收到后，判断是否需要抓取全分辨率图像。如果需要，再通过RTSP拉流。这样一来，大部分时间网络只传输几十KB的数据，负载极低。
MQTT的优势在于：
- 轻量级——协议头只有2字节，非常适合低带宽环境。
- 发布/订阅模式——一个相机发图，多个客户端可以同时接收。
- QoS等级——你可以选择「最多一次」、「至少一次」、「正好一次」三种可靠性级别。
我的建议：如果你在做多相机协同的项目，可以用MQTT来传递「触发信号」和「状态信息」。比如，相机A检测到缺陷，通过MQTT通知相机B和C，让它们同时抓拍。这样比用TCP轮询要高效得多。
不过，MQTT也有局限。它的最大消息体通常限制在256MB以内（取决于Broker配置），而且不适合流式传输。你想想看，如果每秒传30帧1080p图像，MQTT肯定扛不住。所以，MQTT适合做「信号通道」，不适合做「数据通道」。
好了，这一章的内容就到这里。总结一下：
- 实时性要求高，用UDP + 应用层控制。
- 需要完整图像，用TCP。
- 视频流传输，RTSP适合低延迟监控，RTMP适合直播推流。
- 轻量级控制和小图传输，MQTT是首选。
下一章，我们会聊聊图像压缩与编码。你可能会问：「压缩会不会影响检测精度？」嗯，这个问题我当年也纠结过。到时候我会分享一些实测数据，咱们下章见。