Chrome 浏览器将发布周期改为两周，你的 WebRTC 应用进展如何？

Chrome 将转为两周一次的发布周期。这一变化将于今年 9 月开始实施。此前，其发布周期为四周。一切都在加速推进，如果你正在使用 WebRTC 进行开发，请务必留意并做好准备。

作者：Tsahi Levent-Levi
原文：https://bloggeek.me/chrome-2-week-release-cycle-webrtc/

要点总结

• Chrome 现在每两周发布一次更新，这给必须快速适应的 WebRTC 开发人员带来了挑战。
• libWebRTC 的变更在本月导致多个服务出现问题，凸显了快速更新对稳定性的影响。
• 随着 Chrome 的发展速度加快，其他浏览器厂商也可能会加快发布周期，这将使开发和测试变得更加复杂。
• WebRTC 开发人员必须加快发布节奏，并考虑采用 Canary 版本发布模式，以跟上变化的步伐。
• CPaaS 和视频 API 供应商在同步更新 SDK 以适应 Chrome 的快速更新方面面临着重大挑战，这引发了运营方面的担忧。

Chrome 的更新速度比你的更新周期更快

敏捷开发兴起后，我们曾尝试过每月一次、持续迭代，或是介于两者之间的模式。

在 rtcStats，我们最初采用每两周一次的节奏。后来调整为三周一次，这更符合我们的日程安排，也更适合我们的团队规模和目标受众。

Chrome 呢？它以前是 6 周，后来缩短到 4 周，现在是 2 周。如今它的迭代速度已经超过了绝大多数竞争对手。就连 Chromium 的集成商们现在都在抱怨跟不上它的节奏。暂且先忽略那些可能发布速度快到连自己都跟不上的生成式 AI 巨头，我们稍后会从另一个角度来谈谈它们。

在撰写本文时（非发布时），我的 Chrome 运行的是 147 版，并且刚刚开始上传更新。我对此毫不在意。毕竟在 Chrome 过去的 50 或 100 次版本更新中，我根本没感觉到任何变化。对于用户和大多数 Web 开发者来说，这些更新是无形的。没必要在意。

但对 WebRTC 开发者而言？那完全是另一回事。WebRTC 拥有相当庞大的 API 接口，而这仅仅是冰山一角。

仅在本月，我们就遭遇了多起服务中断和开源媒体服务器故障，原因在于 libWebRTC 更改了发送反馈的实现方式，并非因为它之前不遵循规范，也并非现在不遵循，仅仅是因为它调整了某些细微的行为。但其他软件实现依赖于当前的行为。

这个漏洞只在稳定版中被发现，在测试版过程中漏检了。Amazon Chime的工程师在测试版中发现了这个漏洞。

情况发展到我们不得不向所有客户发送一封特殊的、非例行的电子邮件，以便他们确定自己是否也受到了影响。

在测试版阶段发现这些问题能让一切更稳定。但 Chrome 版本之间原本四周的发布周期现在缩短到了两周。

Chrome 是通往网络的窗口

仅 Chrome 浏览器在全球就拥有约 38 亿至 42 亿用户，占据了所有设备浏览器市场份额的约 65%。但这仅仅是冰山一角。其底层开源引擎 Chromium 为近 30 款浏览器提供支持，包括 Edge、三星浏览器、Opera、Brave、Vivaldi、Arc等等。超过 70% 的网络浏览活动都是通过 Chromium 引擎完成的。

接下来是应用层。仅在 Mac App Store 上，就有超过 8000 款应用由Electron （基于 Chromium 构建）提供支持，例如 VS Code、Slack、Discord 和 Spotify 的桌面客户端。CEF（Chromium Embedded Framework）运行于 Steam、Epic Games Launcher 和数百种企业工具中。同样基于 Chromium 的 Android WebView则为几乎所有显示网页的 Android 应用渲染内容。

当安全研究人员在 Chromium 中发现漏洞时，影响范围并不局限于一个浏览器，而是会波及互联网的大部分渲染平台。

像 Chrome 这样的产品改变发展速度，意味着它周围的整个行业都会受到影响。

谷歌为何加速发展

• Chrome/Chromium 的庞大规模使其成为安全研究人员和攻击者共同关注的焦点。
• GenAI如今已成为攻防双方的倍增器：防御方能更快地发现CVE漏洞，攻击者能更快地编写漏洞利用程序。应对之策？更快地修复漏洞。

GenAI 的那件事值得深思。在谷歌那份言简意赅的声明中（很可能是 Gemini 起草的），他们暗示了这项技术是如何实现的。他们没有提及原因，但如果你仔细阅读以下内容，答案显而易见：

“[…] 得益于近期流程的优化，我们相信此次调整将保持我们一贯的高稳定性标准。”

让我们先来分析这句话的前半部分“近期流程的优化”，这很可能部分归功于将生成式 AI（GenAI）引入Chromium 的整体开发流程。自动化程度越高，迭代速度就越快。

虽然 AI 本身并非自动化，但如今 AI 确实对自动化提供了极大助力。它使我们在更短的时间内，能在更多领域实现自动化。我最近也在利用它来加速我自己的内部流程，因此我很容易就能想象出这在 Chrome 这种规模上是如何实现的。

