25

首先 - 我知道 SPDY 和 Websockets 不是一回事，你可以像使用 HTTP 等一样在 SPDY 上运行 Websockets。

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

我当前的原型使用 websockets (node+socket.io)，并且工作正常。但是，我对 websockets 的问题是我必须想出自己的 JSON 协议来路由进出服务器的请求。我更愿意在请求中使用 REST 样式的 URI 和标头，这更适合基于 REST 的架构。SPDY 似乎会更好地支持这一点。

另外，由于缺少标头，我担心 websocket 不能很好地适应我们的部署网络，并且认为 SPDY 会再次更适合。

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

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

但我不清楚浏览器/Javascript 会如何“监听”这些内容并对它们做出反应，就像我对 WebSocket 和 socket.io API 所做的那样。

4

3 回答 3

37

让我们从头开始：为什么要在 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 请求的开销和成本（赢）
  • SSE 是将数据推送到客户端的一个很好、简单的替代方案（现在可以通过 SPDY 工作）

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

于 2012-08-24T06:08:19.177 回答
6

首先澄清一下：

  • 基本 WebSocket 协议 (IETF 6455) 不是分层ontoHTTP。WebSocket 连接的初始握手是 HTTP 兼容的，但是一旦握手完成，该协议就是一个帧的双向全双工连接，开销非常低（通常每帧标头只有 2 个字节）。

  • 基于 SPDY 的 WebSocket 想法是一个可能会或可能不会看到曙光的提议。在这种情况下，WebSocket 实际上是在 SPDY 上分层的。由于 SPDY 与 HTTP 相比，初始连接/握手可能发生得更快，但是，由于 WebSocket 标头字段映射到 SPDY 标头字段，因此数据帧将具有更多开销。

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

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

于 2012-08-24T14:41:36.343 回答
0

但是，我对 websockets 的问题是我必须想出自己的 JSON 协议来路由进出服务器的请求。

出于这个原因，我在 socket.io 上编写了一个瘦 RPC 层，将网络调用包装在 Promise 中。你可以看看这里。

于 2013-10-16T14:48:31.760 回答