用户期望实时交互——而不是页面刷新。
WebSocket 支持 Web 浏览器和服务器之间的实时双向通信。与客户端请求和服务器响应（单向）的传统 HTTP 请求不同，WebSocket 保持持久连接打开，允许任何一方随时发送数据。这可以实现实时聊天、实时通知、协作编辑、实时体育赛事比分和金融数据流。根据 Ably 2025 年的一项调查，80% 的用户期望 Web 应用程序具有实时功能。
在 x13apps，我们为客户实现从实时客户支持到协作仪表板等实时功能。以下是 WebSocket 的工作原理以及何时使用它们。
WebSocket 与 HTTP 有何不同
使用 HTTP，客户端发送请求，服务器返回响应。响应后连接关闭。为了获取更新，客户端必须重复轮询服务器（每隔几秒询问一次）——效率低且速度慢。 WebSocket 在初始 HTTP 升级握手后建立持久的 TCP 连接。客户端和服务器都可以通过这个开放的通道异步发送消息。
其优点是显着的：WebSocket 将延迟从轮询间隔（2-30 秒）减少到毫秒，消除了重复 HTTP 标头和连接设置的开销，并启用了标准 HTTP 无法实现的服务器推送功能。代价是基础设施更加复杂——WebSocket 连接必须以与 HTTP 连接不同的方式进行维护、负载平衡和扩展。
常见的实时用例
实时聊天和客户支持——代理和客户无需刷新即可交换消息。实时通知——新消息、订单或系统事件的警报。协作编辑——编辑同一文档的多个用户可以立即看到彼此的更改（Google 文档风格）。实时仪表板——指标和图表随着数据到达而更新。直播——直播视频期间的实时评论和反应。游戏——多人游戏状态同步。
每个用例对消息量、延迟和可靠性都有不同的要求。发送短信的实时聊天系统的要求低于每秒数百次流式传输价格更新的金融交易平台。根据您的具体要求选择实时架构，而不是采用一刀切的方法。
实施方案
本机 WebSocket 非常适合简单的实现，但需要仔细处理重新连接、扩展和回退。 Socket.io 是一个流行的库，它添加了自动重新连接、房间支持和针对 WebSocket 被阻止的环境的回退传输等功能。为了实现大规模实时，Pusher、Ably 或 PubNub 等托管服务可以处理基础设施的复杂性，提供有保证的交付和全球分发。
扩展考虑因素
WebSocket 连接是有状态的——每个连接都绑定到一个特定的服务器实例。与无状态 HTTP 相比，这使水平扩展变得复杂。使用粘性负载均衡器或外部发布/订阅层（Redis Pub/Sub、RabbitMQ）在服务器实例之间广播消息。云提供商提供托管 WebSocket 服务：AWS API Gateway WebSockets、Google Cloud Run 和 Azure Web PubSub 自动处理扩展。在 x13apps，我们设计了实时架构，可以在保持低延迟的同时高效扩展。有关网络开发的更多信息，请阅读我们的渐进式应用指南。