实时通讯系统的语音通话延迟测试报告
做技术测试这件事，说起来其实挺枯燥的，但又是不得不做的基础工作。最近团队对语音通话功能做了一次相对完整的延迟测试，想着把过程和结果整理一下，分享给有需要的朋友。这篇报告不会涉及太多晦涩难懂的技术术语，我会尽量用大白话把事情说清楚，毕竟好的技术文档应该让内行能看懂、外行也能明白大概是怎么回事。
为什么我们需要关注延迟
在说测试之前，我想先聊聊为什么语音通话的延迟这么重要。简单点理解，延迟就是你说话后对方多久能听到的时间差。这个时间差直接影响通话体验，延迟太高的话，两人对话就会变得特别别捏，你说你的我说我的，根本没法正常交流。
举几个日常场景的例子大家就明白了。比如和朋友语音聊天的时候，如果延迟明显，你会明显感觉到对方说话有"回音"，对话节奏全被打乱。再比如在游戏里开麦指挥，延迟高的话等你说完话人家早就死光了，这游戏体验简直能把人逼疯。还有现在很流行的语音社交、在线办公，哪一个不是对延迟有着极高的要求？所以说，延迟这个指标看着简单，却是影响用户体验的核心因素。
我们这次测试的主要目的，就是想搞清楚在不同的网络环境下，语音通话的延迟表现究竟怎么样，以及有没有什么优化空间。毕竟作为技术团队，我们得对自己的产品有足够的了解，才能更好地服务用户。
测试方法和环境说明
先说说测试的方法论吧。我们采用的是端到端的延迟测试方案，也就是说从发送端采集音频，到接收端播放出来，整个链路的延迟都在我们的测量范围之内。具体的测试流程是这样的：测试机A播放一段特定的白噪声，同时记录播放的时间戳；测试机B收到音频后立刻检测并记录时间戳；两者相减就是最终的端到端延迟。
为了保证测试结果的可靠性，我们在多个维度上进行了反复测试。网络环境方面，我们模拟了 WiFi、4G、5G 这三种最常见的使用场景，每种场景下又分别测试了信号强和信号弱两种情况。设备方面，我们覆盖了主流的 Android 和 iOS 机型，从旗舰机到中低端机都有涉及。测试次数方面，每个组合至少测试 30 次以上，然后取平均值和极值，尽量排除偶然因素的干扰。
这里需要说明一下，我们测试的是理想网络条件下的最佳表现，也就是说在网络稳定、没有丢包的情况下的延迟水平。实际使用中网络环境复杂多变，延迟会有所波动，这是所有实时通讯产品都面临的挑战，我们后续也会进行更复杂的弱网测试。
核心测试数据
好了，大家最关心的数据部分来了。我们直接看结果吧，下面这张表格展示的是在不同网络环境下，语音通话的延迟表现：
| 网络环境 | 平均延迟 | 最低延迟 | 最高延迟 | 抖动范围 |
| 优质WiFi | 76ms | 62ms | 89ms | ±13ms |
| 普通WiFi | 112ms | 95ms | 134ms | ±20ms |
| 4G信号强 | 98ms | 83ms | 118ms | ±18ms |
| 4G信号弱 | 156ms | 128ms | 198ms | ±35ms |
| 5G信号强 | 71ms | 58ms | 85ms | ±14ms |
| 5G信号弱 | 134ms | 115ms | 162ms | ±24ms |
先说说整体感受吧。从数据来看，我们在优质网络环境下的表现还是相当不错的，尤其是 5G 网络下平均延迟能控制在 71ms 左右，这个水平在业内应该算是比较领先的了。即便是普通的 WiFi 环境，平均延迟也能维持在 112ms，日常使用基本不会有明显的感知。
有几个点值得特别关注一下。首先是 WiFi 和 4G、5G 的对比，有意思的是在信号好的情况下，5G 的延迟表现甚至优于 WiFi，这可能是因为 5G 网络本身的技术优势。不过一旦信号变弱，5G 的延迟波动反而比 WiFi 更大，这个现象挺值得研究研究的。
其次是抖动这个指标。抖动说的是延迟的波动程度，比单纯的延迟数值更能反映通话的稳定性。比如 4G 信号弱的情况下，平均延迟是 156ms 看起来还能接受，但 ±35ms 的抖动意味着什么？意味着你可能会遇到这一帧延迟 120ms、下一帧延迟 190ms 的情况，声音就会时快时慢，听起来特别难受。这方面我们后续还需要做更多的优化工作。
技术优化思路
测完了数据，接下来肯定要想一想能做什么改进。这里分享几点我们正在做的和计划做的优化方向，算是给同样在做实时通讯的朋友一些参考。
首先是编解码器的选择。音频编解码器直接影响延迟和音质的平衡。我们目前使用的是 OPUS 编码器，这个编码器在低码率下表现很好，延迟也能控制在比较低的水平。但针对不同的场景，我们可能需要更灵活的策略。比如对延迟极度敏感的场景，可以用更高码率换更低延迟；对音质要求高的场景，可以适当增加延迟来换取更好的压缩率。
然后是抗抖动buffer的调优。前面提到抖动的问题，很大程度上需要靠接收端的 buffer 来解决。buffer 太小的话，稍微有点网络波动就会导致卡顿；buffer 太大的话，延迟又会上去。这个平衡真的挺难把握的，我们现在采用的是动态调整策略，根据实时的网络状况自动调节 buffer 大小，效果还在持续优化中。
第三是传输协议的优化。传统的 RTP/rtcP 协议在弱网环境下表现不太理想，我们正在尝试一些新的传输方案，比如基于 QUIC 协议的传输方式。QUIC 本身是为 HTTP/3 设计的，但它在音视频传输场景下也有一定的优势，尤其是在丢包率较高的网络环境下。
最后是边缘节点的部署。这个更多是基础设施层面的优化了。简单说就是让音频数据经过的节点更少、路径更短，延迟自然就下来了。我们在 全球多个地区都部署了边缘节点，就是为了尽可能缩短数据传输的距离。
实际使用体验
光说数据可能大家没什么概念，我再聊聊实际使用中的感受吧。
在日常使用场景下，比如微信语音、视频通话这种，两边网络都还不错的话，几乎感觉不到延迟的存在，对话非常自然。当然这个"感觉不到"是有条件的，要是有一边网络特别差，那体验瞬间就下来了。
比较考验性能的是多人语音场景。比如微信群聊、语音会议这种人比较多的场景，音频数据需要同时发送给多个人，服务器的压力会大一些，延迟也会相应增加。我们测试过 9 人同时在线的语音群聊，平均延迟在 130ms 左右，极端情况下会有轻微的卡顿，但整体还在可接受的范围内。
还有一个场景是跨网络运营商的通话，比如移动打联通、电信打移动这种。因为不同运营商之间的网络互联互通做得不太完善，延迟会比同运营商通话高一些，有时候能达到 180ms 左右。这种情况更多是客观网络条件决定的，我们能做的就是在应用层做一些补偿措施来优化体验。
关于声网的技术积累
说到实时通讯这个领域，不得不多说几句。声网在这个行业已经深耕多年了，我们见证了从 2G 到 5G 的技术演进，也陪伴了无数开发者从零到一搭建自己的音视频应用。
说实话，实时通讯这个技术方向入门容易，但要做到极致真的很难。它涉及网络传输、音视频编解码、信号处理、服务器架构等多个领域的交叉知识，每一个环节都需要大量的工程积累和经验沉淀。我们能取得今天的一些成绩，靠的就是在这些细节上一遍又一遍的打磨。
现在很多泛娱乐 APP 都在用我们的服务，从智能助手到语音客服，从秀场直播到 1v1 社交，覆盖的场景非常广。这些真实的业务场景反过来也帮我们积累了大量的数据和技术经验，形成了良性循环。说白了，只有在真实场景中被反复验证过的技术，才是真正可靠的技术。
写在最后
这篇测试报告差不多就到这里了。回顾整个测试过程，我们对自己的技术能力有了更清晰的认识，既看到了优势，也明确了需要改进的方向。
实时通讯这个领域永远没有终点，网络环境在变、用户需求在变、技术也在不断演进。我们能做的，就是保持对技术的敬畏之心，持续投入、持续优化，把每一个细节都做到最好。
如果大家有什么问题或者想法，欢迎一起交流。技术这条路，一个人走总是走得慢，一群人走才能走得更远。
