1

我正在为希望允许用户之间进行实时（最小延迟，最大 50 毫秒）对话（一种 Teamspeak）的客户设计一个 iOS 应用程序。延迟一定要低，因为音频也可以是现场音乐，用乐器演奏，所以所有用户都需要同步。我需要一个服务器，它将向每个客户端请求录音并发送给其他人（并让他们同时听到相同的声音）。HTTP 易于管理/实现且易于扩展，但性能非常低，因为平均 HTTP 请求需要 > 50 毫秒...（使用中级硬件），所以我在考虑 TCP/UDP 连接在客户端之间保持打开状态和服务器。但我有一些问题：

  • 如果我用 Python 开发服务器（例如使用 TwistedMatrix），它的性能如何？
  • 我不能用 C++ 开发服务器，因为它很难管理（可扩展）和开发。
  • 有人使用 Nodejs（易于扩展）来管理 TCP/UDP 连接吗？
  • 如果我使用 HTTP，Keep-Alive 是否足够快？因为通常执行 HTTP 请求所需的时间大于 50 毫秒（因为打开-关闭连接很困难），我希望总过程少于那个时间。
  • 服务器将在 Linux 机器上运行。

最后：你能建议我哪种类型的压缩？我认为 Ogg Vorbis 会很好，但如果有更好的（并且可以在 iOS 中使用），我愿意接受更改。

谢谢你，奥马尔。

4

2 回答 2

2

与服务器有关的是，请求本身并不是瓶颈。我猜你有足够的时间来建立连接，因为它只发生在会话开始时。因此，该协议没有多大意义。

但考虑到 HTTP 是一种无状态协议，不适合音频流。您可以选择几种实时流协议。它们都将通过 TCP 或 UDP 工作（例如使用原始套接字），并且有很多实现。

在您的情况下，延迟的瓶颈不是服务器，而是网络本身。如果 AP 没有配置错误且连接良好，iOS 设备和无线接入点 (AP) 之间的连接会消耗大约 40 毫秒。（ping你的iPhone。）总的来说，路径iOS -> AP -> Server -> AP -> iOS至少需要80毫秒。但是很难保持这种延迟稳定。（我本地网络上 AirPlay 的典型延迟约为 300 毫秒。）

我认为今天通过 iOS 设备进行现场音乐是不可行的。尝试在两台 iOS 设备之间使用 Skype，看看你可以接近 50 毫秒。我敢打赌，没有人能做得更好，这与延迟有关。

更新：新的研究结果！

我必须修改我关于 iDevice wifi 连接延迟的声明。显然，当您第一次 ping 设备时，延迟会很糟糕。但是，如果我在那之后不迟于 200 毫秒再次 ping，我会看到 AP 和 iDevice 之间的平均延迟为 2 毫秒到 3 毫秒。

我的理解是，如果AP和iDevice之间没有通信超过200ms，iDevice的网络适配器会进入一个响应性较差的睡眠模式，可能是为了节省电池电量。

看来，现场音乐再次触手可及...... :-)

更新 2

保持低延迟的活动所需的 ping 间隔显然因设备而异。报告的 200 毫秒适用于第 3 代。平板电脑。对于我的 iPhone 4，它更像是 50 毫秒。

在流式传输音频时，您可能不需要为此烦恼，因为数据交换更加频繁。在我自己的上下文中，iDevice 和服务器之间的通信很少，但低延迟至关重要。因此，保持活力是要走的路。

最好的，彼得

于 2012-09-06T10:28:49.337 回答
2

首先，您不会获得低于 50 毫秒的延迟。其他人已经尝试过这个。例如，请参阅http://ejamming.com/一项服务，该服务试图做您正在做的事情，但线路上有明显的音乐延迟，因此在许多人的耳中，完全无法使用。他们使用特殊的路由技术来尽可能降低延迟，最后我听说他们的服务不适用于某些路由器配置。

其次，您在服务器上使用的语言可能没有太大区别，因为从客户端到服务器的延迟将比您的服务造成的任何延迟更糟糕，但是如果我正确理解您的服务，您将需要很多服务器（或服务器线程）只是在客户端之间中继音频数据或进行某种最小混合。这是每个连接的少量工作，但是很多连接，因此您需要可以处理的东西。我会倾向于 Java、Scala 或 Go 之类的东西。我可能是错的，但我认为这不是 node 的一个很好的用例，据我所知，它目前不能很好地处理多线程。另外，不要对 C++ 嗤之以鼻，C++ 已经构建了可扩展服务。您还可以在 C++ 中构建服务的中继部分，而其余部分则以任何方式构建。

第三，在选择压缩格式时，如果您打算使用 UDP，则必须选择一种可以避免丢包的格式，我认为 UDP 是唯一的方法。我不认为 vorbis 能胜任这项任务，但我可能是错的。在我的脑海中，我不确定在 iPhone 上是否有任何东西可以在 iPhone 上运行并且对 UDP 友好，但我确信有很多东西。Speex 就是一个例子，它是开源的。不确定延迟和质量是否满足您的需求。

最后，坦率地说，我认为还有一些其他的事情你应该多研究一下。例如。DNS 通常在本地缓存，而不是在每次 http 调用时检查（尽管它可能取决于系统/库。至少大多数系统在本地缓存 dns）。此外，没有像 TCP/UDP 这样的协议。有 TCP/IP（有时简称为 TCP）和 UDP/IP（有时简称为 UDP）。您似乎将两者称为一体。差异对于您正在做的事情非常重要。例如，HTTP 运行在 TCP 之上，而不是 UDP，而 UDP 被认为是“不可靠的”，但开销较小，因此它适用于流式传输。

编辑：spex

于 2012-09-07T00:48:11.887 回答