阅读http://dev.chromium.org/spdy/spdy-whitepaper上的 SPDY 白皮书，似乎支持它会改善我的 HTTP 延迟。但是，我不清楚其中的一些说法。
1）“因为 HTTP 一次只能获取一个资源（HTTP 流水线有帮助，但仍然只强制执行 FIFO 队列），500 毫秒的服务器延迟会阻止 TCP 通道重复用于其他请求。” -- 这个500ms的数字是从哪里来的？
2) “我们发现，SPDY 的延迟节省随着丢包率的增加而成比例地增加，在 2% 时加速高达 48%。” - 但是，将所有请求放在单个 TCP 连接上是否意味着拥塞控制会减慢您的所有请求，而您是否有多个连接，1 个 TCP 流会减慢速度，而其他 TCP 流不会？
3) “[使用流水线] 处理流中任何内容的任何延迟（无论是前端的长请求还是丢包）都会延迟整个流。” -- 这意味着丢包不会延迟使用 SPDY 的整个流。为什么不？
500ms的引用只是一个例子，数字可以是50ms也可以是5s，但重点还是一样的：HTTP强制FIFO处理，导致底层TCP连接使用效率低下。正如论文所指出的，流水线在理论上可以提供帮助，但实际上管道并没有被使用，因为许多中介在你打开它时会中断。因此，您会遇到最坏的情况：完整的 RTT + 服务器处理时间和 FIFO 排序。
再者，丢包。是的，你完全正确。使用单个连接的缺点之一是，在丢包的情况下，整个连接的吞吐量减少了一半，而不是运行中的 N 个连接之一的 1/2。话虽如此，但也有一些好处！例如，当您使单个连接饱和时，由于三重 ACK + 可能更宽的拥塞窗口，您将获得更快的恢复。由于大多数 HTTP 传输相对较小（数十 KB），它不是许多连接在退出慢启动阶段之前就终止了！
重新，流水线。丢失的数据包会延迟流 - 那是 TCP。胜利在于消除了线头阻塞，这使得浏览器能够进行更多更智能的优化，其次是我上面描述的一些胜利。
@GroovyDotCom：这是 HTTP2 (SPDY) 性能优势的一些实践证明：