什么是网络探测？RTC如何提前预判网络质量

一. 网络探测在做什么

点击”加入会议”后，系统不会立即建立连接。

它会先花一两秒钟做个测试：往服务器发送一些数据包，测量带宽、延迟和丢包率。带宽决定了视频质量的上限。家里的宽带标称100M，但上行通常只有10M左右。10M的上行能发720p视频，但如果想发1080p就很勉强了。

延迟影响对话的节奏。数据从你这里到服务器，再转发给对方，来回一趟要花多长时间？延迟低的时候对话很自然，延迟高了就会有”慢半拍”的感觉，多人会议里更容易出现几个人同时开口又同时停下的尴尬。

丢包率反映网络的稳定性。发出去100个包，丢了5个，丢包率就是5%。丢包会导致画面出现马赛克、声音断续。轻微丢包用户可能注意不到，丢包率超过10%画面基本没法看了。

测完这三个指标，系统会根据结果决定用什么配置：网络好就开高清，网络一般就降到标清，网络差就提示用户”当前网络较差，建议关闭视频”。

---

二. Last Mile：最后一公里的挑战

网络探测中有个重要概念叫Last Mile（最后一公里）。

这个词原本指的是电信网络从中心机房到用户家里的最后一段线路。在RTC领域，Last Mile指的是从用户设备到最近的服务器节点这段网络路径。

Last Mile是整个网络链路中最不可控、最容易出问题的部分。

用户可能在咖啡厅连着拥挤的公共Wi-Fi，可能在地铁上用着信号不稳定的4G，可能在老旧小区用着共享带宽严重的宽带。这些环境下，即使服务器之间的骨干网络再快，Last Mile的质量也会成为瓶颈。

更麻烦的是，Last Mile的状况是动态变化的。你刚进会议时网络可能很好，但过了10分钟，咖啡厅来了一群人都在刷视频，Wi-Fi就拥塞了。你在家里开会，家人突然开始下载大文件，上行带宽就被占满了。

所以网络探测不仅要在通话前做一次，通话过程中也要持续监测Last Mile的状况，实时调整策略。

---

三. 网络探测的基本方法

带宽探测

测带宽最直接的方法是发送一定量的数据，看多长时间能传完。

发送端以不同的速率发送测试数据包，接收端记录实际接收到的数据量和耗时。如果以1Mbps的速率发送，接收端也能稳定收到1Mbps，说明带宽至少有1Mbps。然后逐步提高发送速率，2Mbps、3Mbps…直到接收端开始出现丢包或延迟显著增加，这个临界点就是可用带宽的上限。

这种方法叫容量探测（Capacity Probing）。它的问题是比较耗时，而且会占用带宽。如果每次进会议前都要跑几秒钟的带宽测试，用户会觉得等待时间太长。

另一种方法是被动估计。不主动发大量测试数据，而是在建立连接的过程中，通过观察信令数据包的传输情况来估算带宽。WebRTC在ICE协商阶段会发送一系列STUN/TURN消息，这些消息的传输速率和丢包情况可以提供初步的带宽信息。

被动估计速度快，但准确性稍差。实际应用中，通常会结合两种方法：先用被动估计快速得到一个大概值，然后在通话建立后的前几秒，通过实际音视频数据的传输情况来修正这个估计值。

延迟测量

测延迟比测带宽简单。发送一个数据包到服务器，服务器收到后立即返回，记录往返时间（RTT）。

但只测一次不够准确。网络延迟会波动，某一次测到的值可能是偶然的高峰或低谷。通常会连续测几次，取平均值或中位数。

更细致的做法是测不同大小数据包的延迟。小包（几十字节）的延迟主要反映网络传输时间；大包（上千字节）的延迟还包含了排队时间和处理时间。对比小包和大包的延迟差异，可以判断网络是否拥塞。

丢包率检测

发送一系列编号的测试包，接收端统计收到了哪些包，没收到哪些包。丢失的包数除以总包数，就是丢包率。

丢包率不仅要看数值，还要看模式。如果100个包里丢了5个，但这5个是连续的，这叫突发丢包（Burst Loss），通常是网络短时间拥塞导致的。如果这5个包分散在不同位置，这叫随机丢包（Random Loss），可能是信号干扰或设备问题。

突发丢包对RTC的影响更大。连续几个包丢失，可能导致视频关键帧丢失，画面会持续花屏直到下一个关键帧到达。随机丢包虽然也会影响质量，但有丢包隐藏（PLC）等技术可以部分修复。

抖动测量

网络抖动（Jitter）指的是数据包到达时间的不规律性。

假设发送端每隔20ms发一个包。如果网络稳定，接收端也应该每隔20ms收到一个包。但实际网络中，可能第1个包和第2个包之间隔了18ms，第2个和第3个之间隔了25ms，第3个和第4个之间隔了15ms。这种间隔的变化就是抖动。

