问题描述
我从WebRTC开始，这在很大程度上是一个设计问题。寻找两种竞争方法的利弊。
上下文
我正在创建将视频流传输到多个客户端的媒体服务器。每个客户端可以请求一个或多个视频流以在浏览器页面中查看，然后关闭它们并请求其他视频流，依此类推。单个客户端一次可能会持续数小时或数天的持续连接，随意切换不同的流。
问题
如何管理与客户端的对等连接？
考虑的方法
- 每个（客户端，视频流）对都有自己的对等连接。因此，如果客户端正在观看5个视频流，则该网页将具有5个对等连接。每个对等连接具有单个轨道。这涉及每次客户端采取措施查看/关闭视频流时创建/销毁对等连接。
- 每个（客户端）都获得一个对等连接。根据客户端操作，我们可以添加跟踪，也可以从对等连接中删除跟踪。只要客户在我们的网页上，单一连接就可以存在。
从表面上看，选项2看起来不那么“浪费”，因为只有一个连接，但是阅读WebRTC信号后，添加/删除曲目的行为会触发新一轮的报价/回答，所以我不确定它实际上更有效。而且，由于它的状态更加丰富（例如，确保在不再使用轨道时对其进行正确清理），因此似乎很难管理和实施。
谢谢。
解决方法
选项2肯定会更有效率，因为它避免了为每个流进行ICE协商。它还可以避免浪费UDP端口，如果服务器非常繁忙，这可能很重要。 （这也限制了NAT框中的状态数量，如今可能不再是问题。）
选项1可能会更有效，因为对每个媒体流使用不同的传输流（不同的UDP端口）意味着流量整形器和AQM将区分不同的流，并可能为您的应用程序提供更多的吞吐量。
也许更重要的是，选项1的实现要简单得多。关于重新协商对等连接时可以执行的操作有复杂的规则，这些规则很容易被破坏，导致难以调试失败。