在过去两年，帮助一大群人相互联系并且延迟基本上接近于零的实时应用层出不穷。用户期望也提高了：用户期望实时视频和音频功能可以完美运行。我们发现，构建实时应用的开发人员希望花更少的时间构建和维护低级别基础设施。开发人员还告诉我们，他们想花更多时间构建真正让他们的创意与众不同的功能。
所以，今天我们宣布推出一款新产品，让开发人员能够构建实时音频/视频应用。Cloudflare Calls 公开了一组 API，可供您用于构建以下各类事项：
带有自定义 UI 的视频会议应用
互动式对话，其中主持人可以邀请精选的观众成员作为发言人“登上舞台”
首重隐私的集体锻炼应用，其中教练可以看到所有参与者，而参与者只能看到教练
远程“炉边谈话”，其中一人或多人可以实时与超过 10,000 人的观众进行视频通话（延迟小于 100 毫秒）
让所有这一切成为可能的协议就是 WebRTC。而 Cloudflare Calls 则是把其中的复杂性抽象出来的产品，其做法是让 Cloudflare 网络成为一个“超级对等“，帮助您打造可靠安全的实时体验。
什么是 WebRTC？
WebRTC 是一种点对点协议，支持两个或更多用户的设备_直接_彼此通信，而无需离开浏览器。在原生实现中，点对点通常很适合只有两个参与者的 1:1 呼叫。但随着您添加更多参与者，参与者常常会遇到可靠性问题，包括视频冻结、参与者不同步。原因何在？因为随着参与者人数的增加，用户设备之间的协调开销也相应增加。每个参与者都需要向其他每个参与者发送媒体，每台计算机中的数据消耗就会呈指数级增长。
选择性转发单元 (SFU) 可以解决这个问题。SFU 是在实时应用中将用户彼此连接的一种系统，它在参与者之间智能地管理和路由视频与音频数据。使用 SFU 的应用彼此之间所需的数据容量更低，因为并不是每个用户都必须向其他每个用户发送数据。当应用程序需要确定谁当前在发言时，或者要在使用 WebRTC 同步转发的情况下发送合适分辨率的视频时，SFU 是实时应用程序的必需部分。
超越 SFU
SFU 的集中式性质也是其弱点。集中式 WebRTC 服务器需要一个区域，这意味着它在世界上大部分地区对于大部分用户很缓慢，而仅对于少数精选区域很快速。
如果只有一个邮局收发全世界的所有邮件，那么世界上大部分人的邮件都会延迟送达。SFU 接收每个用户发送的信息，并将其转发到相应的目的地，就像邮局一样。SFU 得到广泛使用的原因在于，可靠、可配置且经济实惠的规模化开箱即用型替代方法极少。
通常，SFU 是在公共云内部构建的。它们会消耗大量带宽，通过许多设备收发高分辨率媒体。而且它们会带来很高的开发运营开销，需要您的团队手动配置区域和可扩展性。
我们认识到，仅仅提供 SFU 即服务，并不能解决成本和带宽效率的问题。
世界上最大的 WebRTC 服务器
如果您处于由经典 WebRTC 实现提供技术支持的五人视频呼叫中，每个人的设备会直接彼此通信。用 WebRTC 的术语来说，这五个参与者各自称为一个_对等。_此外，五人呼叫的可靠性完全取决于互联网连接信号最弱的人员（或对等）的可靠性。
我们根据一个简单的前提构建了 Calls：_“要是 Cloudflare 可以充当 WebRTC 对等会怎么样？”_Calls 是一个“超级对等”或“横跨全世界的巨大服务器”，允许构建的应用程序超越最小公分母对等或集中式 SFU 的局限性。开发人员可以专注于其应用的优点，而不是试图弥补点对点拓扑中最弱对等的不足。
Calls 并不使用每个参与者都连接到单一位置的集中式服务器的传统 SFU 拓扑。相反，每个参与者都连接到其本地 Cloudflare 数据中心。当另一个参与者想检索该媒体时，会找到托管原始媒体流的数据中心，并自动在数据中心之间转发轨道。如果两个参与者在物理上彼此靠近，其媒体不会满世界跑到某个集中式区域，相反，两者会使用相同的数据中心，从而极大缩短延迟并提高可靠性。
Calls 是一种可配置、全球性、无区域的 WebRTC 服务器，其规模等同于 Cloudflare 不断增长的网络。通过 WebRTC 协议，对等可以发送和接收_媒体轨道。_当您处于视频呼叫中时，您的计算机通常会发送_两个_轨道：一个包含您发言的音频，另一个包含来自您摄像头的视频流。Calls 在整个 Cloudflare 网络中实现 WebRTC RTCPeerConnection API，其中用户可以推送媒体轨道。Calls 还公开了一个 API，用于在相同对等连接上下文中请求其他媒体轨道。
如今，如果有人提到“通过 WebRTC 实时”执行某个操作，我们常常会认为是参与者有 50 人以上的视频会议，其中_每个_参与者都与其他每个参与者谈话，并且_每个_参与者会看到其他 49 个参与者加入和离开会议。通过 Calls API，可以实现单凭普通 WebRTC 无法实现的粒度控制。当您使用 Calls 构建时，您可以充分发挥您的想象力，技术根本不构成障碍。
通过 Cloudflare Calls，您可以利用标准 RTC API，而不会降低性能和可靠性。Calls 在边缘实现 PeerConnection API，从而降低了最终用户直接彼此连接时伴随的不可预测性。Calls 在每个 Cloudflare 位置和每一个 Cloudflare 服务器上运行。由于 Cloudflare 网络可在 10 毫秒内触达世界上 90% 的人群，因此不会带来明显的延迟。
如果您运行自己的 WebRTC 服务器，例如 Janus 或 MediaSoup，那么 Cloudflare Calls 是一种很好的解决方案。Cloudflare Calls 还可以替代 Janus 或 MediaSoup 的现有部署，尤其是在您有客户端在全球范围内连接到单个集中式部署的情况下。
区域：地球
构建并维护您自己的实时基础设施会带来独特的架构和扩展挑战。这需要您在运行自己的 WebRTC 服务器基础设施时，对一些棘手的问题做出回答并不断修正回答，例如：“我们支持哪些区域？”，“用户数需要达到多少，我们才有必要在另一个云区域中新增更多基础设施？”，“如何针对计划外的使用量激增进行扩展？”以及“如何在基础设施使用量很低的时段避免亏损？”。
使用 Cloudflare Calls 则可以忽略这些问题。Calls 使用 Anycast 建立每个连接，因此每个数据包总是路由到最接近的 Cloudflare 位置。其性质是全球性的：您的用户会自动从靠近的位置获得所需数据。Calls 会随着您的使用而扩展，您的团队也不必构建自己的自动扩展逻辑。
回答“问题出在哪里？”，但是速度更快
我们与处理现有 WebRTC 工作负载的客户交谈时，发现一个共性的主题：客户都希望能够更轻松地对问题进行故障排除。一群人通过视频呼叫交谈时，如果用户遇到问题，风险会显著提高。如果某个网页加载失败，用户常常会在几分钟后直接重试。如果视频呼叫发生中断，往往呼叫就结束了。
Cloudflare Calls 专注于可观察性，有助于客户更快找到问题的症结所在。由于 Calls 是基于 Cloudflare 的基础设施构建的，因此我们可以从 OSI 模型的所有层获得端到端可视性。
Calls 提供了 WebRTC Statistics API 的服务器端视图，这样您就可以深入研究每个对等连接以及其中媒体流的问题，而不是仅仅依靠从客户端发送的数据。我们之所以选择它，是因为 Statistics API 是开发人员用于获取关于其体验的信息的标准化位置。它也是浏览器中提供的同一个 API，您目前可能已经在使用它来获取对 WebRTC 连接性能的洞察。
隐私与安全性的核心
使用 Calls 时，参与者不必彼此共享 IP 地址等信息。假设您要构建一个应用，通过视频呼叫将治疗师与患者连接起来。利用传统的 WebRTC 实现，患者和治疗师的设备会直接彼此通信，继而导致 IP 地址等潜在敏感数据暴露。如暴露了 IP 地址等信息，您的用户就容易受到拒绝服务攻击。
如果同时使用 Calls 和 WebRTC，则各个参与者会连接到 Cloudflare 网络。如果有四个人处于由 Cloudflare Calls 提供技术支持的视频呼叫中，这四个参与者的设备各自仅与 Cloudflare 网络通信。最终用户的体验就像点对点呼叫一样，而且安全性和隐私得到了加强。
最后，通过 Cloudflare Calls 传递的所有视频和音频流量都会默认加密。Calls 利用现有 Cloudflare 产品（包括 Argo）以安全高效的方式路由视频和音频内容。
下一步
我们会在今天发布 Cloudflare Calls 封测版。要试用 Cloudflare Calls，可请求受邀并在未来几周查看您的收件箱。Calls 在测试期内免费。我们期待与抢先体验的客户密切合作，一起见证 Calls 从测试版到正式发布的全过程。如果您想立即构建实时视频应用，在扩展传统 WebRTC 基础设施时遇到挑战，或想探索一个好的创意，请在请求受邀时留言，我们会与您取得联系。