抖动会影响播放的流畅性。RTC系统通常会用Jitter Buffer（抖动缓冲区）来平滑这种波动，但缓冲区太大会增加延迟，太小又容不下抖动，需要根据实际测量到的抖动大小来调整。

---

四. 网络探测的实现细节

选择合适的探测目标

网络探测不能随便找个服务器就开始测，测试目标要和实际通话时使用的服务器尽可能接近。

如果用户在北京，你拿美国的服务器来做网络探测，测出来延迟500ms，丢包率10%。但实际通话时用户连的是北京的服务器，延迟可能只有30ms，丢包率1%。这个探测结果就没什么参考价值。

理想情况下，探测目标应该和后续实际使用的RTC服务器是同一个节点。这样测出来的网络质量才真实反映通话时的情况。

有些RTC系统会先做一轮粗略的节点选择——根据用户的IP地理位置，选出几个可能的最近节点，然后分别对这几个节点做网络探测，最终选择质量最好的那个作为通话服务器。

控制探测时长

网络探测不能太慢，也不能太粗糙。

太慢的话，用户点了”加入会议”后要等好几秒才能进去，体验不好。太快的话，测出来的数据不准，可能刚好测到网络的一个短暂波动，不代表真实的平均水平。

通常网络探测控制在1-3秒之内。在这个时间窗口里，发送足够多的测试包（比如100个），既能得到统计意义上比较可靠的结果，又不会让用户等太久。

有些系统会做后台预探测。用户打开App的时候，还没点进任何会议，SDK就在后台悄悄做网络探测，把结果缓存起来。等用户真正点击加入会议时，直接用缓存的探测结果，就不需要再等探测时间了。

但后台预探测有个问题：网络状况可能变化了。5分钟前测的网络很好，现在可能已经变差了。所以通常会设置缓存的有效期，比如30秒或1分钟，过期了就重新探测。

多路径探测

现代设备通常有多个网络接口：Wi-Fi、4G/5G、以太网。网络探测可以同时测试多个接口，看哪个质量更好。

手机同时连着Wi-Fi和4G时，可以分别探测两条路径。如果Wi-Fi延迟低但丢包率高（可能是信号弱），4G延迟稍高但很稳定，系统可以建议用户切换到4G，或者做一个智能选择。

有些高级的RTC实现支持多路径传输。音频走稳定性好的路径（比如4G），视频走带宽大的路径（比如Wi-Fi）。网络探测可以为这种策略提供决策依据。

---

五. 根据探测结果做优化

网络探测的数据本身没有太大价值，关键是拿这些数据来做什么。

动态调整视频参数

探测发现上行带宽只有500Kbps，那就不要尝试发送1080p视频了，直接降到480p甚至360p。

探测发现下行带宽充足但CPU性能不够（通过设备信息判断），可以选择接收低分辨率的流，降低解码压力。

探测发现丢包率超过5%，可以启用更激进的FEC（前向纠错）策略，用冗余数据对抗丢包，虽然会占用额外带宽，但总比画面一直花屏要好。

提前告知用户

探测发现网络质量很差，可以在用户进入会议前给个提示：”当前网络状况不佳，建议关闭视频或更换网络环境”。

有些应用会显示网络质量评级：”优秀””良好””一般””较差”。这个评级就是基于探测数据计算出来的——延迟、带宽、丢包率、抖动等指标综合评估。

用户看到”网络较差”的提示，可能会选择先不进会议，换个Wi-Fi或者找个信号好的地方再进。这比进去之后发现卡顿，然后退出重进要好得多。

选择最优编码器和传输策略

探测发现网络很稳定（低抖动、低丢包），可以选择压缩率更高但对丢包敏感的编码器，榨干带宽潜力。

探测发现网络不稳定（高抖动、高丢包），可以选择鲁棒性更好的编码配置，牺牲一些压缩效率来换取稳定性。比如减少P帧依赖链的长度，多发一些I帧，这样即使中间有帧丢失，影响也不会扩散。

探测发现延迟已经很高（比如200ms以上），可以减小Jitter Buffer的大小，降低播放延迟，虽然可能会增加卡顿风险，但至少不会让延迟继续累积。

---

六. 通话过程中的持续探测

网络状况不是静态的，通话过程中也需要持续监测。

被动监测 vs 主动探测

通话建立后，RTC系统会持续收集网络质量数据。这可以通过两种方式：

• 被动监测：分析实际音视频数据的传输情况。统计发送了多少包、收到了多少包、丢了多少包、往返延迟是多少。这些数据本来就在传输过程中产生，不需要额外开销。
• 主动探测：定期发送专门的探测包，类似通话前的网络探测。主动探测的好处是可以测试当前没有使用的传输路径（比如备用服务器），或者测试更高的码率（比如当前用720p，想试试能不能升到1080p）。

