监控画面要同时给客户端、大屏、手机和上级平台看，前端摄像机扛不住一路路直接取流，这时候需要一个转发的中间层：流媒体转发服务器。它一边从设备取流，一边按需分发。本文讲清楚它解决什么问题、并发与带宽怎么估算、转码要不要上 GPU、单机还是集群，参数与指标以具体产品和实测为准。
TL;DR
- 转发服务器的价值：设备只出一路流，多终端按需取流，还能统一协议与转码。
- 带宽估算按单路码率乘并发路数，再留冗余，监控场景用主码流标称码率打底。
- 转码量小走 CPU 软转，并发转码路数上量后上 GPU 硬转更划算。
- 规模增长走集群：接入与分发分离，先单机再扩边缘节点。
- 先定观看端用哪种协议，再选支持的服务器，别让协议选择倒逼业务。
转发服务器到底解决什么问题
- 多路并发取流：几十上百个客户端同时看，由服务器统一取流分发，保护前端设备与链路带宽。
- 协议统一：设备出 RTSP 或 GB28181，客户端要 HLS、FLV，服务器做转封装与输出。
- 转码适配：不同终端屏幕与带宽不同，服务器转出多档码流。
- 鉴权与审计：播放权限在服务器侧控制，访问有记录。
并发与带宽怎么估算
带宽是转发服务器的硬约束，估算口径：所需带宽约等于单路码率乘并发路数，再留冗余。
| 参数 | 参考口径 |
|---|---|
| 单路码流 | 1080P 主码流常见 4Mbps 上下，具体看设备码流设置 |
| 冗余系数 | 预留约 1.2 倍，应对峰值并发 |
| 计算示例 | 100 路并发按 4Mbps 计，约需 400Mbps 出口带宽，再乘冗余 |
算完之后还要看端口速率与带宽是独享还是共享，转发服务器的瓶颈常常在出口带宽而不是 CPU。
转码：软转还是硬转
转码是把一路流变成多档输出的过程，算力消耗在流媒体链路里排在前列。
| 路线 | 优势 | 代价 | 适用 |
|---|---|---|---|
| CPU 软转 | 画质与压缩率可控，灵活 | 单位路数算力成本高 | 转码路数少的场合 |
| GPU 硬转 | 单卡并发路数高，单位成本低 | 画质略逊，需显存与授权 | 并发转码路数上量后 |
经验参考：单路 1080P 转 H.264 软转约需 2 到 4 个物理核心，转 H.265 需求更高；并发转码超过十路上下，就要评估 GPU 方案。具体以服务器性能实测为准。
单机还是集群
小规模单机即可：一台服务器完成接入与分发。规模上来之后，把接入与分发拆开：源站负责取流接入，边缘节点面向用户分发，用户增长时加边缘节点，不压源站。
- 单机：几十路以内，部署简单，先跑起来。
- 接入与分发分离：源站加边缘，播放压力被分散。
- 多源站加边缘：跨区域或高可用要求高时，增加接入冗余。
监控场景与直播场景的差异
监控转发与直播点播看着像，规划口径差别不小。
| 维度 | 监控转发 | 直播点播 |
|---|---|---|
| 流来源 | 摄像机按需取流 | 推流端持续推送 |
| 并发特征 | 观看路数相对可控 | 观看着波动大 |
| 码率口径 | 主码流标称码率打底 | 按清晰度档位估算 |
| 时延要求 | 调阅回放可容忍缓冲 | 直播对延迟更敏感 |
常见误区与避坑
- 只算服务器 CPU 不算出口带宽：并发观看一多，带宽先顶不住。
- 协议选型被客户端倒逼：先想终端用什么播放，再定服务器支持面。
- 转码全开不做档位规划：无差别转多档，算力与存储一起浪费。
- 忽略运维接口：看不到在线会话与转发状态，出问题难定位。
集群的引入顺序有讲究：先把单机的转发会话与带宽摸清楚，确认瓶颈在带宽还是算力，再决定加边缘节点还是加源站。多数成长型项目从单机起步，随业务量自然演进，比一步到位上集群更稳妥。转发服务器的选型指标不是拍脑袋定的：并发上限、转码路数、带宽口径都有产品参数可对，采购前让厂商按你的实际场景给一份并发压测结果，比只看纸面参数可靠。
选型自检清单
| 检查项 | 核对口径 |
|---|---|
| 并发目标 | 明确同时观看路数上限，反推带宽 |
| 协议支持 | 前端接入协议与终端输出协议都对得上 |
| 转码需求 | 定好转码路数与档位，算好算力 |
| 高可用 | 关键业务是否需要主备或集群 |
| 运维能力 | 是否便于查看状态、会话与配置管理 |
转发服务器选型先把给谁看、多少人看、什么协议看三个问题想清楚，带宽和算力按需求倒推，方案不会跑偏。
参考资料
- rtsp-udp-tcp-transport-selection
- gb28181-platform-cascade