做过监控项目的人多半遇到过这样的场景：一个摄像头，自己在手机上看画面很流畅，可一旦保安室、经理办公室、手机端同时接入十几路观看，画面立刻卡成幻灯片，甚至摄像头直接掉线。这背后的根本原因，就是摄像头自身的出流能力有限，而这个问题恰恰是流媒体服务器要解决的核心场景。监控系统到底有没有必要部署流媒体服务器，不能一概而论，得看并发规模、观看方式和延迟要求，下面把整个来龙去脉掰开讲清楚。
先搞清楚：摄像头直接出流到底撑不住在哪里
一台普通的网络摄像头，本质上是一个小型的嵌入式设备，内部硬件资源非常有限。它的主要工作是采集图像、编码压缩，然后通过网络把码流吐出去。厂家设计时通常只考虑了少量并发访问，一般摄像头同时支持的连接数在3到5路之间，部分工业级设备能到10路左右。一旦超过这个上限，新的连接要么被拒绝，要么所有连接集体卡顿。
举个具体例子：一台1080P的摄像头，主码流按4Mbps计算，如果有8个人同时直接连接这台摄像头取流，摄像头就要承担32Mbps的出口带宽和8路编码分发任务。别小看这个数字，很多摄像头的网口是百兆的，但内部的总线、内存和处理器根本扛不住持续的多路分发，CPU占用飙高之后连编码本身都会受影响，出现画面花屏、丢帧甚至重启。
除了并发瓶颈，直连摄像头还有一个很现实的问题：观看端必须和摄像头在同一网络环境里能直接访问。摄像头通常使用RTSP协议出流，而浏览器原生不支持RTSP，手机端也各有各的限制。如果要让外网用户、浏览器用户都能看，就必须有一个中间层做协议转换，这个中间层就是流媒体服务器的职责之一。
流媒体服务器做了什么：分发、转码、协议适配
流媒体服务器的核心思路很简单：从摄像头拉一次流，然后分发给N个观看者。摄像头只需要承担1路连接的压力，剩下的分发工作由服务器完成。服务器的硬件资源远比摄像头强大，一台普通配置的服务器分发几十上百路观看毫无压力，这就从根本上解决了多用户观看的问题。
第二个职责是协议转换。监控系统常见的协议有RTSP、GB28181、RTMP、HLS、HTTP-FLV、WebRTC等，各自的适用场景完全不同。RTSP适合内网低延迟直连，HLS兼容性最好但延迟高，WebRTC延迟最低但部署复杂。流媒体服务器可以把摄像头的一路RTSP流转成多种协议输出，让手机、浏览器、大屏各取所需。以常见的ZLMediaKit为例，一套配置就能同时提供这些能力：
# 通过FFmpeg从摄像头拉流，转成RTMP推给流媒体服务器 ffmpeg -rtsp_transport tcp -i "rtsp://admin:password@192.168.1.64:554/stream1" \ -c copy -f flv rtmp://127.0.0.1/live/camera01 # 观看端可以按需选择协议 # RTMP播放: rtmp://服务器IP/live/camera01 # HTTP-FLV播放: http://服务器IP/live/camera01.flv # HLS播放: http://服务器IP/live/camera01/hls.m3u8
注意上面的命令用了-c copy，表示直接拷贝码流不重新编码，这样服务器压力最小。只有在需要改变分辨率或编码格式时才做转码，比如把H.265流转成H.264给老设备看，转码非常消耗CPU，一台服务器能转的路数有限，规划容量时要算清楚。
延迟问题：协议选择比服务器本身更关键
很多人以为上了流媒体服务器延迟就会变大，其实不一定。延迟主要取决于传输协议和缓冲策略，而不是有没有服务器。各类协议的典型延迟水平大致如下：WebRTC可以做到200到500毫秒，RTSP和RTMP在1秒左右，HTTP-FLV在1到3秒，HLS最差，动辄5到20秒。监控场景里如果用HLS做实时观看，操作员看到画面时现场可能已经发生好几秒了，这对安防来说往往不可接受。
所以选型时要想清楚哪些流需要低延迟，哪些无所谓。实时监看用RTMP或HTTP-FLV，甚至WebRTC；录像回放、移动端弱网观看用HLS反而更稳，因为HLS基于HTTP分片，天然能穿透各种网络环境。流媒体服务器支持按需输出多种协议，正好能把这两类需求分开处理，这比直连摄像头灵活得多。
缓冲参数也值得调一调。播放器端的缓冲区设得越大越抗网络抖动，但延迟随之增加。有些流媒体框架允许配置GOP缓存（gop cache），开启后新加入的观看者能立即出画面，代价是增加了最多一个GOP长度的延迟。摄像头端建议把GOP设置为帧率的两倍，比如25fps就设GOP为50，这样在延迟和秒开体验之间能取得平衡。
常见部署方案与容量估算
实际部署一般有三种形态。第一种是单服务器集中分发，适合几十到一两百路的小型项目，一台4核8G的服务器跑ZLMediaKit或SRS就够用。第二种是级联扩容，观看人数多时部署多台分发节点，源节点只推流给各分发节点，分发节点再服务各自的观众。第三种是CDN方案，面向大规模公网分发的场景，比如直播性质的监控画面公开观看。
容量估算抓住两个数字就行：带宽和并发路数。带宽方面，出口带宽要大于观看人数乘以单路码率，比如100个人看4Mbps的流，理论上需要400Mbps出口，这时往往得靠多节点分摊。并发方面，不转码只做协议转换的分流非常轻量，单机几百到上千路没问题；一旦涉及转码，就按每路转码占用的CPU核数来算，一台8核服务器大概能扛十几路1080P软转码。
另外提一个容易忽略的点：按需拉流。很多监控平台默认把所有摄像头全部拉到服务器上，哪怕没人看。几百路摄像头全量拉流，服务器和带宽白白消耗。更好的做法是配合流媒体服务器的无人观看自动断流功能，有人请求时才去摄像头拉流，空闲一段时间后自动释放，资源利用率能提升一个量级。
常见问题与注意事项
第一是花屏和卡顿问题。如果用UDP方式拉RTSP流，网络稍有丢包就花屏，解决办法是强制TCP传输，比如FFmpeg加-rtsp_transport tcp参数。第二是公网安全问题，流媒体端口直接暴露公网很容易被扫描盗流，务必开启鉴权，播放地址加token校验，或者用on_play回调做权限控制。第三是时间戳问题，多路流经过服务器中转后音画不同步或者画面跳跃，一般是时间戳被重写导致的，排查服务端的戳相关配置。
第四是和NVR的关系。很多项目里录像由NVR负责，流媒体服务器只做实时分发，两者互不冲突，实时观看走流媒体服务器，回放走NVR，这是比较合理的分工。别让流媒体服务器兼任录像，虽然技术上可行，但会大幅增加磁盘IO压力，稳定性不如专业的录像设备。第五是国产化对接，如果项目要求接入国标平台，那就得选支持GB28181的服务器，比如ZLMediaKit配合wvp-GB28181-pro，这一套组合在国内监控项目里用得非常多。
总结一下判断标准：观看并发超过5路、需要外网或浏览器访问、需要多协议适配、需要大规模扩容，满足任何一条，流媒体服务器就是必要的；如果只是一个人在内网偶尔看看，直接连摄像头反而更简单。技术选型没有绝对的好坏，关键是让方案匹配实际规模，小项目硬上重型架构是浪费，大项目没有分发层则是灾难。