SPDY 作为 Websockets 的替代品？答案

【问题标题】：SPDY as replacement for Websockets?SPDY 作为 Websockets 的替代品？
【发布时间】：2012-08-19 16:15:11
【问题描述】：

首先 - 我知道 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 所做的那样。

【问题讨论】：

标签： websocket spdy

【解决方案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 请求的开销和成本（获胜）
SSE 是将数据推送到客户端（现在可以通过 SPDY 运行）的一种很好的简单替代方案

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

【讨论】：

啊，谢谢你的回答——我知道我完全错过了服务器发送事件的消息。这听起来正是我一直在寻找的，并将尝试一下。
这里有一些有用的信息：html5rocks.com/en/tutorials/eventsource/basics
澄清一下，WebSockets (IETF 6455) 不能通过 HTTP 运行，它们只是具有与 HTTP 兼容的初始握手。 WebSocket over SPDY 提案使用 WebSocket 的语义和头字段，但将其转换为 SPDY 字段。
虽然 WebSocket 和 SSE 连接都以 HTTP 请求开始，但您看到的性能优势和它们的能力可能大不相同。例如，SSE 无法将流数据从客户端向上游发送到服务器，并且仅支持文本数据。
SPDY 通过压缩 HTTP 标头和多路复用等操作来增强 HTTP 以提高 HTTP 请求的性能。它的主要目的是提高网页的性能。

【解决方案2】：

首先澄清一下：

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

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

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

【讨论】：

谢谢，基本上我的问题的根源是 SPDY 是否提供了一些内在的双向支持或优于基于 HTTP 的推送方法。进一步阅读后，一个有用的解释是 SPDY 推送由浏览器解释，而 websocket 数据由在浏览器中运行的应用程序解释。 groups.google.com/forum/?fromgroups=#!topic/spdy-dev/…

【解决方案3】：

但是，我对 websockets 的问题是我必须自己构思用于将请求路由到服务器和从服务器发送的 JSON 协议。

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

【讨论】：