使用 Websocket 进行聊天应用答案

【问题标题】：Using Websocket for chatting application使用 Websocket 进行聊天应用
【发布时间】：2021-10-24 17:10:31
【问题描述】：

对于制作聊天应用程序，标准建议似乎是使用 Websocket 从服务器接收实时数据，而且似乎大多数人都是这样做的。但我不明白的是为什么生产聊天应用程序通过标准 AJAX 请求向服务器发送消息，而不是使用 WS。

Discord 和 Slack 的浏览器应用程序，尽管它们保持 WS 连接，但应用程序在发送聊天消息时只是将 POST 发送到其端点之一。

不是生产聊天应用，但 ApolloClient 的 useSubscription 使用 WS 从服务器接收事件，但变异（这是我们用来发送消息的）作为标准 AJAX 发送。

对于聊天应用程序，如果我们有一个与服务器的专用 WS 连接，使用它来发送任何数据不是更快/更有效吗？我认为通过标准 AJAX 发送数据（聊天应用程序的聊天消息）是有正当理由的，但是 SSE 不是比 WS 更好/更少资源密集型的选择吗？

【问题讨论】：

但是这个问题对于 Stack Overflow 的问答形式来说过于宽泛——我们不可能回答这个问题，因为您在没有了解这些供应商的软件设计过程的情况下提出了这个问题——即使这样，这个信息可能被列为商业机密或 NDA，任何具有任何相关知识的人都不能在此披露。投票结束
但 EvenSource 得到 97% 的支持...此外，Discord 使用 WS 用于 Server->Client，但 AJAX 用于从 Client->Server 发送文本消息，因此没有 WS 的浏览器支持，不能polyfill 不能用Discord，不是吗？
您是否删除了您的第一条评论，因为您意识到它是多么离题？你能取消标记我的帖子吗？我真的认为这是一个不违反任何社区准则的合法问题

【解决方案1】：

与 WS 相比，SSE 不是更好/更少的资源密集型选择吗？

服务器发送事件和 Web Sockets 都有一个非常相似的实现：它们在客户端和服务器之间打开一个专用套接字。因此，首先回答您的最后一个问题：它们对关键资源（套接字和该进程的服务器内存）的使用相同。

为什么发送数据（聊天应用程序的聊天消息）是通过标准 AJAX 完成的

AJAX打开socket（*），发送数据，服务器进程处理（推送到另一个服务器或写入数据库），然后可以关闭socket，服务器有能力处理下一个传入请求。

*：使用 HTTP/2 多路复用，大多数时间可能已经有一个套接字就绪。

可以处理 1000 个 AJAX 推送客户端的单个服务器在任何时候可能只能处理 50-100 个 SSE 或 Web 套接字连接。该比率取决于聊天消息的性质和可接受的延迟。

在一个极端情况下，如果您希望在每次按键发生时发布每个按键，并让每个人都收到该字符，并且大多数人大部分时间都在打字，那么 AJAX 方法也可能只能处理 50-100 个客户端一次。

在另一个极端，如果聊天是完整的句子，直到用户按 Enter 才发送出去，并且每个客户端每隔几分钟才写一次评论，那么单个服务器可能能够处理 10,000 条此类客户。

尽管它们维护 WS 连接，但应用程序在发送聊天消息时只是将 POST 发送到其端点之一。

这有点奇怪，不是吗：在理想世界中，您会重复使用该连接。我认为这将归结为实际的工程问题。不同部门处理不同的服务器，具有不同的可扩展性和延迟要求，以及可能不同的安全和备份策略。

换句话说，如果接收消息、将它们推送到数据库、轮询新消息并将它们发送出去，所有这些都由保持打开该专用套接字的单个进程处理，那么所有代码都需要放在一个大型、沉重、难以维护的软件。听起来还是挺简单的，10行代码？但当它们为企业做好准备时，包括身份验证、计费、遗留支持、垃圾邮件检测等，它们已经有数千行了。

另一件需要考虑的事情是，专用套接字很难通过代理和移动设备维护。您需要运行 ajax 版本才能为这些客户端提供可靠的服务。所以如果你无论如何都必须这样做，你还不如为每个人使用它，而不必编写两次代码。

【讨论】：