【问题标题】:Why use WebRTC/similar libraries? [closed]为什么要使用 WebRTC/类似库? [关闭]
【发布时间】:2021-04-05 10:50:10
【问题描述】:

目前有一个功能正常的 Android 应用,用户可以在其中互相发送消息、发送文件和视频通话。这是通过通过普通的旧 Java 套接字 (TCP) 发送对象来实现的。从一些研究来看,现有软件(例如 Discord 或 Signal)似乎使用 WebRTC 或他们自己的 fork/类似库。

鉴于 Discord 最初是使用 Web 技术(React 堆栈)开发的,然后使用 Electron 或 React Native 转换为原生,因此使用 WebRTC 是有意义的。但是对于我的用例,使用上述库是否有先天优势,无论是可扩展性、安全性等,还是我的实现是否合适?

【问题讨论】:

  • 基于 TCP 的视频通话需要非常好的网络连接;首先,WebRTC 增加了对通信条件的弹性。
  • WebRTC 不是通过利用 UDP 来做到这一点的吗?如果是这样,弹性不是 WebRTC 本身固有的东西的产物,它可以单独实现吗?
  • 通过 UDP 构建自己的通信服务并不容易;添加 FEC 和带宽控制(包括调整摄像头和编码器)使这项任务值得几个人年。

标签: android webrtc voip


【解决方案1】:

WebRTC 提供了一些通过 TCP 媒体无法实现的功能(或难以实现)

由于背压/拥塞反馈,通过 TCP 进行实时通信很困难。 TCP具有可靠的传递。你可以依赖所有到达的东西,但你没有得到足够的反馈。通过 UDP 通信,您可以测量抖动/丢包率/RTT 并调整媒体的比特率。这样可以确保您只发送您的网络支持的内容,并且您可以保持通话的实时性。

WebRTC 具有强制性安全性。如果您使用 WebRTC,您将获得 DTLS+SRTP。当然,您可以通过 TCP 连接使用 TLS 来实现这一点。它只是为您完成所有工作。

WebRTC 有 P2P。您可以进行 NAT 遍历并连接两个对等方,而不必通过第 3 方服务器路由任何媒体。 TCP NAT Traversal 是可能的,但我自己从未见过。

WebRTC 随处可用。使用 TCP 协议,您需要在每个新平台上实现代码。有了 WebRTC,我已经有了适用于 C、C++、C#、Go、Python 和 Typescript 的 SDK。我几乎可以在任何地方轻松启动和运行。

很难理解 WebRTC 到底是什么,因为它既是 API、协议又是库。查看 WebRTC 以获取好奇的What is WebRTC?。如果您有任何反馈希望听到,那么有很多价值一开始并不明显。

【讨论】:

  • 这里提到的所有特性中,TCP NAT 是最少的。但总的来说,这是一个很好的总结。
  • ice-tcp 实际上不适用于 NAT 穿越。它在 WebRTC 中的支持一般是服务器,两个浏览器甚至不能直接进行 tcp 通信。
猜你喜欢
  • 2013-01-04
  • 2011-02-23
  • 2011-07-23
  • 2010-10-01
  • 2017-02-17
  • 2011-08-21
  • 2015-03-11
  • 2013-02-17
  • 1970-01-01
相关资源
最近更新 更多