什么时候使用http over web套接字更合适?

我使用的是带有MEAN堆栈的Socket.IO,它对于低延迟和双向通信非常好,但是如何将它用于相对静态的数据以及dynamic性呢?

我的假设是,发送更多dynamic内容会更加方便。 这就是说,一旦套接字连接build立起来,通信的数量有多相关呢? 在用户与应用程序直接交互的过程中,当连接不断build立时,是否有一段时间更适合使用http?

谢谢!

WebSockets是HTTP连接中的双向数据交换。 所以问题不是如果你使用HTTP或WebSockets,因为没有HTTP没有WebSockets。 WebSocket通常与简单的(BSD)套接字混淆,但是WebSockets实际上是一个HTTP连接内部的一个类似于套接字的层,它在使用“真实”套接字的TCP连接中。 或者对于任何熟悉OSI层的人来说 :它是作为第7层(应用程序)内部封装的第4层(传输),而不是直接使用第4层这种奇怪的方式的主要原因是简单的套接字到HTTP,SMTP而且由于所有端口阻塞防火墙,其他一些协议不再可能。

所以如果你使用简单的HTTP或者如果你需要使用WebSockets(在HTTP中),问题应该更多。

  • 使用简单的HTTP,客户端发送一个请求,服务器将响应发送回去。 格式定义良好,浏览器和服务器透明地支持压缩,caching和其他优化。 但是这个简单的请求 – 响应模式是有限的,因为没有办法将数据从服务器推送到客户端,或者在客户端和服务器都可以随时发送任何数据的情况下有更多的(BSD)套接字。 有很多或多或less的很好的解决方法,如长轮询。
  • WebSockets为您提供双向通信,使服务器可以随时将数据推送到客户端或双向发送数据。 一旦通过升级现有的HTTP连接来build立WebSocket连接,数据本身的开销就非常小,然后用全新的HTTP请求就小得多了。 虽然这听起来很不错,但是您可以放宽在客户端或代理服务器上caching的所有简单请求响应HTTP的优点。 由于客户端和服务器需要资源来保持底层TCP连接的打开,所以需要更多的资源,这对于繁忙的服务器来说可能是相关的。 另外,WebSockets可能会给中间件(如代理或防火墙)带来更多的麻烦,然后简单的HTTP就会出现。

总之:如果您不需要WebSockets的简单请求 – 响应HTTP保持优势。