本文回答有关 WebRTC 的一些常见问题,这些问题似乎是谷歌搜索的热门话题。内容分享来自 bloggeek 博客,作者:Tsahi Levent-Levi。
前言
几天前,我在谷歌上搜索一些东西,不知怎么就进入了一个页面,上面全是谷歌认为相关或常见的问题。这些问题与我的搜索词并不完全相关(不是直接相关),但它们就在那里。而且它们都是关于 WebRTC 的初级问题。
我恍然大悟,我可能在过去顺便(或更多一点)提到过其中的一些问题,但把它们整齐地放在一起还是很有意义的。下面的内容是针对 WebRTC 初学者常见问题。
WebRTC 是 TCP 还是 UDP?
WebRTC 既不是 TCP 也不是 UDP。同时,WebRTC 既是 TCP 也是 UDP。
不明白?
让我们来理一下。
WebRTC 包含信令和媒体。
信令被视为超出范围,应留给应用程序处理。大多数应用程序将使用 HTTPS 或安全 WebSocket 作为信令传输。HTTPS 通过 TCP 运行……算是吧……因为 HTTP/3 也可以使用 UDP。但大多数情况下,你可以把 WebRTC 中的信令视为 TCP,这样天空就不会塌下来(我们对信令的要求是可靠性和消息顺序,而基于 TCP 的协议就能做到这一点)。
WebRTC 中的媒体希望使用 UDP。它努力尽可能多地使用 UDP,但这并不总是可行的,所以它又回到了使用 TCP 的道路上。但你可以将其视为最后的手段(我们不想陷入这种困境)。
WebRTC 是否仍在使用?
是的,否则你就不会读我的文章了。
当然并不是没有挑战者,而是 WebRTC 仍然是 Web 浏览器中最流行、最常见的实时通信解决方案。
WebTransport + WebCodecs + WebAssembly 也许有一天会取代 WebRTC。但我们还没到那一步。
WebRTC 是免费还是付费的?
免费?付费?都要吗?都不是?
让我们来理清一下思路。
WebRTC 是一项开放标准,由谷歌维护并被所有主要浏览器供应商使用的开源实施方案广受欢迎。
访问 API 和使用 API 都是免费的。
但是,创建大多数有意义的应用程序都需要支付一定的费用。这可以是向 CPaaS 供应商支付 WebRTC 基础设施托管费,也可以是向 IaaS 供应商(如 AWS)支付服务器托管费和带宽使用费(尤其是 TURN 和媒体服务器)。
所以是的,WebRTC 是免费的,但需要付费,尤其是在需要帮助的时候。谷歌不会帮你…
延申阅读:WebRTC 真的免费吗?运行 WebRTC 应用程序的成本
WebRTC 有什么用途?
WebRTC 用于通过 Web 浏览器在互联网上实现实时语音和视频通信,但它绝对不仅限于此。
我见过的用例包括录音、流媒体直播、广播、云游戏、远程遥控操作(远程驾驶汽车)、点对点辅助交付、文件传输……不胜枚举。
WebRTC 是否存在安全风险?
WebRTC 使浏览器能够(并允许)访问您的麦克风、摄像头、显示屏和 IP 地址。这也是你安装的每个语音或视频会议应用程序正常工作所需要的。
这会带来安全风险吗?这要由作为用户的你来决定。
赋予浏览器这样的权力,不仅减少了用户使用时的麻烦,也减少了想要利用这些功能的邪恶第三方的麻烦,因此有些人会认为这增加了安全风险。
对于开发人员来说,这只是意味着他们需要知道并了解自己在做什么,以及如何利用这项技术实现自己的应用,以降低任何潜在风险。值得注意的是,WebRTC 和 Web 浏览器会尽最大努力降低此类安全风险,甚至鼓励开发人员编写安全的应用程序。
Netflix 使用 WebRTC 吗?
没有。
Netflix 可能会在某些地方使用 WebRTC,但在其主要视频流媒体服务中,Netflix 并未使用 WebRTC。
为什么呢?因为 WebRTC 是为实时通信而设计和微调的。因此,它牺牲了质量来改善延迟。
Netflix 恰恰相反。它致力于提供最好的质量,并愿意牺牲一点延迟,为了获得清晰、纯净的视频,你不会介意在电影开始前等待几秒钟。另一方面,如果你的在线视频对话延迟 5 秒,感觉对方就像坐在月球上一样,你一定会很生气。
WebRTC 会被黑客攻击吗?
是的。
一切都可能被黑客攻击。
浏览器正试图尽最大努力降低 WebRTC(以及它们实施的其他技术)的风险,但这是一场军备竞赛…
WebRTC 是否会暴露你的 IP?
这是一个棘手的问题。答案是肯定的,也是否定的。
让我们先来了解一下哪个 IP 地址…
你的设备通常有两个 IP 地址:
- 本地 IP 地址,在本地网络(如家庭网络)内使用
- 公共 IP 地址,由 NAT 分配,用于与 “世界 “通信。
设备上的每个应用程序(包括浏览器)都可以访问本地 IP 地址。
你在互联网上连接的每个网络服务器都会看到您的公共 IP 地址。
在协商 WebRTC 会话时,WebRTC 会使用一种称为 ICE 的机制来发现你的公网 IP 地址,并将你的本地 IP 地址和公网 IP 地址共享给与之连接的对等设备。
在此简要说明一下:
- 没有访问摄像头或麦克风的权限,WebRTC 不会公开本地 IP 地址。
- 任何语音或视频通信应用程序最终都会以类似方式暴露相同的地址
- WebRTC 应用程序可以决定只使用 TURN 中继或媒体服务器,这样就不会向其他用户暴露这些 IP 地址。
- 可以使用浏览器扩展来限制暴露本地 IP 地址的能力
- 如果你的 VPN 在使用 WebRTC 时泄露了你的公共 IP,则表明该 VPN 无法正常工作
什么比 WebRTC 更好?
说真的,我也不知道。
看情况吧。这是个勉强的答案,但也是唯一的答案。
问题应该更具体。它应该包括你想建立的是什么,目标受众是什么,以及你想使用什么媒介。
对于流媒体直播,WebRTC 可能不是最合适的。尤其是如果你能忍受 2 秒的延迟(在这种情况下,LL-HLS 和 LL-DASH 将是更好的解决方案)。
至于视频会议……嗯……我会首先默认选择 WebRTC。然后再想办法戳穿我的决定,选择其他方案——专有方案——因为没有其他方案了…
延申阅读:WebRTC 是一项技术而非解决方案
WebRTC 比 Websocket 更好吗?
从苹果到橙子。
我会同时使用。在同一个应用程序中,我是认真的。
WebSocket 用于信令,WebRTC 用于媒体。
有两个地方你可以把 WebRTC 和 WebSocket 看作替代方案:
- WebRTC 的数据通道本质上是双向的、点对点的。在大多数情况下,我还是会使用 WebSocket。除非我对低延迟或隐私要求很高
- 以实时流媒体为目标。但那时我可能会选择 WebTransport,而不是 WebSocket,这也是一种前瞻性思维……
Google 是 WebRTC 吗?
坦率地说,谷歌就是谷歌。不知道这里的问题是什么 🤣
谷歌和 WebRTC 的关系非常有趣。
这一切都源于谷歌收购了 GIPS,一家获得媒体引擎许可的公司。稍后,WebRTC 在标准化组织中公布,谷歌将 GIPS 媒体引擎变成了开源实现,将其集成到 Chrome 浏览器中,并在其顶部放置了 API–这些 API 就是 WebRTC API 规范(或当时足够接近的规范)。
这已经是 10 多年前的事了。从那时起,WebRTC 不断发展,谷歌对它的实现也是如此。
谷歌内部将 WebRTC 用于 Google Meet 及其他产品和项目。
实际的 WebRTC 项目是开源的。由谷歌负责维护,而且大部分贡献都是谷歌的。
WebRTC 需要服务器吗?
是的。WebRTC 需要服务器,事实上,它需要多个服务器。
首先,你需要从某个地方下载应用逻辑,并向你想与之对话的人发出信号。这需要一个信号服务器。
然后,在连接 WebRTC 会话时,有时会出现媒体没有直接路径的情况。在这种情况下,就需要使用 TURN 服务器。TURN 服务器也可充当 STUN 服务器,但 STUN 服务器与信令服务器不同。
此外,你可能还想花点心思——开个群组会议、录点东西。这些功能几乎总是意味着你需要添加一个媒体服务器。
延申阅读:WebRTC媒体服务器是什么
WebRTC 需要互联网吗?
是的。
今天的一切都需要互联网。就连你阅读本常见问题集也需要互联网。
WebRTC 可以在本地网络或专用网络中运行,无需连接公共互联网。但它仍然需要 IP 网络才能运行。
WebRTC 使用 SSL 吗?
是的。
让我们先从定义开始: 对我来说,SSL 和 TLS 是同一个概念。
HTTPS 和 WSS(安全 HTTP 和安全 WebSocket)都在 TLS 的基础上运行,所以它们也是 SSL。
Web 浏览器实际上强制应用开发人员在托管这些服务的页面上使用 HTTPS,这意味着 WebRTC 使用的所有信令都将通过 HTTPS 或 WSS 完成。
媒体使用 SRTP,即安全 RTP,它不使用 TLS(因为它不是通过 TCP 运行的)。也就是说,当会话需要通过 TURN 服务器中继时,最终可能会通过 TURN/TLS 中继。
原文:https://bloggeek.me/faq-webrtc-beginners/
本文来自作者投稿,版权归原作者所有。如需转载,请注明出处:https://www.nxrte.com/jishu/webrtc/42403.html