我正在寻找一种解决方案，将事件从我的服务器推送到客户端，即Android，iOS和桌面（网络）用户。
我在Parse，Amazon SNS和Google Cloud Messaging上看过不少帖子，但是他们没有提到它们的速度和最常见的应用程序，或者与简单的TCP流或websockets进行比较？
我需要最多 50 事件/第二 bi-directona l每个客户的吞吐量（每个事件1英镑），最大值 150ms延迟。
仅使用 TCP流事件与 websockets 与 SNS / Parse / GCM 相比有什么缺点？
答案 0 :(得分：6)
推送通知（GCM和APN）
PROS：即使客户端应用程序未运行，您也可以访问该设备。
缺点：吞吐量低;高延迟
原始TCP
PROS：高吞吐量;低延迟;双向
缺点：没有通过典型的代理和防火墙;需要客户端应用程序运行
<强>的WebSockets
PROS：高吞吐量;低延迟;双向的;通过防火墙
缺点：并非所有代理都支持它们;需要客户端应用程序运行
此外，还有 HTTP Streaming 和 HTTP Long Polling 。
答案 1 :(得分：3)
你可以尝试使用SignalR。
ASP.NET SignalR是一个面向ASP.NET开发人员的新库，它使向应用程序添加实时Web功能变得异常简单
我的一位同事已将此库用于web，window，android，mac等实时消息传递。
答案 2 :(得分：2)
在这里你可以找到一些基准：http://blog.arungupta.me/rest-vs-websocket-comparison-benchmarks/
这个更具技术性的问题也可能对您或其他人有所帮助：What is the fundamental difference between WebSockets and pure TCP?
从接受的答案中引用：
当您在Intranet边界内工作时，通过TCP套接字进行通信更容易，因为您可能可以控制该网络上的计算机并可以打开适合建立TCP连接的端口。
通过互联网，您可以与另一端的其他人的服务器进行通信。他们极不可能有任何旧的套接字打开连接。通常它们只有几个标准的端口，例如HTTP端口80或HTTPS端口443。因此，要与服务器通信，您必须使用其中一个端口进行连接。