spdy - 了解 SPDY 延迟声明

Question

阅读 SPDY 白皮书 http://dev.chromium.org/spdy/spdy-whitepaper ，似乎支持它会改善我的 HTTP 延迟。但是，我不清楚其中的一些说法。

1) “因为 HTTP 一次只能获取一个资源(HTTP 流水线有帮助，但仍然只强制执行一个 FIFO 队列)，500 毫秒的服务器延迟阻止了 TCP channel 对额外请求的重用。” -- 这个 500ms 的数字从何而来？

2) “我们发现 SPDY 的延迟节省随着丢包率的增加而成比例地增加，在 2% 时加速高达 48%。” -- 但是，将所有请求放在单个 TCP 连接上是否意味着拥塞控制会减慢您的所有请求，而如果您有多个连接，则 1 个 TCP 流会减慢速度，而其他的则不会？

3)“[使用流水线]处理流中任何内容的任何延迟(线头处的长请求或数据包丢失)都会延迟整个流。” -- 这意味着丢包不会延迟使用 SPDY 的整个流。为什么不呢？

Answer 1

500ms的引用只是一个例子，数字可以是50ms或5s，但重点还是一样的:HTTP强制FIFO处理，导致底层TCP连接的使用效率低下。正如论文所指出的，流水线在理论上是有帮助的，但实际上流水线并没有被使用，因为许多中介在你打开它时会中断。因此，您遇到了最坏的情况:完整的 RTT + 服务器处理时间和 FIFO 排序。

再，丢包。是的，你完全正确。使用单个连接的缺点之一是，在丢包的情况下，整个连接的吞吐量减少了一半，而不是 N 个连接之一的 1/2 的吞吐量。话虽如此，还有一些好处!例如，当您使单个连接饱和时，由于三重 ACK + 可能更宽的拥塞窗口，您将获得更快的恢复。由于大多数 HTTP 传输相对较小(数十 KB)，因此不是许多连接在退出慢启动阶段之前就终止了，这是不寻常的!

再，流水线。丢失的数据包会延迟流 - 那是 TCP。胜利在于消除了队头阻塞，这使浏览器能够进行更多更智能的优化，然后是我上面描述的一些胜利。