【发布时间】：2016-12-17 01:29:47
【问题描述】：
我知道网络浏览器对同时 http 请求等的数量有限制。但是对网页可以打开的 RTCPeerConnection 的数量也有限制吗？
有点相关：RTCPeerConnection 允许通过 1 个连接发送多个流。在 1 个连接中组合多个流或设置多个连接（例如，每个流 1 个）之间的权衡是什么？
【问题讨论】：
【发布时间】：2016-12-17 01:29:47
【问题描述】：
不确定限制，但我认为大约是 256（我上次听说）。我最近看到有人在一个网页上建立了 200 个连接（通过http://testrtc.com）。
多个 RTCPeerConnection 对象很棒：
- 它们易于添加和移除，因此在加入或退出群组通话时提供更高程度的灵活性
- 它们可以连接到不同的目的地
也就是说，他们有自己的挑战和开销：
每个 RTCPeerConnection 都有自己的 NAT 配置 - 因此 STUN 和 TURN 绑定和流量在 RTCPeerConnection 对象之间并行发生，即使它们连接到同一个实体（例如 SFU）。这种开销是本地资源之一，例如内存和 CPU 以及网络流量（不是很大的开销，但可以处理）
它们在 Chrome 上使用多个选项卡使您的 webrtc-internals 视图变得混乱（根据口味），并且 SSRC 可能在它们之间具有相同的值，这使得它们更难以跟踪和调试（同样，问题味道）
当某人需要添加到列表中（或删除）时，单个 RTCPeerConnection 对象不得不重新协商它。
【讨论】：
-
谢谢，这正是我正在寻找的信息。
-
也在这里阅读 - 我已经深入研究了这个主题 - bloggeek.me/webrtc-rtcpeerconnection-one-per-stream
这是 chrome 错误 list.
但现在还没有解决。
【讨论】：
基于page 14 的webrtc for the curious 电子书，上面写着：
group:BUNDLE Bundling 是一种在一个上运行多种类型的流量的行为 联系。一些 WebRTC 实现使用每个专用连接 媒体流。捆绑应该是首选
所以我想只使用一个RTCPeerConnection 来处理不同类型的流是首选。
如果您认为这个观点是错误的，我很乐意纠正我。
【讨论】：