我正在使用带有 MEAN 堆栈的 Socket.IO，它非常适合低延迟和双向通信，但是将它用于相对静态和动态数据的主要缺点是什么？
我的假设是它更适合发送更多动态内容。话虽这么说，一旦建立了套接字连接，所进行的通信量有多大相关性？当用户与应用程序的直接交互过程中不断建立连接时，是否存在使用 http 更合适的情况？
谢谢!
最佳答案
WebSocket 是 HTTP 连接内的双向数据交换。所以问题不在于你使用 HTTP 还是 WebSocket，因为没有 HTTP 就没有 WebSocket。 WebSocket 经常与简单 (BSD) 套接字混淆，但 WebSocket 实际上是 HTTP 连接内的类似套接字的层，该连接位于使用“真实”套接字的 TCP 连接内。或者对于任何熟悉 OSI layers 的人来说:它作为第 4 层(传输)封装在第 7 层(应用程序)内，采用这种奇怪方式而不是直接使用第 4 层的主要原因是，到 HTTP、SMTP 和其他一些协议(protocol)之外的端口的普通套接字是不存在的。由于所有端口都阻止防火墙，因此可能时间更长。
因此，如果您使用简单的 HTTP 或需要使用 WebSocket(在 HTTP 内部)，问题应该更多。
- 使用简单的 HTTP，客户端发送请求，服务器发回响应。该格式定义良好，浏览器和服务器透明地支持压缩、缓存和其他优化。但是这种简单的请求-响应模式是有限的，因为没有办法将数据从服务器推送到客户端，也没有办法拥有更多(BSD)类似套接字的行为，其中客户端和服务器都可以随时发送任何数据。对此有各种或多或少好的解决方法，例如长轮询。
- WebSockets 为您提供了双向通信，这使得服务器可以随时向客户端推送数据或双向发送数据。一旦通过升级现有的 HTTP 连接建立了 WebSocket 连接，数据本身的开销就非常小，比全新的 HTTP 请求要小得多。虽然这听起来不错，但您却失去了简单请求-响应 HTTP 的所有优点，例如在客户端或代理中进行缓存。由于客户端和服务器需要资源来保持底层 TCP 连接打开，因此需要更多资源，这对于繁忙的服务器来说可能是相关的。此外，与简单的 HTTP 相比，WebSocket 可能会给您带来更多中间件(如代理或防火墙)的麻烦。
总之:如果您不需要 WebSocket 的优势，请继续使用简单的请求-响应 HTTP。
关于node.js - 什么时候(如果有的话)通过 Web 套接字使用 http 更合适？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/29061396/