游戏直播搭建的网络延迟优化方法
做游戏直播的朋友应该都深有体会，延迟这东西真的很玄学。有时候网络看起来没问题，画面也清晰，但就是感觉哪里不对劲，观看的用户体验上总是差那么一口气。今天咱们就来聊聊，游戏直播搭建过程中，那些实实在在影响延迟的因素，以及怎么从根本上把延迟降下来。
先搞懂延迟到底是怎么来的
很多人一说起延迟，第一反应就是"网速快不快"。其实延迟和网速完全是两回事。网速指的是带宽大小，相当于道路的宽度；而延迟是数据从一端传到另一端花的时间，相当于开车从出发点到目的地的时间。一条高速公路可能很宽，但如果要绕很远才能到目的地，时间反而更长。
具体到游戏直播的音视频传输，延迟主要由这几个部分组成。首先是采集编码延迟，这一块发生在主播端，摄像头或者游戏画面被捕获下来，然后通过编码器压缩成数字信号，这个过程普通电脑大概需要几十毫秒，高性能设备可以做到更低。然后是网络传输延迟，这才是重头戏，数据包要经过各种网络节点从主播那边传到观众那边，中间经过的每一跳都会产生延迟。接下来是解码渲染延迟，观众端的设备接收到数据后要解码成画面再显示出来，这个也需要一定时间。
网络传输延迟本身还可以细分。物理距离是第一道坎，你在北京直播，观众在纽约，就算网络设施再好，数据跑那么远也得花时间，物理定律摆在那里。网络路径选择也很关键，数据走的路线是不是最优的，中间经过的路由器多不多，这些都会影响最终延迟。还有服务器处理能力，假设数据经过的某个节点服务器性能不行，处理速度慢，也会造成拥堵和延迟。
举个直观的例子，假设物理距离产生的延迟是50毫秒，网络路径选择不好多绕了20毫秒，服务器处理又花了10毫秒，加起来就80毫秒了。这还只是网络传输的部分，加上编解码的延迟，轻轻松松就奔着150毫秒去了。所以优化延迟必须方方面面都考虑到，少算一个环节都不行。
传输协议选对了，延迟就少一半
说到网络传输，协议选择是头等大事。这里有个关键点需要明白： TCP协议虽然可靠，但它为了保证数据完整到达，会做一些重传和确认机制，这在某些情况下会增加延迟。比如一个数据包丢了，TCP要等超时重传，在这段时间里后面的数据也得等着，整个流程就卡住了。
UDP协议在这个场景下就有优势了。它的设计理念是"尽力而为"，不保证每个包都到达，也不做确认和重传。这样有什么好处？首先头部简单，只有8个字节，TCP头最小也有20字节，传输效率更高。然后是不用建立连接，发送方直接就能发，节省了握手的时间。更重要的是，它不会因为丢包而阻塞，这点对实时性太重要了。
当然UDP也有缺点，就是不保证可靠性，可能会有丢包或者乱序。但游戏直播场景下，我们追求的是实时性，偶尔丢一帧画面比卡顿半天要能接受得多。所以目前主流的实时音视频传输都是基于UDP或者在UDP基础上做改进，比如常用的RTP/rtcP协议族，就是在UDP之上增加了时间戳和同步机制，既保留了低延迟的特性，又能做一些基本的丢包检测。
这里有个细节值得说说，有些团队在做直播架构时会纠结用TCP还是UDP。我的建议是，如果你做的是偏互动的场景，比如直播连麦、游戏语音，UDP系协议是首选。如果是那种可以有一定延时的录播点播，TCP会更稳妥。选错协议，后面再怎么优化都很难弥补。
编解码优化：画质和延迟的博弈
编码环节对延迟的影响往往被低估了。大家都知道高清画质好，但高清意味着更多的数据量，编码器需要处理的时间也更长。有些编码器为了追求更高的压缩率，会使用复杂的算法 lookahead，也就是提前缓存一部分画面来分析，这虽然能提升画质，但代价就是延迟增加。
那怎么平衡呢？首先可以考虑硬件编码，现在不管是NVIDIA的NVENC、Intel的QuickSync还是苹果的Metal，硬件编码器的速度都比软件编码快得多，延迟也能做到更低。如果条件允许，尽量用硬件编码。然后是编码参数的取舍，帧率、分辨率、码率这几个参数要搭配好。降低帧率能减少数据量，但画面会不流畅；降低分辨率影响清晰度；降低码率在运动场景下容易出现马赛克。
这里有个实用的技巧是动态码率调节。网络带宽不是恒定的，有时候好有时候差，如果码率固定不变，带宽不够的时候就会卡顿。好的做法是根据实时探测的带宽情况动态调整码率，宽裕的时候推高清，带宽紧张的时候自动降级，保证流畅度优先。这个技术在移动端尤为重要，因为移动网络的波动比固网大得多。
解码端也有讲究。软解码的灵活性好，但速度慢；硬解码速度快，省电，但兼容性需要考虑。现在很多设备都支持硬解优先的策略，优先使用硬件解码，只有在硬解不支持的情况下才回退到软解，这样能保证大多数情况下的低延迟体验。
边缘节点和智能路由：让数据走最短路径
前面提到物理距离是延迟的主要来源之一，这个问题怎么解决？答案很简单：让数据少跑路。怎么做？就是在全球各地部署边缘节点，把服务延伸到离用户更近的地方。
假设你的服务器主要放在北京，那上海的用户访问延迟肯定比哈尔滨低，香港的用户又比上海高。但如果在香港也有节点，香港用户就相当于在本地访问了，延迟能降下来不少。这不是简单的多放几台服务器就行的，节点怎么分布、怎么调度、流量怎么分配，这些都是技术活。
智能路由是另一个关键。数据从A到B可以走很多条路，哪条最快？不是距离最短就最快，还要看当前网络的拥塞程度。有些线路距离短但高峰期堵车，有些线路绕远但畅通无阻。好的路由系统能实时探测各条线路的延迟和丢包率，动态选择最优路径。这个探测的频率要把握好，探得太勤增加开销，探得太慢又跟不上网络变化。
很多专业的实时音视频服务商在这方面投入很大，就是因为这直接关系到用户体验。举个例子，像声网这样的服务商，他们在全球都有节点部署，结合实时的网络质量探测和智能调度，能把跨区传输的延迟压到很低。对于要做出海业务的直播平台来说，这种能力尤其重要，毕竟你的观众可能在世界各地。
抗丢包和抖动缓冲：最后一道防线
网络状况永远是不可完全预测的。哪怕前面做得再好，丢包和抖动还是会发生。丢包就是数据包没送到，抖动是数据包到的顺序乱了或者时快时慢。这两个问题不解决，最终的观看体验还是会受影响。
先说丢包。丢了包怎么办？最粗暴的做法是让发送方重传，但这又会增加延迟。高级一点的做法是前向纠错，也就是在发送数据的时候多发一些冗余包，接收方丢了包可以用冗余数据恢复出来。当然冗余包本身也占用带宽，要根据丢包率来调整冗余比例，找到一个平衡点。
抖动缓冲的原理是这样的：收到的数据包不是立刻就播放，而是先缓存一会儿。这样就算有的包晚到了，只要在缓存窗口内到达，就能按正确的顺序播放。缓冲时间设多长？设太短来不及处理突发延迟，设太长又增加延迟。好的系统会根据实时的抖动情况动态调整缓冲时长，平时保持一个较小的值，网络抖动时自动拉大。
这两个机制配合好了，即使在不太稳定的网络环境下，也能给观众提供相对流畅的体验。当然，再好的技术也架不住网络特别差的情况，那时候能做的也只是尽量减少对用户的影响。
从系统层面看延迟优化
说了这么多技术点，最后想从整体上聊聊。游戏直播的延迟优化不是某一个环节做好了就行的，它是一个系统工程。从采集编码到网络传输再到解码播放，每个环节都有关联，任何一个短板都会拖累整体表现。
很多团队在搭建直播系统时会陷入一个误区，就是过度关注某一个点。比如拼命提升编码效率，却发现网络传输的延迟占比更大；或者网络优化得差不多了，但观众端的解码渲染又成为瓶颈。正确的做法是先用工具测量一下各个阶段的延迟分布，找到最大的瓶颈在哪里，集中力量攻克主要矛盾。
还有一个容易被忽视的点是对不同场景的差异化处理。游戏直播里面，不同玩法的延迟要求其实不太一样。如果是那种竞技类游戏，延迟稍微高一点玩家就能感觉到明显的不跟手；如果是秀场直播，主要看的是主播这边，观众端的延迟要求相对宽松一点；如果是直播带货，可能对互动延迟要求高，但对画质可以妥协。了解自己的场景特点，才能做出合理的取舍。
现在做直播的技术方案很多，有自建的，有用云服务的。自建的好处是可控度高，什么都能自己把握，但需要投入人力和资源去维护和优化。用云服务的话，可以借助服务商已经做好的基础设施，比如声网这样专门做实时音视频的厂商，他们在这块积累很深，很多坑已经被踩过了，直接用现成的解决方案能省不少事。具体怎么选，还是要看团队的情况和业务阶段。
写在最后
游戏直播的网络延迟优化，说到底就是在跟物理定律和网络不确定性斗智斗勇。我们没办法消除所有的延迟，但可以通过合理的技术选型和架构设计，把延迟控制在一个可接受的范围内。
做技术优化的人都知道，没有完美的方案，只有最适合当前场景的方案。有时候为了降低延迟可能要牺牲一些画质，为了提升稳定性可能要接受一定的资源消耗。关键是理解各个因素的trade-off，然后做出明智的决策。
希望这篇内容能给正在搭建游戏直播或者遇到延迟问题的朋友一些参考。如果有什么没说到的，或者有具体的问题想讨论，欢迎一起交流。