未被提及的另一点是，这种速度同样被攻击者所利用，那些出于各种原因试图发现并利用 Chrome 漏洞的人。

在过去的两期《WebRTC Insights》中，我们评论了共计 12 个已报告的安全漏洞。

而在整个 2025 年，我们仅报告了 6 个。

今年我们已超过了历史最高纪录（即2021年的17个漏洞），而现在甚至还没过半。

原因显而易见，利用 GenAI 发现安全漏洞并进行修补。在双方均已采用生成式 AI 的安全军备竞赛中，这已成为当务之急。我们有望最终减少进入稳定版本的漏洞数量。

鉴于这场猫鼠游戏将持续进行，谷歌不得不加快步伐。因为显然他们无法堵住所有漏洞，因此必须在漏洞修复速度上做得更好、更高效。

挑战何在？谷歌拥有维持这种节奏的工程实力，但即便如此，也必须有生成式 AI 和 Gemini 作为后盾。而大多数 WebRTC 供应商并不具备这种实力。

你拥有这种工程实力吗？

当 Chrome 发布速度加快时，什么会出问题

RTP 报头扩展编号方式的变更、哪些报告会被捆绑到同一个数据包中、允许进行哪些类型的SDP 修改……

你永远无法预料 Chrome 中 WebRTC 的实现会在何时何地给你带来麻烦。这个月？Janus 和 Amazon Chime 都因为一次更新而出现故障。Microsoft Teams 和 Firefox 也各自遭遇了问题。

看似无害的小问题，事后你会说：“显然，谷歌应该更清楚这一点，并在更新前进行测试并发布公告。” 但他们没有这样做，而且这也不是他们的责任。谷歌不可能考虑到所有极端情况和突发事件。作为应用开发者，你需要根据自己的用例和需求来考虑这些问题。现在，你需要加快思考和行动的速度，跟上 Chrome 的发布速度。

在我们的现实中，Chrome 会破坏 WebRTC 应用。

这不是会不会发生的问题，而是何时发生的问题。

即使问题发现得足够早，用来缓解问题的时限也已经缩短了两周。

记住，谷歌不会为了你而回滚浏览器版本。用户也不会为了你而回滚到之前的 Chrome 版本。如今，他们更换供应商的速度比等你还快。

祈祷并不能解决问题

但一旦你需要使用常规浏览器访问，你就只能听天由命，任由 Chrome 的版本更新摆布。WebRTC 仅用于 0.3% 的 Chrome 页面加载。你的应用程序一旦崩溃，就如同苍蝇被火车撞了一样。

而那个带有固定版本的 Electron 应用呢？它虽然带来了稳定性，但也积累了安全债务。发布周期加快意味着债务累积得也更快。

我们需要更好的解决方案。同时，提高跑步速度也变得越来越重要，同时也更具挑战性。

基础设施团队需要变得更加灵活

当你在使用 Chrome 时遇到问题，必须迅速响应。仅仅使用 Chrome 的测试版可能不够。这些测试版会在两周内升级到正式版并投入生产环境，留给你调查、修复和部署因 Chrome 中 WebRTC 实现行为变更而导致的故障的时间非常有限。

对许多人来说，这意味着要将 Canary 版本作为持续测试的一部分。考虑到 Canary 版本运行过程中可能出现的大量误报，这可不是什么好事。

你还应该考虑如何加快基础设施中与 WebRTC 相关的所有组件的发布节奏，尤其是TURN和SFU服务器，但处理 WebRTC 的信令和应用程序逻辑也同样需要加快。对于 WebRTC 应用程序开发人员来说，能够在不到一周的时间内完成修复和部署比以往任何时候都更加重要。

你准备好了吗？

自建 vs. 购买，两周发布周期版本

CPaaS 和视频 API 供应商面临的难题是，既要快速更新其 SDK，又要吸引客户升级到更新后的 SDK——在很多情况下，这并非易事。

这就引出了依赖第三方供应商的问题。如果你属于这种情况，你确定它能满足你的需求吗？一旦它满足需求，你是否准备好在自己的代码库和应用程序中快速更新和升级他们的 SDK？

这里没有简单的答案，只有更多你需要尽早处理的问题。

浏览器作为移动部件

这不仅仅关乎 Chrome 浏览器。Chrome 是指明了方向。其他浏览器厂商需要多久才能加快发布速度？Firefox 最近几周也发布了不少安全补丁。这预示着未来的趋势，还是仅仅是一次性投入？

Chrome 的发展速度为其他厂商树立了标杆。

虽然 WebRTC 的标准化和规范基本完成且较为稳定，但其实现却一直在不断变化：代码清理、优化、安全补丁、引入新的编解码器和算法等等。所有这些都在改变浏览器中 WebRTC 的行为和实现方式，这些对最终用户来说无关紧要，但对开发者而言却至关重要。最终结果就是系统不稳定，需要开发者进行更多测试。

对你而言？浏览器兼容性是一个持续的运营问题，而不是一次性的集成任务。