我正在为想要允许用户之间的实时（最小延迟，最长50毫秒）对话的客户设计一个iOS应用程序（一种Teamspeak）。滞后必须很低，因为音频也可以是现场音乐，用乐器演奏，所以所有用户都需要同步。我需要一台服务器，它会向每个客户端请求录音并发送给其他人（并让他们同时听到相同的声音）。 HTTP易于管理/实现且易于扩展，但是性能非常低，因为平均HTTP请求需要＆gt; 50ms ......（带有中级硬件），所以我在想客户端和服务器之间保持打开的TCP / UDP连接。 但我有一些问题：
最后：你能建议我使用哪种压缩方式？我认为Ogg Vorbis会很好，但如果有更好的东西（并且可以在iOS中使用），我愿意接受改变。
谢谢你， 欧麦尔。
答案 0 :(得分：2)
服务器有什么问题，请求本身不是瓶颈。我猜你有足够的时间来建立连接，因为它只在会话开始时发生。因此，该协议没有多大意义。
但请注意，HTTP是无状态协议，不适合音频流。您可以选择几种实时流媒体协议。所有这些都可以通过TCP或UDP工作（例如使用原始套接字），并且有很多实现。
在您的情况下，延迟的瓶颈不是服务器而是网络本身。如果AP配置错误且连接良好，则iOS设备和无线接入点（AP）之间的连接会耗尽大约40毫秒。 （ping你的iPhone。）总的来说，iOS路径至少需要80毫秒 - ＆gt; AP - ＆gt;服务器 - ＆gt; AP - ＆gt; iOS版。但是很难保持这种延迟稳定。 （我本地网络上AirPlay的典型延迟时间约为300毫秒。）
我认为iOS设备上的现场音乐今天并不实用。尝试两个iOS设备之间的Skype，看看你有多接近50毫秒。我敢打赌，没有人可以做得更好，这与延迟有关。
更新：新的研究结果！
我必须修改关于iDevice的wifi连接延迟的声明。显然，当您第一次ping您的设备时，延迟会很糟糕。但是如果我在不迟于200ms之后再次ping通，我会看到AP和iDevice之间的平均延迟为2ms-3ms。
我的解释是，如果AP和iDevice之间没有通信超过200毫秒，iDevice的网络适配器将进入反应较慢的睡眠模式，可能是为了节省电池电量。
看来，现场音乐再次触手可及......： - ）
更新2
保持低延迟所需的ping间隔显然因设备而异。报道的200毫秒是第三代。 iPad兼容。对于我的iPhone 4，它更像是50ms。
在播放音频时，您可能不需要为此烦恼，因为数据会更频繁地进行交换。在我自己的上下文中，我在iDevice和服务器之间进行稀疏通信，但低延迟是至关重要的。因此，保持活力是可行的方法。
最好，彼得
答案 1 :(得分：2)
首先，你不会得到低于50毫秒的延迟。其他人试过这个。例如，参见http://ejamming.com/一项服务，它试图做你正在做的事情，但在线路上有一个音乐上明显的延迟，因此，在许多人的耳中，完全无法使用。他们使用特殊的路由技术来尽可能降低延迟，最后我听说他们的服务不适用于某些路由器配置。
其次，您在服务器上使用的语言可能没有多大区别，因为从客户端到服务器的延迟将比您的服务造成的任何延迟更糟糕，但如果我理解您的服务正确，您将需要许多服务器（或服务器线程）只是在客户端之间中继音频数据或进行某种最小程度的混合。这是每个连接的少量工作，但是很多连接，所以你需要能够处理它的东西。我倾向于像Java，Scala或者Go这样的东西。我可能是错的，但我认为这不是一个很好的节点用例，据我所知，它目前还不能很好地进行多线程处理。另外，不要poo-poo C ++，可扩展服务已经构建了C ++。您还可以使用C ++构建服务的中继部分，其余部分也可以构建。
第三，在选择压缩格式时，如果您计划使用UDP，则必须选择能够在丢包中幸存的格式，并且我认为UDP是唯一可行的方法。我不认为vorbis能胜任这项任务，但我可能错了。在我的头脑中，我不确定在iPhone上有什么作用并且是UDP友好的，但我确信有很多东西。 Speex就是一个例子，是开源的。不确定延迟和质量是否符合您的需求。
最后，说实话，我认为还有其他一些你应该研究的东西。例如。 DNS通常在本地缓存，而不是每次http调用都检查（尽管它可能取决于系统/库。至少大多数系统在本地缓存dns）。此外，没有TCP / UDP这样的协议。有TCP / IP（有时称为TCP）和UDP / IP（有时称为UDP）。你似乎把它们称为两者。差异对于你正在做的事情非常重要。例如，HTTP运行在TCP之上，而不是UDP，UDP被认为是“不可靠的”，但开销较少，因此对流式传输有利。
编辑：speex