我可以相信 WebRTC getStats 的准确性吗？是和不是，WebRTC getStats 我们都必须使用，也就是说，您真正的问题可能完全在别处。
您可以而且应该相信 WebRTC getStats 的准确性，但与其他所有事情一样，您也应该保持一定程度的怀疑。
与任何软件一样，libwebrtc 及其扩展的 getStats 也存在错误。这些错误会随着时间的推移得到修复。修复它们的优先级主要与谷歌自己的服务受到的影响以及对其余问题的看似武断的优先次序有关。
请参阅下文，详细了解我们遇到问题的原因以及您可以采取的措施。
WebRTC getStats 简史
WebRTC 于 2011 年某个时间段宣布，Chrome 中的初始公共代码于 2012 年发布。协议本身稳定下来，并于 2021 年 1 月由 W3C 正式发布。就在……10 年后。
在这 10 年之间，进行了很多讨论，并且修改了 WebRTC 标准规范的 API ，以适应提供的反馈并包含其他用例和要求。
在 WebRTC 在 Web 浏览器中实施并发布以便开发人员可以使用它们的同时，我们也进行了这些讨论。在 WebRTC 正式“标准化”之前的几年，我们有成百上千个使用 WebRTC 的生产应用程序，通常是付费客户。
在某些时候，标准规范中的 getStats 实现与谷歌在 Chrome 中的实现有所不同，最终有两个主要替代方案：
- 符合规范的 getStats – 符合标准规范的新 API。鉴于此规范是由 Google 员工撰写的，因此它最终成为对 Chrome 实现内容的描述也就不足为奇了，无论它是否有意义。这是在 2017 年 1 月添加到Chrome 58中的。
- Legacy getStats ——Chrome 中的原始实现。
这使得从一个切换到另一个成为一个挑战：
- 谷歌可以只实现新的统计信息，但这会破坏使用遗留 getStats 实现的应用程序
- 开发人员希望使用符合规范的统计数据，但需要一个支持它们的浏览器
决定两者之间的区别在于调用 getStats() 的方式。基于回调的调用返回遗留统计数据，同时使用承诺返回符合规范的 getStats。这背后的逻辑是，promises 是当时引入 Javascript 的新结构，因此目前使用遗留 getStats 的开发人员还没有使用 promises。
这种方法在过去 6 年中运行良好，许多应用程序都采用了符合规范的 getStats：
当 Google Meet 停止使用旧版 API 时，我们观察到使用率下降了一步（即下降的蓝线）。也就是说，仍然有一些异常值使用旧的 getStats。他们将无法在 2024 年这样做。
跟上 WebRTC getStats 变化的步伐
在testRTC，我们为 WebRTC 应用程序的整个生命周期提供工具。其中包括测试和监控服务。因此，我们严重依赖 getStats。
多年前，我们不得不实施从遗留统计数据到符合规范的统计数据的迁移。
然后是 2022 年，Google 对 getStats 中的统计数据进行了内务管理更改。它从 Chrome 107 开始，一直持续到今天。对于每个这样的版本，我们都需要有经验的 WebRTC 开发人员来检查、测试和修复我们的代码，以确保我们的服务正确地收集统计信息。所有这些都是为了支持 Google 不时在 WebRTC getStats 中添加到 Chrome 的更多指标。
在这方面，我们的工作比大多数人都难，因为我们需要收集和支持所有统计数据——我们拥有的客户群各不相同，我们永远不知道他们会对哪些指标感兴趣。
在过去的几个月里，跟上 getStats 的任务一直是一个挑战。那是因为在每个版本中都会有一些其他的变化。每一步都是合理的。需要。次要的。但它带来了我们需要在自己的规划和路线图中做的改变。
对其他人来说，这样的变化也带来了漏洞。有时需要更新和升级开源组件或修复自己的代码。
这是一件好事
重要的是要声明——谷歌在这里进行的更改和工作是为了更好。
寻求符合规范的 WebRTC getStats 实现意味着我们拥有我们期望工作的实际文档。它还意味着与其他浏览器和组件的互操作性（假设它们也努力符合规范）。
性能的改进和优化最佳实践意味着 WebRTC 应用程序的性能和代码总体上更好。
删除无用的和弃用/未使用的统计信息和类似组件意味着更小的代码库，更少的边缘案例和要测试的“东西”。
这就是我们希望 WebRTC 实现的样子。
事实上，我们需要经受这种考验，这是我们需要为此付出的代价。如果 Google 能够提前制定此类更改的计划（不是通过零星的 PSA，而是作为一种公共路线图），那就更好了。这将使那些运行此类应用程序的人能够更好地规划。但是它就是这样啊，坦率地说我们会为免费付出代价。
Chrome 的 WebRTC getStats 实现可能不是错误指标值的原因
然后是bug。你通过getStats获得的指标似乎并不反映现实。
发生这种情况通常有 3 个原因：
- Chrome。有一个 Chrome 错误会通过 getStats 导致错误的指标结果。正如我之前所说，当涉及到他们的 libwebrtc 库时，Google 会根据优先级和积压情况再来修复。
- You。该值也许是正确的，您只是不明白它的含义或计算方式，那是因为在 getStats 中几乎没有记录每个指标的方法。
- The other side。当您的浏览器与非浏览器设备、本机移动应用程序或媒体服务器交互时，它会通过 WebRTC getStats 从由其他设备计算、生成和发送的 RTCP 报告中获取大量用于报告特定指标的数据。那一面也可能有错误（极有可能甚至更多）
这里要记住几件事：
👉 WebRTC 被许多内部浏览器使用，十亿人？
👉 它被数以千计的直接或间接开发在其上的应用程序所采用。
👉使用统计数据是优化媒体质量的标准做法，大多数大型 WebRTC 应用程序已经严重依赖它。
❓ 为什么您的应用程序和用例在信任 WebRTC getStats 方面应该有所不同？
您可以对 WebRTC getStats 更改做些什么？
我确实有一些建议给你：
- 理解并假设事情会发生变化，会发现（并修复）错误，并且在大多数情况下，getStats 是一个非常强大和有用的工具。
- 针对最新的浏览器版本测试您的应用程序（及其统计信息），这应该包括即将到来的测试版。
- 确保您的媒体服务器和其他组件是最新的，特别是在 RTCP 报告中。有疑问时，质疑他们在 libwebrtc 之前的行为（记住他们也需要在谷歌在 Chrome 中实现 WebRTC 之后运行）
- 订阅并关注WebRTC Insights。这就是我们标记即将发生的问题的地方，以及我们迎合的其他事情。
原文链接：https://bloggeek.me/trust-webrtc-getstats-accuracy/
本文来自作者投稿，版权归原作者所有。如需转载，请注明出处：https://www.nxrte.com/jishu/webrtc/15566.html
