海外直播卡顿怎么办？一个技术人员眼中的排查全记录

说实话，每次遇到海外直播卡顿的问题，我都觉得脑袋大。这事儿说简单不简单，说复杂也复杂，但归根结底就是那么几个环节在捣乱。今天我就把自己这些年排查这类问题的思路整理一下，算是给遇到同样困扰的朋友们一个参考。准备好了吗？我们开始。

先从最基础的网络连通性说起

很多人一上来就盯着编码器或者CDN看，其实有时候问题特别简单——网络根本就没通。排查海外直播问题，第一步永远是确认网络层面的基础连通性。

我们首先要测试的是海外节点的可达性。别只用ping命令，那个只能说明ICMP能过去，直播走的是TCP或者UDP，意义不大。更好的做法是直接telnet你的直播服务器地址和端口，看看三次握手能不能完成。比如你用的是RTMP协议，就试试1935端口；如果是webrtc，那端口就多了去了，3478、443这些都可能用到。

这里有个小技巧，我发现很多人在国内测试海外节点的时候喜欢用traceroute，但国内的运营商国际出口经常会有一些奇怪的路由走向。建议同时用一下webbased的MTR工具，从多个地理位置同时去测试，这样你能看到不同地区的用户访问过来的时候，路由到底在哪里绕了弯。上次我排查一个客户的问题，最后发现竟然是某个国家的海底光缆节点故障，导致那个区域的所有用户延迟都飙升到800ms以上。

另外，DNS解析这块也得注意。有时候域名解析出来的IP不是你期望的那个海外节点，特别是用了智能DNS的情况下。你可以dig一下看看返回的IP是什么，然后手动把这个IP放到hosts文件里测试一下，看看切换IP之后卡顿现象有没有改善。如果切换IP后问题消失，那基本上就是DNS解析策略的问题。

带宽和延迟，这两个老朋友得分开看

带宽不足会导致卡顿，这个大家都懂。但我发现很多人容易把带宽不足和延迟过高混为一谈。其实这是两个完全不同的概念，得分开来看。

带宽问题最直观的表现就是缓冲。视频打着打着突然停住转圈圈，或者画面突然变得很粗糙然后糊一会儿，这通常是带宽不够的表现。你可以看一下码率和实际带宽的比值，如果码率长期超过可用带宽的80%，那就危险了。毕竟网络传输总会有波动，你得给它留点余量。

测带宽别用什么Speedtest，那个测的是下载速度，对直播参考意义不大。正确的做法是在推流或者拉流的服务器上做实际的数据传输测试。比如用iperf3，模拟你的直播流量跑一段时间，看看实际能稳定跑多少。如果你能拿到运营商给的历史带宽数据曲线也看看，有时候高峰时段带宽会缩容，这个坑我踩过不止一次。

延迟高则是另一码事儿。延迟高了之后，你感觉画面慢半拍，互动不及时，但只要带宽够，缓冲反而可能不多。这就是为什么有时候你看着码率监控一切正常，但观众就是反馈说”感觉有点卡”。海外直播因为物理距离远，基础延迟本身就低不了，跨洋链路轻轻松松就是150ms以上，这个是客观存在的，你别指望能消除它，只能尽量优化。

测延迟的话，我推荐用tcping或者mtr配合着看。tcping能告诉你TCP层面的往返时间，mtr能让你看到每一跳的延迟分布。如果某一跳的延迟特别高，那基本就是那一段网络有问题。

CDN和节点选择，这里水很深

说到海外直播，CDN基本是绕不开的话题。我见过太多案例，源站质量没问题，问题全出在CDN节点选择和配置上。

首先你得搞清楚你的CDN在全球有多少节点，覆盖了哪些区域。很多CDN厂商吹得很厉害，说全球几百个节点，但你仔细一看，亚太就占了大部分，欧洲和美洲反而稀疏得很。如果你的观众主要在欧洲，那选这种CDN就是给自己找麻烦。

