生产级聊天应用用Websocket收消息为何选AJAX而非WS发送？

• 成熟的HTTP生态可以大幅降低开发维护成本
  发消息属于需要明确知道执行结果的操作，HTTP本身已经内置了状态码、超时、重试、幂等校验的完整机制，AJAX请求的成功、失败回调都是标准化的，你不需要额外做任何定制就能直接判断消息是否发送成功、失败原因是什么。而WebSocket是裸的双向数据流，如果要通过WS实现请求-响应模式，你需要自己定义request_id做请求匹配、自己实现超时检测、自己定义错误码规范，额外开发量非常大。
  比如Apollo Client的useSubscription仅用WS做被动事件接收，而mutation走AJAX，就是因为mutation需要明确的执行结果反馈，复用成熟的HTTP GraphQL工具链比在WS上重新封装一套响应协议成本低得多。
• 服务架构扩展性更强
  WebSocket是长连接，一旦建立就会绑定到固定的后端推送节点上，如果所有发消息的请求都走WS，流量会全部压到绑定的推送节点上，无法灵活调度。而AJAX请求可以被负载均衡器直接路由到负载最低的写服务集群，不需要经过推送节点，刚好匹配聊天应用「读写分离」的通用架构设计，对大流量场景的友好度高很多。Discord、Slack这类产品的推送服务和消息写入服务都是完全拆分的，发消息走AJAX可以直接绕开推送集群，减少中间链路的性能损耗。
• 连接可靠性更高
  WS长连接在弱网、切换网络的场景下很容易断连，断连重连的间隙发送WS消息会直接丢失，需要自己实现消息缓存、去重、重发逻辑。而AJAX请求的生命周期和WS连接状态完全解耦，只要网络正常就能发送，上层请求库的失败重试、离线缓存机制也非常成熟，不需要和WS的连接状态绑定，可靠性更高。

SSE确实是轻量的服务端推送方案，但对聊天场景来说缺陷很明显：

• SSE是单工协议，仅支持服务端向客户端推送数据，类似用户输入状态上报、心跳检测这类需要客户端向服务端发送的轻量请求，还是要单独走HTTP，综合连接开销不一定比WS低
• 浏览器对同一域名的SSE连接有最大6个的限制，用户多开几个标签页就会出现连接失败的问题
• SSE默认仅支持文本传输，二进制内容需要额外编码，传输聊天场景下的表情、语音、缩略图等内容的性能不如原生支持二进制的WS

内容的提问来源于stack exchange，提问作者Seaside9