SPDY和在保持连接的HTTP多路复用有什么不同？

Question

HTTP 1.1支持保持活动连接，即在发送“Connection: close”之前不会关闭连接。

因此，如果浏览器（例如Firefox）启用了network.http.pipelining并增加了network.http.pipelining.maxrequests，最终效果是否相同呢？

我知道这些设置被禁用是因为对于某些网站来说，这可能会增加负载，但我认为一个简单的HTTP标头标志可以告诉浏览器使用多路复用，这个问题可以更容易地解决。

难道不应该更改浏览器的默认设置，而不是发明一个新的协议，增加HTTP服务器的复杂性吗？

- codeassembly

---

SPDY在请求和响应头上使用有状态压缩。 - Dan D.

这会有很大的区别吗（特别是对于SSL中已经存在的普通压缩）？ - Thilo

HTTP也可以使用gzip压缩，几乎所有的浏览器都支持它，并且头部通常太小而无关紧要。 - codeassembly

HTTP无法压缩头部。 大型头部通常用于传递大量的大型cookie。出于很好的原因，HTTP头部大小没有限制。我曾经看到过一些奇怪的持久性东西在头部发送了几百KB的数据。 - Lothar

Answer 1

SPDY拥有许多优点，超越了HTTP流水线技术所能提供的，这些优点在SPDY白皮书中进行了描述：

1. 使用流水线技术，服务器仍然必须按请求顺序逐个返回响应。如果客户端请求的动态生成的资源在静态资源之前，这将是一个问题：服务器无法发送任何“简单”的静态响应，直到动态生成的响应已经生成并发送。使用SPDY可以按照生成的顺序乱序或并行返回响应，降低接收所有资源的总时间。
2. 正如您在问题中指出的，不是所有服务器都能处理流水线技术：这与负载有关，有些服务器在客户端请求流水线时实际上会出现错误。使用头来指示可以执行流水线技术已经太晚，无法获得最大的好处：此时您已经接收到第一个响应，因此虽然您可以在将来的连接上使用它，但对于此连接已经太迟了。
3. SPDY使用一种专门针对该任务的算法（具有状态和对HTTP标头通常包含内容的了解）来压缩标头；虽然是的，SSL已经包括压缩，但仅使用deflate来压缩它们效率不高。大多数HTTP请求没有正文，只有很短的GET行，因此标头几乎构成整个请求：任何可以获得的压缩都是一个改进。许多响应与其标头相比也很小。

SPDY允许服务器在客户端请求前发送额外的响应内容。例如，服务器可以在客户端接收和解析HTML以确定样式表URL之前，随同原始HTML一起发送页面的CSS。这可以通过消除客户端实际解析HTML后请求其他资源来进一步加快页面加载速度。它还支持一个较少带宽负荷的版本，其中它可以“提示”哪些资源可能是需要的，并允许客户端决定：这允许不关心图像的客户端不必去请求它们，但想显示图像的客户端仍然可以使用给定的URL请求图像而不需要等待HTML。

其他内容也有：欲了解更多，请参见William Chan的答案。

- Torne

---

服务器推送不就是你在第四点描述的功能吗？ - Dmitry Pashkevich

数字2不正确，因为第一个连接需要内容（HTML）才能知道它接下来要接收什么。在解析HTML期间，流水线已经生效。 - Lothar

这并不完全正确；大部分HTML文档都会引用除了下载该文档的服务器之外的URL（例如CDN、分析/广告JS/内容等）- 如果你必须针对每个服务器重新开始建立是否支持流水线处理的话，那么你大多数情况下将无法使用流水线处理。 - Torne

Answer 2

• HTTP管线化在HTTP事务级别容易受到HOL阻塞的影响（http://en.wikipedia.org/wiki/Head-of-line_blocking），而SPDY仅在传输层具有HOL阻塞，这是由于其使用多路复用。
• HTTP管线化存在部署问题。请参见https://datatracker.ietf.org/doc/html/draft-nottingham-http-pipeline-01，其中描述了许多不同的解决方法和启发式方法来减轻这个问题。实际部署中的SPDY并没有这个问题，因为它通常是通过SSL（端口443）使用NPN协议（http://technotes.googlecode.com/git/nextprotoneg.html）来协商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 pipelining存在不确定的失败语义。当服务器关闭连接时，您如何知道哪些请求已经成功处理？这是POST和其他非幂等请求不能在流水线连接上允许的主要原因。SPDY提供了取消同一连接上单独流的语义，并且具有GOAWAY帧，指示最后一个成功处理的流。

HTTP pipelining由于中介机构的问题，通常难以允许深度流水线。这（以及诸多其他原因，如HoL阻塞）意味着您仍然需要利用多个TCP连接来实现最大的并行化。使用多个TCP连接意味着拥塞控制信息无法共享，压缩上下文无法共享（像SPDY一样与头文件），对互联网更糟糕（对中介机构和服务器更昂贵）。

我可以继续讲述HTTP pipelining vs SPDY的优劣，但我建议只需阅读SPDY的相关内容。请参阅http://dev.chromium.org/spdy和我们在http://www.youtube.com/watch?v=TNBkxA313kk&list=PLE0E03DF19D90B5F4&index=2&feature=plpp_video的SPDY技术讲座。

- William Chan

Answer 3

请查看HTTP pipelining和SPDY中的HTTP multiplexing的区别

- qualle