使用Socket.IO的emit（）而不是所有的HTTP请求是一个好习惯吗？
我build立了一个Node.js HTTP服务器。 它侦听path“/”，并在获取请求上返回一个空的HTML模板。
该模板包含Require.js客户端脚本，该脚本创build与服务器的Socket.IO连接。
然后，客户端和服务器之间的所有通信都由Web Sockets提供。
连接时，服务器需要authentication; 如果存在authenticationcookie，则客户端将其发送到服务器进行validation，如果没有cookie，则客户端呈现login视图并等待用户input等。
到目前为止，一切正常，validation凭据后，我为用户创build一个SID，并使用它来pipe理他的访问权限。 然后我渲染主视图和应用程序启动。
问题：
-
是否需要使用HTTPS而不是HTTP，因为我只使用HTTP将脚本发送到客户端？ （注：我打算使用本地存储而不是Cookie）
-
在没有HTTP的情况下使用纯Web套接字是否有什么问题？
-
如果有效，为什么没有人使用它？
是否需要使用HTTPS而不是HTTP，因为我只使用HTTP将脚本发送到客户端？ （注：我打算使用本地存储而不是Cookie）
不，HTTP / HTTPS是websocket握手所必需的。 从安全angular度出发，selectHTTP或HTTPS。 如果你想用它来简单地发送脚本，那么没有任何伤害。 如果你想在你的页面中实现用户login/authentication，那么应该使用HTTPS。
在没有HTTP的情况下使用纯Web套接字是否有什么问题？
Web套接字和HTTP是非常不同的。 如果你使用纯Web Socket，你会错过HTTP。 HTTP是跨平台Web服务的首选。 对于文件遍历/检索是有好处的，但它是一种方法。 Web套接字通过单个TCP连接提供全双工通信通道，并允许我们摆脱Ajax，Reverse Ajax，Comet等变通方法和窍门。需要注意的是，两者都可以共存。 所以瞄准networking套接字而不会遗漏HTTP。
如果有效，为什么没有人使用它？
我们生活在HTTP时代，networking套接字是比较新的。 从长远来看，networking套接字将会越来越受欢迎，占据更大的networking服务份额。 直到最近许多浏览器都没有正确支持Web套接字。 看到这里 ，IE 10是IE中支持web套接字的最新和唯一的版本。 nginx，一个非常受欢迎的服务器，直到2013年2月 – 3月才会支持web套接字。networking套接字将需要一段时间才能成为主stream，但它将会。
你的问题和这个很相似
为什么在WebSockets可用时使用AJAX？
在一天结束时，他们都被创build了不同的东西，尽pipe你可以使用web套接字来处理大部分的事情，如果不是在普通的HTTP请求中可以完成的话。
我build议使用HTTPS，因为你似乎通过websockets发送authentication数据（它也将使用SSL，不是吗？），但是这取决于你需要的定义。
垮台 – 缺乏对旧版浏览器的支持
这在其他许多情况下并没有使用，因为这不是必要的，而且还是“相对较新的”。