LiveGBS 拆成两个进程：LiveCMS 管信令和业务，LiveSMS 管媒体。 这个拆分和「按负载拆」的原则完全对得上——CMS 一台够，SMS 按路数加。
上一节讲组网，这一节开始看具体软件。 LiveGBS 是国内用得比较多的一套开源国标平台，它的进程划分很典型，看懂了别的也差不多。 注意：沙箱里装不了这套软件，所以这一章讲的是「结构和配置」，不是「手把手安装」。
一、两个进程，各管一段
LiveCMS 管信令和业务：SIP 注册、目录、点播信令、数据库、网页接口，全在它这儿。 LiveSMS 管媒体：收 RTP、转 RTSP／HLS／FLV／RTMP、录像是。 两者之间靠内部 HTTP 通信： CMS 收到点播请求，算出「该由哪台 SMS 收流」，再让前端去那台 SMS 取流。 所以 SMS 是可以横向加机器的，只要 CMS 知道每台 SMS 的地址和余量。 这就是「能扩容」的具体实现方式。
二、流地址不是固定的
这个架构有个必然的副作用：「流地址」是每次点播现算的，不是固定 URL。 因为 CMS 要先决定「由哪台 SMS 收」，才能给出地址。 所以外部系统不能「拼一个 URL 一直用」。 这一点和很多人对「监控流地址」的印象不一样： RTSP 摄像头的地址确实是固定的，但国标平台的地址不是。 正确用法是「每次先调接口拿地址」， 拿到之后再用，而且这个地址有有效期——会话断了地址就作废。
三、端口怎么规划
信令和 HTTP 各一个 TCP 端口，媒体是一段 UDP。
端口的算法是「每路两个」：RTP 一个、RTCP 一个。
所以「能撑多少路」这个问题的答案，先看端口段有多大，再看带宽和 CPU。
一万个端口理论上五千路，实际按一半规划——因为端口回收有时滞，一路流断了端口不会立刻还回去。
还有一点很容易被忘：端口段要写进 SDP 的 m= 里，会话中途改不了。
所以「不够了临时加一段」在国标里是很麻烦的操作，规划时宁可多划。
四、动手 Demo：LiveGBS 的两个进程怎么分工
列两个进程的端口和职责，再算端口段能撑多少路。
start, end = 30000, 40000
print("端口数", end - start + 1)
print("每路两个 → 理论", (end - start + 1) // 2, "路")
print("留一半余量 → 建议", (end - start + 1) // 4, "路")
实跑输出：
--------------------------------------------------------------------
LiveGBS 的两个进程怎么分工
--------------------------------------------------------------------
**LiveGBS 拆成两个进程**：**LiveCMS 管信令和业务，LiveSMS 管媒体。**
**这个拆分方式和上一节说的「按负载拆」完全对得上。**
进程 占用端口 干什么 扩容方式
---------------------------------------------------------------------------------------------
**LiveCMS** **SIP、HTTP、数据库** **注册、目录、点播信令** **轻，一台够**
**LiveSMS** **RTP、RTSP、HLS、FLV** **收流、转协议、录像是** **重，按路数扩**
**两者之间的接口是「内部 HTTP」**：
**CMS 收到点播请求，算出「该由哪台 SMS 收流」，再让前端去那台 SMS 取流。**
**所以 SMS 是可以横向加机器的**，**只要 CMS 知道每台 SMS 的地址和余量。**
**这个架构有个必然的副作用**：**「流地址」不是固定的，是每次点播现算的。**
**所以外部系统不能「拼一个固定 URL 就一直用」**，**必须每次先调接口拿地址。**
**端口规划要提前做**：
信令 1 个 TCP 端口，HTTP 1 个
媒体要一段 UDP 端口，按「每路 2 个」估
200 路并发 → 至少 400 个端口，留一倍余量 → 800 个
**「每路两个端口」是因为 RTP 和 RTCP 成对**，**一收一发算一路。**
**所以 30000 到 40000 这一万个端口，理论上能撑五千路**——
**但实际要留出重启、重连的余量，一般按一半算。**
一万个端口、理论五千路、建议两千五——这三个数之间的差距不是保守，是「端口回收时滞」。 如果按理论值卖方案，现场跑到一半就会「端口分配失败」。 「每路两个端口」这件事值得记：RTP 和 RTCP 成对，一个送数据一个送统计。 所以看防火墙规则时，不能只放奇数或只放偶数。 两个进程的分工还带来一个运维习惯： 排障先看 CMS 还是先看 SMS，取决于「问题在哪一类」——注册不上看 CMS，点播黑屏看 SMS。 这比「一上来就抓包」快得多，因为抓包只能告诉你「没收到」，不能告诉你「谁该发」。
30 秒实验
- 算一下：一万个 UDP 端口，理论能撑多少路？（五千）
- 想一下：为什么国标平台的流地址不是固定的？
- 想一下：「注册不上」和「点播黑屏」分别该看哪个进程？
常见误区
- 以为「LiveGBS 是一个程序」。 CMS 和 SMS 是两个进程，可以分机部署。
- 以为「流地址可以拼出来固定用」。 每次点播现算，还有有效期。
- 以为「端口段按理论值算就够」。 要留一半余量，因为回收有时滞。
自测三问（点开对答案）
1. LiveCMS 和 LiveSMS 各管什么？ —— **CMS 管信令和业务，SMS 管媒体收流与转协议**。 2. 为什么 SMS 能横向扩容？ —— **它不存业务状态**，**CMS 只要知道每台的地址和余量就能调度。** 3. 为什么端口段要留一半余量？ —— **端口回收有时滞**，**流断了端口不会立刻还回去。**下一节看配置文件：CMS 那份只有十来个键，但每一个都不能错。
- ☐ （本节完，下一节 11.02.02 LiveCMS的配置文件）