HTTP TCP 和 Web 套接字

Question

如有错误请指正。 在 Web 应用程序中使用 HTTP 协议的优势之一是最大限度地减少客户端之间的服务器资源共享。即使有数千个并发连接，由于 HTTP 的这种无状态特性，服务器上的负载也会大大降低。

另一方面，如果连接是有状态的（例如 TCP），则服务器需要打开并保持连接以应对数千个请求，从而给服务器带来巨大负载。因此，为什么 HTTP 为在 Web 应用程序中工作而变得无状态是完全合理的。

我对 web socket 感到困惑，如果 web socket 使用 TCP 在客户端和服务器之间进行实时通信，那么对于任何基于 web 的实时通信来说，这怎么可能是一个好的选择（考虑到服务器上的负载）应用？ Web 套接字服务器如何处理多个连接的负载？

Answer 1

HTTP 基于 TCP。

仅仅保持连接打开并不一定需要大量资源。但是，它确实通常需要不同的 threading/IO 模型来处理这些连接。例如，这推动了 java 中针对异步和非阻塞 io 的大部分 nio 更改。

Answer 2

HTTP 操作不一定是轻量级的或短暂的；有许多 Web 应用程序在处理表面上无状态的请求时会消耗大量资源。 Web 套接字实际上可以 比 HTTP 性能更高 ，具体取决于场景 - 新的 HTTP 连接和服务器端响应的隔离处理，可能比长期套接字连接昂贵得多客户端到服务器进程，该进程能够在没有新连接和数据编组开销的情况下传输数据。它实际上取决于数据的类型 - 规范的 websockets 示例是实时聊天，其中查看新聊天消息的完整 Web 请求的开销（或延迟）比可以多路复用的 pub-sub 类型的过程要重得多向大量现有 websocket 发送新消息。

WebSockets 或 "Restful" HTTP 哪个性能更高或效率更高的问题在很大程度上取决于场景。