一、为什么我们需要机器学习来做拥塞控制？
传统的拥塞控制算法，比如 GCC、BBR，其实已经做得很好了。但我在实际项目中遇到过一个问题——当网络环境特别复杂时，比如 4G 信号在高铁上剧烈抖动，或者 Wi-Fi 和 5G 频繁切换，这些基于固定模型的算法就开始吃力了。
说白了，传统算法是「猜」网络状态。它通过丢包、延迟这些信号去推测。但机器学习不一样，它是「学」出来的。你给它喂大量数据，它自己就能找到规律。
我个人的经验是：在 30% 丢包率以下，GCC 还能扛；一旦超过 30%，或者延迟抖动超过 200ms，ML 方案的优势就非常明显了。
核心观点：机器学习不是要完全替代传统算法，而是在传统算法「搞不定」的场景下做补充。比如高丢包、高抖动、带宽突变。
二、强化学习在码率控制中的应用
2.1 为什么是强化学习？
你想想看，拥塞控制本质上是个什么过程？是 agent（发送端）在不断观察环境（网络状态），然后做出动作（调整码率），最后获得奖励（流畅度、清晰度）。这不就是标准的强化学习问题吗？
我记得第一次看到这个思路时，觉得特别自然。传统算法里，我们手动写一堆 if-else 规则。强化学习里，这些规则变成了 reward function。
2.2 状态空间、动作空间、奖励函数
我简单拆解一下 RL 的三个核心要素：
| 要素 | 具体定义 | 我的建议 |
|---|---|---|
| 状态空间 | 当前 RTT、丢包率、接收端报告、历史码率 | 不要太多维度，5-8 个就够了 |
| 动作空间 | 码率调整方向：+50kbps、-100kbps、保持不变 | 离散动作比连续动作好训练 |
| 奖励函数 | 流畅度 + 清晰度 - 惩罚项（卡顿次数） | 卡顿的惩罚权重至少是清晰度的 3 倍 |
避坑指南：我曾经把奖励函数设计得太复杂，加了 7 个指标。结果模型训练了三天都不收敛。后来简化成 3 个指标，一天就收敛了。记住：奖励函数越简单，训练越快。
2.3 一个简单的 DQN 码率控制示例
下面是我在项目中用过的简化版 DQN 结构。注意，这只是演示思路，生产环境要复杂得多：
class DQNAgent:
def __init__(self, state_dim=6, action_dim=3):
self.model = Sequential([
Dense(64, activation='relu', input_dim=state_dim),
Dense(64, activation='relu'),
Dense(action_dim, activation='linear')
])
self.model.compile(optimizer='adam', loss='mse')
def act(self, state):
# epsilon-greedy 策略
if np.random.rand() < self.epsilon:
return random.choice([-1, 0, 1]) # 降、稳、升
q_values = self.model.predict(state)
return np.argmax(q_values) - 1 # 映射到 {-1, 0, 1}这里有个关键点：动作空间为什么是离散的？因为连续动作（比如精确到 1kbps 的调整）会让 Q 值估计变得极不稳定。我试过连续动作，训练了 2 万步还没收敛，换成离散动作后 5000 步就搞定了。
三、LSTM 预测网络状态
3.1 为什么要预测？
传统算法有个致命问题：它只能「事后」反应。等检测到丢包了，再降码率，这时候卡顿已经发生了。LSTM 能做什么？它能提前 1-2 秒预测网络即将变差，让你提前降码率。
嗯，这里要注意：预测不是万能的。如果网络突变（比如突然断网），LSTM 也预测不了。它擅长的是周期性变化，比如视频会议中每 30 秒一次的带宽波动。
3.2 LSTM 的输入输出设计
我个人的习惯是：
- 输入序列长度： 10 个时间步（每个步长 100ms，即过去 1 秒的数据）
- 输入特征： RTT、接收码率、丢包率、抖动
- 输出： 未来 500ms 的带宽预测值
为什么是 500ms？因为 WebRTC 的码率调整周期通常是 200-500ms。预测太远没意义，网络早就变了。
model = Sequential([
LSTM(64, return_sequences=True, input_shape=(10, 4)),
Dropout(0.2),
LSTM(32, return_sequences=False),
Dense(16, activation='relu'),
Dense(1, activation='linear') # 预测带宽
])
model.compile(optimizer='adam', loss='mae')注意：LSTM 训练时一定要做数据归一化。我曾经忘了归一化，RTT 是 200ms，带宽是 2Mbps，两个数量级差太多，模型直接学偏了。建议用 MinMaxScaler 缩放到 [0,1] 区间。
四、实际落地案例
4.1 案例一：某视频会议产品的混合方案
我在 2022 年参与过一个项目。我们用了「传统算法 + ML 兜底」的混合架构：
- 默认走 GCC，因为它在 80% 的场景下表现良好
- LSTM 预测模块实时输出未来带宽
- 如果 LSTM 预测带宽 低于当前码率 30%，触发 ML 降码率
- 如果 LSTM 预测带宽 高于当前码率 50%，允许激进升码率
效果怎么样？卡顿率从 2.3% 降到了 0.8%，清晰度提升了 15%。但代价是 CPU 占用增加了 8%。嗯，这个 trade-off 你要自己权衡。
4.2 案例二：直播场景的强化学习方案
直播和实时通信不一样。直播可以容忍 2-3 秒延迟，但要求极高清晰度。我们当时用 DQN 做码率控制，奖励函数设计成：
- 流畅度权重 0.4
- 清晰度权重 0.4
- 码率稳定性权重 0.2
训练了 10 万步后，模型学会了在带宽充足时「大胆升码率」，在带宽紧张时「果断降码率」。比人工调参的固定策略提升了 22% 的用户体验评分。
落地经验总结：
- 不要一上来就上 ML，先用传统算法跑通流程
- ML 模型要定期重新训练（建议每周一次）
- 一定要有 fallback 机制：ML 挂了，切回传统算法
- 模型大小控制在 1MB 以内，否则移动端扛不住
五、本章知识体系总览
下面这张图总结了机器学习在拥塞控制中的核心逻辑：
这张图把三个核心模块串起来了。左边是强化学习做码率决策，中间是 LSTM 做网络预测，右边是落地时怎么组合使用。你仔细看箭头方向——LSTM 的输出可以作为强化学习的状态输入，这是目前业界比较前沿的做法。
我的建议：如果你刚开始接触这个方向，先从 LSTM 预测入手。它比强化学习简单，效果也立竿见影。等 LSTM 跑通了，再尝试把强化学习加进去。一口吃不成胖子，我当初也是这么一步步过来的。