我正在为希望允许用户(某种Teamspeak)之间进行实时(最小延迟，最大50ms)对话的客户设计一个iOS应用。滞后必须很低，因为音频也可以是现场音乐，可以用乐器演奏，因此所有用户都需要进行同步。我需要一台服务器，该服务器将向每个客户端请求录音并发送给其他客户端(并使它们同时听到相同的声音)。
HTTP易于管理/实现且易于扩展，但性能却很低，因为平均HTTP请求所花费的时间超过50毫秒...(使用中级硬件)，因此我想到了客户端之间保持TCP / UDP连接保持开放的状态和服务器。
但是我有一些问题:
最后:您能建议我哪种压缩方式？我以为Ogg Vorbis会很好，但是如果有什么更好的东西(可以在iOS中使用)，我很乐于接受变化。
谢谢，
乌玛
最佳答案
首先，您不会获得低于50毫秒的延迟。其他人已经尝试过了。例如，查看http://ejamming.com/服务，该服务尝试执行您正在做的事情，但是在线路上在音乐上存在明显的延迟，因此在许多人看来是完全无法使用的。他们使用特殊的路由技术将等待时间降到最低，最后我听说他们的服务不适用于某些路由器配置。
其次，您在服务器上使用哪种语言可能并没有多大区别，因为从客户端到服务器的延迟将比由于您的服务引起的任何延迟都严重，但是如果我正确地理解了您的服务，您将需要很多服务器(或服务器线程)只是在客户端之间中继音频数据或进行某种程度的最小混合。每个连接的工作量很少，但是连接很多，因此您需要可以处理的工作。我倾向于使用Java，Scala或Go。我可能是错的，但是我认为这不是节点的好用例，据我所知，它目前在多线程方面表现不佳。另外，不要随便C++，可扩展的服务已构建为C++。您还可以在C++中构建服务的中继部分，然后在其他任何地方构建。
第三，在选择一种压缩格式时，如果您打算使用UDP，则必须选择一种可以避免丢包的方法，我认为UDP是唯一的解决方法。我认为vorbis不能胜任这项任务，但我可能是错的。从我的头顶上，我不确定在iPhone上能正常使用并且对UDP友好的任何东西，但是我确定有很多东西。 Speex是一个示例，并且是开源的。不确定延迟和质量是否满足您的需求。
最后，直言不讳，我认为您还有其他一些事情需要研究。例如。 DNS通常在本地缓存，并且不会在每个http调用时进行检查(尽管它可能取决于系统/库。至少大多数系统在本地缓存dns)。而且，没有诸如TCP / UDP的协议(protocol)。有TCP / IP(有时称为TCP)和UDP / IP(有时称为UDP)。您似乎将两者称为一体。差异对于您的工作非常重要。例如，HTTP运行在TCP之上，而不是UDP，并且UDP被认为是“不可靠的”，但是开销较小，因此非常适合流传输。
编辑:speex