使用Socket.IO的emit()代替所有HTTP请求是一个好习惯吗？

Question

我设置了一个 Node.js HTTP 服务器。它监听路径“/”并在 get 请求上返回一个空的 HTML 模板。

该模板包含 Require.js 客户端脚本，该脚本创建与服务器的 Socket.IO 连接。

那么客户端和服务器之间的所有通信都是由 Web Sockets 提供的。

连接时，服务器需要身份验证；如果有身份验证 cookie，则客户端将它们发送到服务器进行验证，如果没有 cookie，则客户端呈现登录视图并等待用户输入等。

到目前为止，一切正常，在验证凭据后，我为用户创建一个 SID 并使用它来管理他的访问权限。然后我渲染主视图并启动应用程序。

问题：

• 由于我只使用 HTTP 向客户端发送脚本，是否需要使用 HTTPS 而不是 HTTP？（注意：我打算使用本地存储而不是cookie）

• 使用没有 HTTP 的纯 Web 套接字有什么缺点吗？

• 如果它有效，为什么没有人使用它？

Answer 1

由于我只使用 HTTP 向客户端发送脚本，是否需要使用 HTTPS 而不是 HTTP？（注意：我打算使用本地存储而不是cookie）

不，Websocket 握手需要 HTTP/HTTPS。选择 HTTP 或 HTTPS 是从安全角度出发。如果您想使用它来简单地发送脚本，那么没有什么坏处。如果您想在页面中实现用户登录/身份验证，则应使用 HTTPS。

使用没有 HTTP 的纯 Web 套接字有什么缺点吗？

Web 套接字和 HTTP 有很大不同。如果您使用纯 Web 套接字，您将错过 HTTP。HTTP 是跨平台 Web 服务的首选。它对于文档遍历/检索很有用，但它只是一种方式。Web 套接字通过单个 TCP 连接提供全双工通信通道，使我们能够摆脱 Ajax、反向 Ajax、Comet 等变通方法和黑客攻击。需要注意的重要一点是，两者可以共存。因此，以 Web 套接字为目标，同时不要忽略 HTTP。

如果它有效，为什么没有人使用它？

我们生活在 HTTP 时代，Web 套接字相对较新。从长远来看，Web 套接字将越来越受欢迎，并在 Web 服务中占据更大的份额。直到最近，许多浏览器都无法正确支持 Web 套接字。请看这里，IE 10 是 IE 中最新且唯一支持 Web 套接字的版本。nginx 是一款广受欢迎的服务器，直到 2013 年 2 月至 3 月才支持 Web 套接字。Web 套接字成为主流还需要一段时间，但它会的。