一、为什么一半的键是端口

每转一种协议就要开一个服务：RTSP 给播放器、HLS 给浏览器、FLV 给低延迟、RTMP 给推流。 四个协议就是四套逻辑、四个端口、四份维护面。 一套出问题就是一个功能不可用。 所以小项目常常只开两种：RTSP 加 HLS，够用且稳定。 FLV 是为了低延迟，RTMP 是为了给别人推流——不需要就别开。 端口多还有一层隐患是「端口冲突」：同一台机器上如果还跑着别的东西，很容易撞上。 所以规划时要把「这一段归媒体用」写进文档。

二、两个数决定项目预算

max_stream 是这个 SMS 最多同时转多少路。 两百路 4 Mbps 就是八百兆比特每秒——已经吃掉一块千兆网卡八成。 所以「一路流占多少带宽」这个问题，答案是「乘上并发数才成立」。 单看一路觉得不多，乘上两百就吓人了。 第二个数是保存天数。 两百路、每小时 1.84 GB、存三十天，就是两百多 TB。 这个数字比「服务器多少钱」更能决定预算， 而且它是「越往后越贵」的——因为盘会满，满了就要加盘或者缩短天数。 所以验收时最该吵清楚的两件事就是这两个数，而不是「界面好不好看」。

三、录像路径的三个坑

第一个坑是权限：服务以哪个用户跑，那个用户就得对目录有写权限。 没权限的表现是「录像列表有、点开是空的」。 第二个坑是磁盘满：满了之后不是「停止录像」而是「录像损坏」， 因为文件头写进去了、数据没写全。 第三个坑是「路径带中文或空格」：有些组件拼路径时不转义，直接报错或者写到别处去。 三个坑的共同点是「不报错、只是不对」，所以只能用「录一段、播一下」这种笨办法验证。

四、动手 Demo：LiveSMS 的配置为什么比 CMS 长

解析 SMS 的示例配置，数一数有几个键是端口，再算并发路数带来的带宽和存储。

cp = configparser.ConfigParser()
cp.read_string(SMS_INI)
n = sum(1 for k in cp.options("sms") if "port" in k)
print("键数", len(cp.options("sms")), "其中端口", n)

print("200 路 × 4 Mbps = %.1f Gbps" % (200 * 4.096 / 1))
print("200 路 30 天 = %.1f TB" % (200 * 1.84 * 24 * 30 / 1000))

实跑输出：

--------------------------------------------------------------------
LiveSMS 的配置为什么比 CMS 长
--------------------------------------------------------------------
**SMS 管媒体，所以它的配置项大多是「端口」和「资源上限」。**
**CMS 那份只有十来个键，SMS 这份要多一倍。**

  键                     值
  ----------------------------------
  **http_port**          `10100`
  **rtp_port_start**     `30000`
  **rtp_port_end**       `40000`
  **rtsp_port**          `10554`
  **hls_port**           `10800`
  **flv_port**           `10801`
  **rtmp_port**          `10935`

  解析出 10 个键，其中 7 个是端口

**一眼看过去全是端口**，**因为每转一种协议就要开一个服务**：
**RTSP 给播放器、HLS 给浏览器、FLV 给低延迟、RTMP 给推流。**

**转的协议越多，能接的客户端越多，但维护面也越大**：
**四个协议就是四套逻辑，一套出问题就是一个功能不可用。**
**所以小项目常常只开 RTSP 加 HLS 两种。**

**资源上限那几个键最容易被忽略**：
  `max_stream = 200` 是这个 SMS 最多同时转 200 路
  200 路 × 4 Mbps = 0.8 Gbps

**八百兆比特每秒**——**已经吃掉一块千兆网卡八成。**
**所以「一路流到底占多少带宽」这个问题，答案是「乘上并发数才成立」。**

**`record_keep_days` 决定存储**：
  200 路 × 1.84 GB/小时 × 24 小时 × 30 天 = 265.0 TB

**两百多 TB**——**这个数字比「服务器多少钱」更能决定项目预算。**
**所以配置项里最该反复确认的不是端口，是这两个数：并发路数和保存天数。**

十一个键里有七个是端口，这个比例很能说明 SMS 的性质： 它是一台「协议转换器」，一转就开一个口。 并发那一行算出来是八百多兆——两百路就把一块千兆网卡吃掉八成。 所以「加机器」通常不是为了 CPU，是为了网卡。 存储那一行算出两百六十多 TB，这个数字是很多项目「做着做着超预算」的根源： 设备报价很显眼，存储报价很隐蔽。 最后那句「验收时最该吵清楚两个数」是经验之谈： 并发路数和保存天数一旦定了，后面所有设计都跟着定。 定晚了就要返工。

30 秒实验

1. 算一下：200 路 4 Mbps 一共多少带宽？（约 820 Mbps）
2. 想一下：为什么小项目常常只开 RTSP 和 HLS？
3. 想一下：磁盘满了会「停止录像」还是「录像损坏」？（损坏）

常见误区

1. 以为「端口开得越多越好」。 一套协议一套维护面，不需要就别开。
2. 以为「并发路数只影响 CPU」。 先撞墙的往往是网卡。
3. 以为「磁盘满了会自动停录」。 常见结果是录像文件损坏。

下一节讲运行：启动之后先看哪几个数，排障顺序是什么。

• ☐ （本节完，下一节 11.02.04 LiveSMS的运行）

相关笔记

• LiveCMS的配置文件
• LiveSMS的运行
• LiveGBS的服务架构
• 30 课 · 流媒体直播原理
• 📹 视频监控与国标 · 索引