2. 网络瓶颈分析：带宽、拥塞、协议与 QoS
网络瓶颈，说白了就是数据在传输过程中被「卡脖子」了。我做流媒体系统这么多年，遇到的性能问题里，网络层面至少占了一半。很多时候你优化了编码、升级了服务器，结果发现瓶颈其实在网线上——嗯，这感觉挺憋屈的。
这一章我们就把网络瓶颈拆开来看。带宽、拥塞、协议选择、QoS 配置，这四个点搞清楚了，你排查网络问题就有方向了。
2.1 带宽限制：不是越大越好，是够用就好
带宽是网络管道的粗细。但很多人有个误区：以为带宽越大，流媒体就越流畅。其实不是这样。
我遇到过一家直播公司，他们买了 10Gbps 的专线，结果用户还是卡。查了半天，发现是服务器出口的带宽被多个服务共享，流媒体只分到了 200Mbps。你想想看，管道再粗，分给你的只有一根吸管，那也没用。
关键公式：
所需带宽 = 视频码率 × 并发用户数 × 冗余系数（通常 1.2~1.5）
举个例子：一个 4K 流，码率 20Mbps，同时 100 人观看，那至少需要 20 × 100 × 1.3 = 2600Mbps ≈ 2.6Gbps 的出口带宽。
带宽瓶颈的排查步骤，我一般这么来：
- 先测实际可用带宽——用 iperf3 打流，别信运营商给的数字
- 看链路利用率——如果持续超过 70%，说明带宽快撑不住了
- 区分上行和下行——推流看上行，拉流看下行，两个方向都要测
我的习惯：在服务器上跑一个带宽监控脚本，记录 24 小时的带宽使用曲线。峰值出现在晚上 8-10 点，那是用户最活跃的时候。如果峰值接近上限，就该扩容了。
2.2 网络拥塞：真正的隐形杀手
带宽够用，但用户还是卡？那多半是拥塞了。拥塞不是带宽不够，而是数据包在路上堵车了。
我曾经排查过一个案例：用户观看 1080p 视频，前 10 秒流畅，然后突然卡顿，过几秒又恢复。抓包一看，发现是中间路由器的缓冲区满了，发生了「缓冲区膨胀」（Bufferbloat）。
拥塞的典型表现：
- 延迟抖动（Jitter）——RTT 忽高忽低，从 10ms 跳到 500ms
- 丢包率上升——超过 1% 就能明显感觉到卡顿
- 吞吐量下降——实际传输速率远低于带宽上限
避坑指南：我曾经在配置 QoS 时，把视频流的优先级设得太高，结果导致其他业务（比如日志上报）完全被饿死。后来运维半夜打电话说服务器失联了……嗯，从那以后我学会了「优先级要设，但不能设死」。
2.3 TCP vs UDP：选对协议，事半功倍
流媒体系统里，协议选择是个老生常谈但永远有人踩坑的话题。我直接说结论：
| 特性 | TCP | UDP |
|---|---|---|
| 可靠性 | 保证送达，重传机制 | 不保证，丢了就丢了 |
| 延迟 | 较高（三次握手 + 拥塞控制） | 低，无握手开销 |
| 适用场景 | 点播、HLS、DASH | 直播、实时通信、WebRTC |
| 防火墙友好度 | 高，几乎都放行 | 低，很多企业防火墙会拦截 |
| 拥塞控制 | 内置（CUBIC、BBR 等） | 需要应用层自己实现 |
为什么直播场景更倾向 UDP？因为直播对延迟敏感。你想想看，一个体育直播，如果因为丢包重传，画面卡了 2 秒才恢复，那观众看到的已经是进球后的庆祝了。UDP 的做法是：丢了就丢了，下一帧补上。
但 UDP 也有坑。我记得有个项目，我们用 UDP 做直播推流，结果在客户的内网里被防火墙直接丢弃了。后来没办法，只好在 UDP 外面包了一层 ICE/STUN 打洞，或者干脆 fallback 到 TCP。
我的建议：
- 点播系统：用 TCP（HLS/DASH），省心，兼容性好
- 直播系统：用 UDP（SRT/QUIC/WebRTC），但要做好丢包容忍
- 混合方案：TCP 做信令，UDP 传媒体数据
2.4 QoS 配置：给关键流量开绿灯
QoS（服务质量）说白了就是给不同的流量排优先级。在流媒体系统里，视频流应该比文件下载优先级高，但比 VoIP 低——因为语音比视频更不能容忍延迟。
QoS 配置的核心是 DSCP（差分服务代码点）。我一般这么配：
# 视频流标记为 AF41（保证转发，高优先级）
iptables -t mangle -A POSTROUTING -p udp --dport 5000:5100 -j DSCP --set-dscp 34
# 音频流标记为 EF（加速转发，最高优先级）
iptables -t mangle -A POSTROUTING -p udp --dport 5101:5110 -j DSCP --set-dscp 46
# 其他流量保持默认（BE，尽力而为）
但要注意，QoS 只在网络设备上生效。如果你在服务器上打了 DSCP 标记，但中间的路由器/交换机不认，那就白搭。我遇到过这种情况：服务器配好了 QoS，但客户的交换机是傻瓜式的，根本不解析 DSCP 字段。结果该卡的还是卡。
经验之谈：在部署 QoS 之前，先确认整条链路上的网络设备都支持。最好在两端都做限速和优先级标记，形成端到端的保障。
2.5 知识体系总览
下面这张图把网络瓶颈的四个维度串起来了。你可以把它当作排查时的思维导图：
这张图里，四个维度是相互影响的。比如带宽不足会加剧拥塞，拥塞又会导致 TCP 协议降速，而 QoS 配置不当可能让关键流量被挤掉。排查的时候，我习惯从带宽入手，然后看拥塞指标，再检查协议和 QoS 配置——这个顺序能帮你快速定位问题。