然后要看看CDN的智能调度能力怎么样。好的CDN会根据用户的地理位置、网络状况、节点负载来综合判断，给用户分配最优节点。这个调度策略是不是生效，你可以让不同地区的朋友帮忙测试一下，看看他们拉流的时候分别是从哪个节点拉过来的。如果调度策略有问题，可能会有明明在美国的用户，却被分配到日本的节点去看，那延迟能不高吗？

还有一点很容易被忽略，就是CDN的缓存命中率。如果缓存命中率低，大量的请求都回源到你的源站，那源站的压力会很大，响应也会变慢。你可以看一下CDN后台的命中率报表，如果命中率低于80%，那得多想想办法提升一下。比如是不是时间碎片太严重，导致热门内容反而没法很好地缓存。

常见CDN问题的排查思路

当怀疑CDN有问题的时候，可以按这个步骤来：

• 直接用源站地址拉流试试，如果用源站不卡，那就是CDN的问题
• 换几个不同的CDN节点地址直接拉流，看是不是个别节点的问题
• 检查CDN节点的负载情况，有没有某个节点承载压力过大
• 看看CDN的流量调度日志，分析一下用户的请求有没有被正确路由
• 对比一下不同时段的表现，判断是不是高峰期的节点容量问题

协议选择，有时候比配置更重要

直播协议的选择对海外传输的影响非常大，但我发现很多人在这块不太重视，觉得随便选一个能推能拉就行。其实不同协议在弱网环境下的表现差异巨大。

RTMP这种老牌协议，虽然成熟稳定，但它基于TCP，在高延迟网络上的表现会比较一般。而且RTMP没法自适应带宽，网络波动的时候要么卡住要么花屏，观众的体验不会太好。

HLS和DASH这种基于HTTP的协议，最大的好处是能自适应码率，网络好了自动切高清，网络差了就降清晰度，缓冲一下就能继续播。但它们的延迟本身就比较高，海外直播用HLS的话，延迟轻松上到10秒以上，你要是做互动直播，那体验真的不太行。

至于webrtc，那就是为实时通信而生的，延迟可以做到很低，海外直播场景下优势很明显。但WebRTC的配置相对复杂一些，涉及ICE、TURN、STUN这些组件，哪个环节没配好都可能出问题。而且WebRTC对客户端的支持也不是所有设备都完美，安卓低端机和某些浏览器版本可能会有兼容性问题。

我们声网在这方面做了很多工作，针对海外场景优化了传输策略，能够在保证低延迟的同时提供更稳定的传输质量。当然，不同业务场景还是要根据实际需求来选择协议，没有最好的协议，只有最适合的协议。

编码器配置，别小看这些参数

编码器配置不对，也会导致卡顿。这个问题容易被忽视，因为大家都觉得编码器嘛，设个码率就能跑了，哪有那么复杂。但实际上，编码器的参数设置和你的网络状况、观众设备都有关系。

码率设置是第一个要看的。如果你用的是固定码率（CBR），那遇到弱网的时候观众端就会卡住等你；如果用可变码率（VBR），虽然码率会波动，但画面质量会相对稳定一些。海外直播网络波动大，我建议优先考虑VBR模式下的ABR（自适应比特率）方案，让系统根据网络状况自动调整。

帧率和分辨率的搭配也很重要。30帧和60帧在同等码率下，清晰度差异挺明显的。海外网络不稳定的时候，适当降低帧率保清晰度可能是更好的选择。比如把帧率降到24fps或者20fps，省下来的带宽用来提升画质，观众的主观感受可能更好。

gop（Group of Pictures）设置也值得关注。gop越大，压缩效率越高，但延迟也越大；gop小的话延迟低，但码率会上去。海外直播如果对延迟要求不是特别极致，gop设置成帧率的2到4倍是比较合理的区间。

还有就是编码profile，Baseline、Main、High这几个级别，对设备的兼容性不同。Baseline兼容性最好但压缩效率低，High压缩好但有些老设备可能解不了。海外观众设备来源复杂，这个要谨慎选择。

