silverlight - 最小化丢失数据包对通过 TCP 发送的实时媒体流的影响的最佳方法是什么？

Question

我们已经在 Silverlight 之上实现了一个音频-视频协作应用程序，并正在尝试对其进行调整。我们遇到的问题之一是每当数据包丢失时流延迟都会增加:我们必须等待检测到数据包丢失、请求数据包丢失，然后重新发送丢失的数据包。当然，这会影响我们音频流的一致性。 (如果可以的话，我们会切换到 UDP，但 Silverlight 不支持浏览器内的那个。我们还禁用了 Nagle 算法，所以一般来说，只要我们提交要传输的 byte[] 数组，它被传输，并且在一个数据包中。我知道 TCP 数据包大小!= 提交的数据量，但是禁用 Nagle 算法，它很接近。我们有一个自适应 jitter buffer ，所以我们可以 处理丢失的数据包，但是通过 TCP/IP 丢失的数据包会大大增加我们需要缓冲的音频量，从而增加延迟。)

所以我们正在尝试优化我们发送数据包的方式，看看是否有任何方法可以减少丢弃数据包的影响。我们目前有几个我们正在考虑实现的竞争解决方案:

(1) 我们可以尝试让我们的数据包更大。目前，我们通过同一 TCP 流发送混合的大(~1024 字节视频)数据包和小(~70 字节音频)数据包。但是我们可以将音频和视频数据多路复用在一起，即只要有空间，就将我们的一些视频数据附加到我们的音频数据包中。这会使单个数据包稍微大一些，但会减少数据包的总数。

(2) 我们可以将音频和视频分成两个独立的 TCP 流。这意味着如果视频流因为数据包丢失而停止，音频流不会停止，反之亦然。当然，这会稍微增加开销，并且不会减少发送的数据包总数。

(3) 我们可以将音频反向多路复用到多个单独的 TCP 流中，然后在远端重新组合它们。这将有效地允许我们“伪造”单个 UDP 样式的数据包传递。如果我们有 8 个音频流，其中一个因为丢失数据包而停止，其他流仍然能够按时传送数据，而我们所要做的就是处理 1/8 的音频数据包在停滞的流恢复之前不可用。当然，这并不理想，但与让整个流停止并且在重新传输丢失的数据包之前无法播放任何数据包相比，这可能会带来更好的体验。

对这些可能性有什么想法吗？还有其他建议吗？还是我们只需要编写所有三个代码，然后测试它们？

Answer 1

如果您重新启用 Nagle 算法，您将 (i) 让 TCP 根据路径 MTU 而不是您自己的决定发送最大大小的缓冲区； (ii) 完成您的建议 (1) 搭载音频和视频数据包； (iii) 减少包的总数。使用和不使用 Nagle 算法的饱和 TCP 连接的稳态性能是相同的，因此除了初始窗口填充期间，您不会丢失任何东西。

你还应该运行你能负担得起的最大的套接字发送缓冲区:至少 128k，或者如果可能的话是它的两倍或四倍；并且您还应该使用尽可能大的套接字 receive 缓冲区，尽管在连接套接字之前必须设置大于 64k 的套接字接收缓冲区，以便在 TCP 握手期间可以告知另一端有关窗口缩放的信息.