直播卡顿优化中网络诊断步骤
前两天有个朋友跟我说，他开发的直播应用最近总被用户投诉说画面卡顿，尤其是晚高峰时段，那画面简直能让人急出高血压。他问我有没有什么好的排查方法，我想了想，与其让他自己摸索，不如把网络诊断这套东西好好捋一捋。毕竟做直播的都知道，卡顿这个问题说大不大说小不小，但真要追根溯源起来，里面的门道可不少。
其实我自己当年刚接触音视频这行的时候，也被卡顿问题折磨过。那时候不懂什么叫网络诊断，看到卡顿就盲目加带宽，结果钱花了问题还没解决。后来慢慢摸索出来了，网络诊断这件事讲究的是个循序渐进，顺序不能乱，步骤不能省。今天我就把这一套方法论分享出来，希望能帮到正在被类似问题困扰的朋友们。
一、先弄明白卡顿是怎么来的
在开始诊断之前，我们得先搞清楚直播卡顿的几种典型表现。有的朋友可能会说，卡顿不就是画面不动吗？话是这么说，但同样是卡顿，原因可能天差地远。
第一种情况是画面定格不动，你点一下播放键，画面就卡在某一帧不动了，声音可能还在响，这种情况通常意味着视频流数据传输中断或者解码出了问题。第二种是画面一顿一顿的，像看幻灯片一样，这种往往是网络带宽不足或者波动导致的缓冲不够。第三种是画面模糊然后突然变清晰，这是自适应码率在起作用，说明网络状况在好转或者系统在自动调整。
这三种情况的诊断方向是完全不同的。所以我建议大家在遇到用户反馈的时候，最好能让用户提供一些额外的信息：比如卡顿发生在什么时候，是一直卡还是偶尔卡，是所有用户都卡还是只有部分用户卡。这些信息能帮我们大大缩小排查范围。
二、网络诊断的标准流程
说了这么多，我们现在开始进入正题。网络诊断这件事，我把它拆成了六个步骤，顺序很重要，最好不要跳着来。因为后面的很多结论都需要前面步骤的数据支撑，你要是直接从第五步开始干，很可能会走弯路。
第一步：确认网络环境基础状态
这第一步看起来简单，但很多人会忽略。你得先确认用户端的网络到底是个什么状态。不是什么玄学的东西，就是一些基础指标的采集。
首先要看的当然是网络延迟，也就是从客户端到服务器的一个往返时间。这个用ping命令就能测出来，单位是毫秒。一般来讲，直播场景下延迟在100ms以内算优秀，200ms以内算正常，超过300ms就可能会感受到明显的延迟感了。不过这里要注意，ping出来的延迟和实际直播延迟不是一回事，因为直播走的协议和ping不一样，但ping延迟高的话，直播延迟基本也不会太低。
然后是丢包率，这个指标很关键。丢包就是数据包在传输过程中丢失了，直播尤其是实时性要求高的直播，丢包直接会导致画面卡顿或者马赛克。怎么测呢？可以用ping命令加上-t参数，连续ping上一分钟，然后看丢包统计。在UDP协议下，丢包率1%以内是可以接受的，超过5%就会明显影响体验了。
还有一个是带宽估算。你要大概知道用户现在的网络能承载多大的数据量。最简单的办法是让用户先停止其他占用网络的应用，然后用测速网站跑一下。不过要注意，测速网站测的是下载带宽，而直播需要的是上传带宽，很多家庭的宽带是上下行不对称的，上行可能只有下行的十分之一，这个一定要搞清楚。
第二步：分析CDN和节点选择
确认了用户端网络没问题之后，下一步要看的就是服务器端的配置了。这里首先要检查的是CDN节点的分配是否合理。
我见过不少案例，最后查出来问题居然是CDN节点选错了。比如一个用户明明在上海，CDN却给他分配了一个北京的节点，绕了这么大一圈，延迟不高才怪。所以第一步要确认的是，用户请求有没有被正确地调度到地理位置最近的节点。这个可以通过查看客户端的DNS解析结果或者直接看访问日志来确定。
如果发现节点调度有问题，那就需要检查CDN的调度策略了。是因为DNS解析不够智能？还是CDN节点本身的覆盖有盲区？又或者是某些节点负载太高被限流了？这些都有可能。我建议在关键节点上都做好监控，一旦发现某个区域的CDN节点响应异常，要及时切换或者扩容。
另外还要注意CDN的缓存策略是不是合适。直播内容虽然时效性强，但一些静态资源比如播放器配置、鉴权信息什么的，还是应该走缓存的。如果缓存命中率太低，每次都要回源，那延迟自然会上去。
第三步：排查传输层协议配置
这一块可能稍微专业一点，但非常重要。传输层协议的选择和配置直接影响着直播的稳定性和流畅度。
目前主流的直播传输协议有RTMP、FLV、HLS、HTTP-FLV，还有基于UDP的私有协议比如QUIC。每种协议都有自己的特点：RTMP延迟低但穿透性差，HLS兼容性最好但延迟高，HTTP-FLV在移动端表现不错，QUIC则在弱网环境下有优势。
如果用的是UDP协议，需要特别关注一下拥塞控制算法的选择。Bbr、Cubic、Westwood这些算法在不同网络环境下的表现差异很大。比如在有丢包的网络环境下，Westwood可能比Cubic更合适；在高带宽高延迟的网络环境下，bbr算法的表现往往更稳定。这个需要根据自己的业务场景去调优，没有放之四海而皆准的最优解。
还有一个要注意的是MTU设置。MTU就是最大传输单元，如果MTU设置得不合适，大包会被分片，分片一旦丢失，整个包就废了。在直播场景下，建议把MTU设置在1400左右，这样可以平衡传输效率和可靠性。
第四步：检查编码和码率配置
网络没问题了，但卡顿还在，那问题可能就出在编码这一块。这一步要检查的是编码参数设置得是否合理。
首先看码率。码率设置得太高，用户带宽不够，就会卡顿；码率设置得太低，画面质量又没法保证。这里有个参考值：普通直播场景下，480P分辨率建议码率在800kbps到1.5Mbps之间，720P建议在1.5Mbps到3Mbps之间，1080P则建议在3Mbps以上。当然这只是一个大概的范围，具体还要根据内容类型来调整——运动画面多的场景码率需要高一些，静态画面多的场景码率可以低一些。
然后看帧率。帧率太低会感觉画面不流畅，帧率太高又会对带宽和解码性能提出更高要求。一般直播场景下，25帧到30帧是比较合适的区间。如果发现帧率不稳定，忽高忽低，那可能是编码器的码率控制策略有问题，需要调整GOP（图像组）大小和参考帧设置。
还有一点容易被忽略，就是关键帧间隔。关键帧也叫I帧，是完整的一帧图像，后面跟随的P帧和B帧只存储和关键帧的差异。如果关键帧间隔太长，一旦发生丢包，就需要等待下一个关键帧才能恢复完整画面，等待的这段时间用户就会看到卡顿或者马赛克。但如果关键帧间隔太短，码率又会上去。一般建议关键帧间隔设置在2秒到4秒之间。
第五步：监控和日志分析
到这一步，如果前面几步都没发现问题，那可能需要借助更详细的监控数据来排查了。
首先要在客户端做好质量数据的采集。包括但不限于：每秒钟的帧率波动、缓冲次数和缓冲时长、卡顿事件的具体时间点和持续时间、网络类型切换事件等等。这些数据要尽量详细，最好能上报到后台做聚合分析。你可能会发现一些规律：比如卡顿总是发生在用户切换WiFi和4G的时候，或者总是发生在特定型号的手机上，又或者总是发生在某个特定的时段。
服务端日志也要仔细看。要关注的是请求的错误码分布、响应时间分布、异常断开连接的原因等等。如果发现某个时间段的错误码特别多或者响应时间突然变长，那可能就是服务端那边出了问题。
这里我要提一下，我们声网在全球部署了大量的边缘节点，配合智能调度系统，能实时监控全球各区域的网络质量状况。一旦发现某个节点有异常，系统会自动把流量切换到其他健康节点上，最大限度保证直播的稳定性。而且我们后端的日志系统做得也比较细致，任何异常都能快速定位，这也是为什么很多头部直播平台都选择我们的服务的原因之一。
第六步：压力测试和弱网模拟
如果你已经在生产环境排查了一圈还没找到问题，那可能需要回到测试环境，用压力测试和弱网模拟来复现问题了。
压力测试的目的是看看系统在高并发情况下的表现。比如模拟1000个用户同时在线，看服务端CPU和内存的占用情况，看网络带宽有没有成为瓶颈，看数据库连接数有没有超限。很多问题只有在高负载情况下才会暴露出来。
弱网模拟则更贴近真实用户的网络环境。你可以用一些工具来模拟高延迟、高丢包、带宽受限的网络环境，看看在这种恶劣条件下直播的表现如何。我们内部做测试的时候，会重点关注几个临界点：延迟到多少ms的时候开始卡顿？丢包率达到多少的时候画面会出现马赛克？带宽降到多少的时候系统能自动切换到低码率模式？这些数据对于优化自适应码率策略很有帮助。
三、常见卡顿问题的快速定位表
为了方便大家快速定位问题，我整理了一个简易的对照表。当你遇到卡顿投诉的时候，可以先对照这个表做一个初步判断：
| 卡顿表现 | 可能原因 | 优先排查方向 |
| 一直卡顿，无一幸免 | 服务端问题或CDN故障 | 服务端监控日志、CDN节点状态 |
| 部分用户卡顿 | 用户网络问题或节点分配 | 用户网络环境、CDN调度策略 |
| 晚高峰时段卡顿 | 带宽不足或节点负载过高 | 带宽扩容、负载均衡配置 |
| 网络切换策略或协议配置 | 网络切换处理逻辑、传输协议 | |
| 特定机型卡顿 | 设备性能或兼容性问题 | 该机型解码性能、系统兼容性 |
这个表只能做一个初步参考，实际排查中可能需要组合多种情况来分析。比如某个用户反馈卡顿，既可能是他自身网络不好，也可能是CDN节点分配不当，两者叠加在一起，问题就更复杂了。
四、写在最后的一点感想
做直播开发这些年，我最大的感受就是卡顿这个问题，永远没有一劳永逸的解决办法。网络环境在变，用户设备在变，内容形态也在变，你永远不知道下一个卡顿会以什么方式出现。
我能给出的建议就是：做好监控，让问题第一时间被发现；做好预案，知道出了问题该从哪里入手；保持学习，新的技术方案可能刚好能解决你现在的痛点。
另外就是，在选择底层服务的时候还是要慎重。像我们声网这样深耕音视频领域的厂商，确实能帮你解决很多基础设施层面的问题，让你把精力集中在业务创新上。毕竟术业有专攻，有些事情交给专业的团队来做，效率会高很多。
如果你在实际操作中遇到了什么具体的问题，也可以提出来大家讨论讨论。卡顿这个话题展开讲还有很多东西，今天就先聊这么多吧。