两种方式通常会结合使用。被动监测持续运行，实时反映当前网络状态；主动探测在特定时机触发，比如检测到质量下降时，主动探测一下其他路径是否更好。

自适应策略的触发

当检测到网络质量下降，系统会触发自适应调整。

• 降码率：从1080p降到720p，从720p降到480p。
• 降帧率：从30fps降到15fps。
• 关闭视频：只保留音频，释放大部分带宽。
• 切换路径：从当前服务器切换到备用服务器，或者从Wi-Fi切换到4G。

这些调整不能太频繁，否则用户会感觉画质一会儿清晰一会儿模糊，反而体验更差。通常会设置一个稳定期，比如检测到网络变差后，观察5-10秒，确认是持续变差而不是短暂波动，才触发调整。

反过来，当网络恢复时，也不能立即升回高码率。万一只是短暂恢复，升上去又掉下来，用户体验也不好。通常会等网络稳定一段时间（比如30秒），再逐步提升质量。

---

七. 实际应用中的挑战

NAT和防火墙的影响

网络探测需要发送UDP数据包，但有些网络环境对UDP有限制。

企业防火墙可能只允许特定端口的UDP通信，或者完全禁止UDP。这时候网络探测可能会失败，或者测出来的结果不准确——测试包通过了，但实际音视频数据传输时会被拦截。

更隐蔽的问题是NAT的会话超时。NAT会为每个UDP连接分配一个端口映射，但这个映射有时效性，可能60秒或120秒后就失效了。网络探测时测出来网络很好，但通话建立后过了几分钟，NAT映射失效，连接就断了。

移动网络的特殊性

手机在移动网络下，基站切换会导致网络路径突变。

用户在地铁上开会，地铁进站时信号从基站A切换到基站B，延迟和丢包率可能突然跳变。网络探测测的是当前基站的质量，但下一秒切换到另一个基站，情况可能完全不同。

移动网络还有个特点是非对称性。上行和下行可能走不同的路径，质量差异很大。只测下行或只测上行，都不能全面反映网络状况。

探测的准确性问题

网络探测用的是小数据包（通常几百字节到几KB），但实际音视频传输的数据包可能更大，传输模式也不同。

测试包可能顺利通过，但实际发送高码率视频流时，触发了网络拥塞控制，开始丢包或增加延迟。

另一个问题是竞争流量。网络探测时网络可能很闲，但通话建立后，网络上可能有其他流量（比如用户同时在下载文件），带宽被占用，质量下降。

所以网络探测给出的是一个初步评估，不是绝对准确的预测。通话过程中的持续监测和自适应调整同样重要。

---

八. 网络探测的未来方向

机器学习优化

传统的网络探测基于规则和阈值判断——延迟高于多少算差，丢包率超过多少需要降码率。

但网络质量和用户体验的关系很复杂。同样的延迟和丢包率，在不同编码器、不同分辨率、不同场景下，对体验的影响不同。

机器学习可以从大量真实通话数据中学习这种复杂关系。根据网络探测的数据，预测用户实际体验的MOS评分（平均意见分），然后基于这个预测来决策——是否要降低码率、是否要切换服务器、是否要提示用户。

端到端质量预测

现在的网络探测主要看Last Mile和服务器之间的网络质量。但实际通话是端到端的，双方的网络质量都会影响体验。

未来的网络探测可能会做双向探测。A和B要视频通话，不仅测A到服务器的网络，也测B到服务器的网络，甚至测A到B的直连路径（P2P）。综合双方的网络状况，给出整体的质量预测。

5G和网络切片

5G网络引入了网络切片（Network Slicing）技术，可以为不同应用提供差异化的网络质量保障。

未来RTC应用可能会和运营商合作，为视频通话流量申请专用的网络切片。网络探测可以检测当前是否在5G网络切片下，如果是，就可以使用更高的码率和更低的延迟配置，因为网络质量有保障。

---

总结

网络探测是RTC系统的”侦察兵”，在通话建立前和通话过程中，持续评估网络质量，为系统决策提供依据。探测的核心指标包括带宽、延迟、丢包率、抖动。这些指标不仅要测数值，还要看变化趋势和模式。

Last Mile是网络质量的关键瓶颈，也是最难预测和控制的部分。网络探测需要针对实际使用的服务器节点进行，才能准确反映真实情况。

探测结果要转化为实际行动：动态调整视频参数、选择最优传输策略、提前告知用户、在通话过程中持续优化。

网络状况是动态变化的，所以网络探测不是一次性的，而是持续的。通话前探测、通话中监测、质量下降时重新探测，形成闭环。