Question

首先 - 我理解SPDY和Websockets不是一回事，你可以通过SPDY运行Websockets，就像使用HTTP等一样。

然而 - 我想知道如果我试图提供一个支持服务器推送的REST（类似）API（通过同一连接进行双向调用），SPDY是否可以替代websockets。

我当前的原型使用websockets（node + socket.io），并且工作正常。但是，我对websockets的问题是我不得不想出我自己的JSON协议来路由来往服务器的请求。我更倾向于在请求中使用REST样式的URI和Headers，这更适合基于REST的架构。 SPDY似乎会更好地支持这一点。

另外，由于缺少标题，我担心websockets不适合我们的部署网络，并且认为SPDY会更适合。

但是，除了将文件推送到浏览器之外，我还没有看到很多双向SPDY请求的例子。我想将事件和数据推送到浏览器，例如：

Content-Type: application/json
{
   "id": "ca823f3e233233",
   "name": "Greg Brady"
}

但我不清楚浏览器/ Javascript如何“监听”并对这些内容作出反应，就像我使用WebSocket和socket.io API一样。

Answer 1

让我们从头开始：为什么要通过SPDY运行WebSockets，而不是进行HTTP升级？如果将HTTP连接升级到WS，则没有其他任何东西可以使用该TCP流 - WS连接可以处于空闲状态，但仍然会阻止连接。使用SPDY，您可以在同一底层TCP流上复用多个请求/响应和一个websocket连接（甚至多个）。从实际角度来看，截至2012年7月，WS over SPDY仍在进行中，因此您必须等待SPDY用于WebSockets - 希望不会太长！

但是让我们假设支持就在那里......之所以不清楚如何从JavaScript中搜索“SPDY Push”是因为没有办法做到这一点！推送的资源会进入您的浏览器缓存 - 仅此而已。如果您需要将数据流式传输到您的javascript回调，那么WebSockets或服务器发送事件（SSE）就是答案。

所以，把它们放在一起：

HTTP为个别小请求（标题等）增加了大量开销
WebSockets为您提供低开销通道，但需要您实现自己的路由
SPDY将显着降低小型HTTP请求（win）的开销和成本
SSE是一种很好的，简单的替代方法，可以将数据推送到客户端（今天可以通过SPDY工作）

您可以使用SPDY + SSE来实现目标，并且所有通信都可以在同一TCP通道上运行。 SPDY请求服务器，从服务器推送SSE。

Answer 2

首先澄清一下：

基本WebSocket协议（IETF 6455）不是分层onto HTTP。 WebSocket连接的初始握手是HTTP兼容的，但是一旦握手完成，协议就是一个成帧的双向全双工连接，开销非常低（每帧只有2个字节）。
< / LI>
WebSocket over SPDY的想法是proposal，它可能会或可能看不到白昼。在这种情况下，WebSocket实际上是在SPDY上分层。由于SPDY与HTTP的性质，初始连接/握手可能会更快发生，但是，由于WebSocket头字段被映射到SPDY头字段，因此数据帧将具有更多开销。

SPDY旨在成为HTTP的更有效替代品。 WebSocket是一种完全不同的野兽，它可以在客户端和服务器之间实现极低延迟的双向/全双工消息传递。

如果您对使用简单API的服务器推送感兴趣并且您不需要超低延迟，那么您可能会考虑服务器发送的事件，其具有简单且类似于WebSocket API的API。或者您可以查看许多优秀的Comet库中的一个，这些库可以实现服务器推送，但是与上述任何解决方案不同，它将更好地支持旧浏览器。

Answer 3

然而，我对websockets的问题是我不得不梦想自己用于在服务器之间路由请求的JSON协议。

我在socket.io上写了一个瘦的RPC层，因为这个原因包含promises中的网络调用。你可以看一眼here。

SPDY作为Websockets的替代品？

3 个答案: