你错了,基于 websocket 的解决方案不限于 5K 并发连接。
根据Facebook 新闻编辑室的数据,他们在 2013 年 9 月平均每天有大约 7.27 亿活跃用户,或者每分钟访问 Facebook 页面的独立用户大约为 50.4 万。给定平均 18 分钟的访问时间(由statisticbrain.com研究),他们的通知基础设施必须能够 24/7 全天候服务于大约 900 万 (18*504k) 个并发 TCP 连接。尽管这个数字是一个非常接近的近似值,但它可以让您大致了解他们正在处理什么以及如果您要构建这样一个系统,您必须处理什么。
您可以使用长轮询以及 websockets 来构建您的实时通知系统。在这两种情况下,您都面临与您的操作系统相关的类似问题(说明适用于基于 Unix 的系统):
- 端口的限制,一个 tcp 侦听器套接字只能在它正在侦听的同一 IP/端口上接受 2^16 个连接,因此您需要侦听多个端口和/或多个 IP 地址。
- 内存,每个打开的连接至少使用一个文件描述符
在现代 Linux 机器可以拥有的打开 TCP 连接的理论最大数量是多少中阅读有关限制的更多信息
长轮询与 Websockets:
长轮询解决方案中的每个轮询都需要一个新的 HTTP 请求,这需要比保持 websocket 连接保持活动所需的带宽更多的带宽。此外,通知作为 HTTP 响应返回,从而导致新的轮询请求。虽然 websocket 解决方案在带宽和系统资源消耗方面可以更高效,但它有一个很大的缺点:缺乏浏览器支持。
根据手头的统计数据,仅 websocket 的解决方案会忽略大约 20-40% 的访问者(来自statscounter.com的统计数据)。出于这个原因,开发了不同的服务器库,将连接的概念从“物理”底层传输模型中抽象出来。因此,更现代的浏览器使用 websockets 创建连接,而旧浏览器则回退到另一种传输方式,例如 HTTP 长轮询、jsonp 轮询或 flash。此类库的突出示例是Sock.js和Socket.io。