SPDY 与通过保持活动连接的 http 多路复用有什么不同吗答案

【问题标题】：Is SPDY any different than http multiplexing over keep alive connectionsSPDY 与通过保持活动连接的 http 多路复用有什么不同吗
【发布时间】：2012-05-08 21:11:20
【问题描述】：

HTTP 1.1 支持保持活动连接，连接不会关闭，直到发送“Connection: close”。

那么，如果浏览器，在这种情况下firefox启用了network.http.pipelining，并且network.http.pipelining.maxrequests增加了，到底效果不一样吗？

我知道这些设置已禁用，因为对于某些网站，这可能会增加负载，但我认为一个简单的 http 标头标志可以告诉浏览器可以使用多路复用，并且可以更轻松地解决此问题。

在浏览器中更改默认设置不是比发明一种增加复杂性的新协议更容易吗？尤其是在 http 服务器中？

【问题讨论】：

SPDY 对请求和响应标头使用状态压缩。
这是否有很大的不同（尤其是对于您在 SSL 中已有的正常压缩）？
http 也可以使用 gzip 压缩，几乎所有浏览器都支持它，而且标头通常太小而无所谓
HTTP 无法压缩标头。大标题通常用于传递大量大 cookie。有充分的理由对 HTTP 标头大小没有限制。我已经看到了一些奇怪的使用持久性的东西，它们会在标头中发送数百个 KB。

标签： http firefox keep-alive spdy

【解决方案1】：

见Difference between HTTP pipeling and HTTP multiplexing with SPDY

【讨论】：

【解决方案2】：

SPDY 具有许多超出 HTTP 流水线所能提供的优势，这些优势在 SPDY whitepaper 中进行了描述：

使用流水线，服务器仍然必须按照请求的顺序一次返回一个响应。如果客户端在静态资源之前请求动态生成的资源，这可能是一个问题：在生成并发送动态生成的资源之前，服务器无法发送任何“简单”静态响应。使用 SPDY，响应可以在生成时无序或并行返回，从而缩短接收所有资源的总时间。
正如您在问题中指出的那样，并非所有服务器都能够处理流水线：不仅仅是负载，当客户端请求流水线时，某些服务器实际上表现不正确。使用标头表示可以进行流水线操作为时已晚，无法获得最大收益：此时您已经收到第一个响应，因此虽然您可以在未来的连接中使用它，但对于这个来说已经太晚了。李>
SPDY 使用特定于该任务的算法压缩标头（有状态并了解 HTTP 标头中的正常内容）；虽然是的，SSL 已经包含压缩，只是用 deflate 压缩它们效率不高。大多数 HTTP 请求没有正文，只有一个简短的 GET 行，因此标头几乎构成了整个请求：您可以获得的任何压缩都是一种改进。与标题相比，许多响应也很小。
SPDY 允许服务器在没有客户端请求的情况下发回额外的响应。例如，在客户端有机会接收和解析 HTML 以确定样式表 URL 之前，服务器可能会开始将页面的 CSS 与原始 HTML 一起发回。通过消除客户端在请求呈现页面所需的其他资源之前实际解析 HTML 的需要，这可以进一步加快页面加载速度。它还支持此功能的带宽较少的版本，它可以“提示”可能需要哪些资源，并允许客户端决定：例如，这允许不关心图像的客户端不打扰请求它们，但想要显示图像的客户端仍然可以使用给定的 URL 请求图像，而无需等待 HTML。
还有其他事情：请参阅陈伟霆的回答了解更多信息。

【讨论】：

服务器推送功能与您在 #4 中描述的功能不同吗？
数字 2 不正确，因为第一个连接需要内容 (HTML) 才能知道接下来要接收什么。在解析 HTML 期间，流水线已经生效。
这不是真的；大部分 HTML 文档引用的 URL 不是下载文档的服务器（例如 CDN、分析/广告 JS/内容等） - 如果您必须从头开始为每个服务器重新建立是否支持流水线，那么您就是大部分时间都无法使用流水线。

【解决方案3】：

HTTP 流水线在 HTTP 事务级别易受行头阻塞 (http://en.wikipedia.org/wiki/Head-of-line_blocking) 的影响，而 SPDY 由于使用多路复用，因此在传输级别仅存在行头阻塞。
HTTP 管道存在可部署性问题。请参阅https://datatracker.ietf.org/doc/html/draft-nottingham-http-pipeline-01，其中描述了许多不同的解决方法和启发式方法来缓解这种情况。在野外部署的 SPDY 没有这个问题，因为它通常使用 NPN (http://technotes.googlecode.com/git/nextprotoneg.html) 通过 SSL（端口 443）部署以协商 SPDY 支持。 SSL 是关键，因为它可以防止中介干扰。
SPDY 具有标头压缩功能。请参阅http://dev.chromium.org/spdy/spdy-whitepaper，其中讨论了标头压缩优势的一些基准测试结果。现在，需要注意的是带宽越来越不是问题（请参阅http://www.belshe.com/2010/05/24/more-bandwidth-doesnt-matter-much/），但记住带宽仍然是移动设备的关键也很有用。查看https://developers.google.com/speed/articles/spdy-for-mobile，它展示了 SPDY 对移动设备的好处。
SPDY 支持服务器推送等功能。请参阅http://dev.chromium.org/spdy/spdy-best-practices，了解使用服务器推送来提高内容的可缓存性并仍然减少往返的方法。
HTTP 流水线具有不明确的失败语义。当服务器关闭连接时，如何知道哪些请求已成功处理？这是不允许通过管道连接进行 POST 和其他非幂等请求的主要原因。 SPDY 提供语义来取消同一连接上的各个流，并且还有一个 GOAWAY 帧，指示要成功处理的最后一个流。
HTTP 管道在允许深度管道方面存在困难，通常是由于中间体。这（除了 HoL 阻塞等许多其他原因之外）意味着您仍然需要利用多个 TCP 连接来实现最大并行化。使用多个 TCP 连接意味着无法共享拥塞控制信息，无法共享压缩上下文（就像 SPDY 对标头所做的那样），这对互联网来说更糟（对中介和服务器来说成本更高）。

我可以继续讨论 HTTP 流水线与 SPDY。但我建议只是阅读 SPDY。查看http://dev.chromium.org/spdy 和我们关于SPDY 的技术讲座http://www.youtube.com/watch?v=TNBkxA313kk&list=PLE0E03DF19D90B5F4&index=2&feature=plpp_video。

【讨论】：