服务端负载，别让服务器成为瓶颈

源站服务器或者转码服务器负载过高，也会导致卡顿。这个问题在海外直播中尤其明显，因为海外的服务器资源通常比国内贵，很多人为了省钱会把配置压得比较极限。

首先看CPU负载。如果你的转码服务器CPU长期跑在80%以上，那就要小心了。视频转码是非常消耗CPU的工作，一旦CPU不够用，要么延迟飙升，要么就开始丢帧。你可以按核心数估算一下，单路1080p转码大概需要多少CPU资源，然后算算你的服务器能承载多少路并发。

内存和磁盘IO也经常是瓶颈。特别是如果你用软件解码然后再编码，内存占用会非常高。磁盘IO方面，如果你的源站或者CDN节点用的磁盘IO性能不好，大流量的时候读取视频切片就会变慢，这也会体现为卡顿。

网络带宽也要算清楚。服务器的上行带宽够不够支持你同时推多少路流，这个账要好好算。见过不少人买了服务器之后才发现带宽费比服务器本身还贵，那就尴尬了。

服务器性能监控指标参考

td>低于系统限制的80%

客户端这边，也不能完全不管

排查问题的时候，很多技术人员容易犯一个错误，就是只盯着服务端看，把客户端当成铁定没问题的。但实际上，客户端的问题五花八门，什么情况都可能发生。

浏览器或者APP的性能影响就很大。JS主线程被其他任务占着的时候，视频解码和渲染都会受影响。你可以看一下播放器的帧率输出和实际渲染帧率的对比，如果渲染帧率远低于解码帧率，那基本上就是客户端性能问题了。

客户端的网络环境也千奇百怪。有的用户在地铁里用4G，有的在公司里用的企业网络出口做了各种限制，还有的用的WiFi信号弱得可怜。这些都会影响观看体验，但在服务端根本看不多来什么问题。所以收集客户端的反馈信息很重要，有时候用户的网络环境问题，靠服务端排查是永远排查不出来的。

播放器版本也得关注。不同版本的播放器对各种协议和编码格式的支持程度不同，有时候升级或者降级播放器版本问题就解决了。这个虽然听起来玄学，但我确实遇到过好几次。

安全设备，别让它们帮倒忙

防火墙、负载均衡器、安全网关这些设备，在海外直播场景下尤其容易出问题。因为它们可能在你不注意的时候把正常的直播流量给拦截了或者限速了。

先检查一下源站服务器的防火墙规则。特别是那些基于Linux iptables的规则，一不小心就把某个端口或者IP段给封了。海外直播的话，国际出口的IP段访问规则要重点检查一遍。

如果是用了云服务，看看安全组设置对不对。很多云平台的安全组是默认拒绝的，你得手动放行相关的端口和协议。另外有些云平台还有额外的防火墙服务，比如AWS的WAF或者阿里云的云盾，它们可能会有一些默认的防护策略把正常的直播流量给拦了。

负载均衡器也要看一下健康检查配置。如果健康检查的阈值设置得太严格，可能导致正常的流量被判定为异常，然后负载均衡器就把流量切换到其他节点去了。这一切换，观众那边肯定要卡一下。

写在最后

排查海外直播卡顿问题，核心思路就是分段排查、逐一排除。从客户端到网络，从网络到CDN，从CDN到源站，一段一段地定位问题。

工具方面，常用的也就是ping、traceroute、telnet、mtr、iperf3、tcpdump这些。关键是你要理解这些工具输出的数据是什么意思，能够从数据里发现问题。

还有很重要的一点，就是建立有效的监控和日志体系。问题发生的时候，如果你有完整的监控数据和日志，定位问题的速度会快很多。海外直播面对的用户环境更复杂，更需要完善的监控来支撑。

希望这篇文章能给遇到类似问题的朋友一点启发。直播技术这行当，水很深但也很有意思，遇到问题不要慌，一步一步来，总能找到根因的。