SPDY令人赞叹。这是十几年来对HTTP的第一次真正的升级，它不仅解决了高延迟移动网络的性能问题，还增强了Web的安全性。SPDY与HTTP有许多区别，但它最大的价值是它能通过复用仅仅一条（或几条)TCP连接，在客户端与服务器间发送几十个请求或回应。

之前的评测吹嘘说SPDY极其强力，从页面加载速度变两倍到相比纯HTTP用SPDY和HTTPS能让无线网站加载速度快23%。不过在实际生活中的网站上我没发现有这么大的进步。老实说，我的测试表明SPDY仅比HTTPS快一点点，同时还比HTTP要慢。

为什么？简单的说，SPDY改进了HTTP，但对大多数网站来说，HTTP不是瓶颈。 我土鳖
翻译于 2年前

1人顶

顶
翻译的不错哦!
其它翻译版本(1)
主要内容

你如果没有时间了解完整细节，可以看看这个快速介绍。

我用Chrome浏览器测量了美国500强（Alex）网站HTTPS和HTTP加载时间。又用Cotendo代理测试这些网站的SPDY加载时间——HTTPS和HTTP也经过Cotendo代理，保证比较的公平性。

结果显示SPDY平均比HTTPS只快4.5%，比HTTP慢3.4%。SPDY没有给页面加载提升多少，不能抵消从SSL切换的成本。 傅小黑
翻译于 2年前

1人顶

顶
翻译的不错哦!
其它翻译版本(1)

因为先前测试效果不好，我开始了这一轮测试。修改了一些测试细节：
只对第一方内容启用SPDY。
网站管理者无法控制第三方域名及其传输方式
打包第一方域名，不处理第三方域名
先前的测试把所有内容复制在同一域名下的页面中，即SPDY服务商生成的代理页面
不用客户端代理，用反向代理
客户端代理生成一次连接，将所有请求复合成一个。虽然这样更有利于SPDY处理，但是不符合实际。
测试了很多现实网站，有很多垃圾测试数据
测试包括页面中的很多域名、没优化的页面、效率低的后端等等。我主要关注的测试数据是来自高度优化的Google站点的，或是静态内容。这样可以消除现实世界（未优化，效率低等）造成的瓶颈。 傅小黑
翻译于 2年前

0人顶

顶
翻译的不错哦!
其它翻译版本(1)

测试结果的好坏我们让您自行判断，但它能帮助理解为什么结果会如此不同。

SPDY有许多原因没有改善性能，但以下两个问题很明显：

1.Web页面使用许多不同的域，SPDY在每个域都要建立连接。这意味着在多个跨域请求的时候SPDY并不能减少连接，此时SPDY的价值会减弱。

2.Web页面的其他瓶颈导致SPDY无法发起请求。例如，SPDY无法预防脚本阻塞，也不能使CSS无阻塞渲染。SPDY比HTTP好，但大多数页面的瓶颈不在HTTP协议上。 QiuPengTao
翻译于 2年前

0人顶

顶
翻译的不错哦!
其它翻译版本(1)

为了完成这个实验，我需要一组网站去测试，一个支持SPDY的客户端以及反向代理。

网站，我选择了Alexa上美国前500的网站。令人担忧的是这里面有相当数量的黄色网站，但它很好的表现了人们的需求。

反向代理，我选择了Cotendo CDN（最近被Akamai收购了）。Cotendo是最早适配SPDY协议的代理之一，有工业级的SPDY支持和高性能服务器。Cotendo支持三种协议 - HTTP，HTTPS以及SPDY。 QiuPengTao
翻译于 2年前

0人顶

顶
翻译的不错哦!
其它翻译版本(1)

客户端，我使用WebPageTest的Chrome代理（和Pat Meenan的帮助）。WebPageTest和真正的Chrome一样（我测试的时候是Chrome v18）并且支持SPDY。注意，Chrome随机在5%的用户上禁用SPDY，但WebPageTest没有做这个取样。我测量每个页面5次，超过4种不同的网速，包括Cable，DSL，低延迟移动网络和高延迟移动网络。

由于一些网站使用多个顶级域名，我也使用一些Akami重写能力去尝试合并这些域。简单的讲，HTML里引用的大多数静态资源通过当前页的域获取。这能帮助SPDY充分发挥作用。

最后，由于一天中的时段不同以及网络原因会是的结果有误差。我重复测试3次，两次白天一次深夜。总共我加载了90,000个独立页面，每种模式30,000个，这能确保统计的精度。 QiuPengTao
翻译于 2年前

0人顶

顶
翻译的不错哦!
其它翻译版本(1)
测试结果

主要的测试结果是SPDY并不能让网站变快。下面几组数据强调了这个结果：
SPDY平均仅比HTTPS快4.5%；
SPDY平均比HTTP（不使用SSL）慢3.4%；
SPDY加速中值是1.9%；
SPDY仅在59%的测试中比HTTPS快；
SPDY在比较平均加载速度这方面（包括每一种URL/协议，横跨不同批次和网络速度）仅比HTTPS快2.1%；
SPDY加速值在三个不同测试批次中分别为4.3%、6.3%和2.8%。

当考虑到不同的网络速度时，数字稍微有所变化，但结论没变。下面这个表格总结了SPDY与HTTP和HTTPS相比对网络速度的影响： 网络速度（下载/上传(Kbps)，延迟(ms)） SPDY vs HTTPS SPDY vs HTTP
有线网（5000/1000，28） SPDY快6.7% SPDY慢4.3%
DSL（1500/384，50） SPDY快4.4% SPDY慢0.7%
低延迟移动网络（780/330，50） SPDY快3% SPDY慢3.4%
高延迟移动网络（780/330，200） SPDY快3.7% SPDY慢4.8%

精确数字不重要，重要的是它们彼此间的差距很小。无论怎么看，结论都是SPDY没起多大作用。
我土鳖
翻译于 2年前

0人顶

顶
翻译的不错哦!
如果SPDY这么赞，为啥它没让网站变快呢？

简单答案是：它没解决当前的网络瓶颈。通过深入挖掘这份数据，我整理出了一套理论来阐明为什么SPDY没起到加速效果。
域名使用过多

SPDY针对单个域名优化。在每个资源都放在不同域名中的极端情况下，SPDY根本起不了作用。现在的网页都引用大量域名（不少是第三方域名），这限制了SPDY的发挥。
在这个测试中，平均每个网页都从18个不同的域名加载资源。低于一半的资源与引用它们的HTML文件在同一域名下。SPDY的价值主要体现在通过复用请求减少网络连接这一方面，而每个网页上如此巨大的域名数量无法体现这个价值。 我土鳖
翻译于 2年前

0人顶

顶
翻译的不错哦!


分别仔细观察每个测试，我们可以发现相比于HTTPS，SPDY将每网页域名的平均连接数从6.2奇迹般的减少到了2.6*（见上图）。然而，包括所有域名在内的总连接数从HTTPS的34.9减少到了SPDY的30.5，绝对数字有所下降，但相对比例不高。

即便所有域名都启用了SPDY，结果也不太可能有什么变化。平均来看，18个域名中的9个每次仅被1个请求所引用，4个附加域名提供了另外2个资源。每个这类域名都需要一个TCP连接，这种情况无法从SPDY中受益。

*Chrome对页面使用一个连接，对资源使用第二个连接，在某些情况下对延迟加载资源或者从网站的非SSL版本引用的随机资源使用第三个连接，导致平均连接数升高到了2.6。 我土鳖
翻译于 2年前

0人顶

顶
翻译的不错哦!
资源阻塞

加载一个网页并不是简简单单的并行下载完所有资源就搞定了。比如说当加载一个网页时，浏览器一般不会下载任何图片，除非JavaScript和CSS文件获取完毕并得到处理。CSS文件也有可能导入其他CSS文件，浏览器还没先进到能预测这种情况。有些脚本也会产生需要浏览器加载的新资源。

SPDY对这种延迟无能为力，并且总的来说我能断定相关的浏览器行为并无改变。对于许多（要么就是大多数）网页来说，这些延迟才是真正的瓶颈，只留下极少的空间给SPDY发挥。 我土鳖
翻译于 2年前

0人顶

顶
翻译的不错哦!
结语

从这次研究中我们能得到两组收获。

如果你是站长，你最好调整一下你对SPDY的预期。将网站切换到SPDY确实有效，但加载速度快不了多少。为了最大限度发挥SDPY的作用，应当减少每个网页中引用的域名数量，同时消除其他的前端瓶颈。不管你用不用SPDY这都是个好主意，所以最好别浪费你的时间，马上行动起来。 我土鳖
翻译于 2年前

0人顶

顶
翻译的不错哦!

如果你是浏览器开发者，或者说是SPDY社区的参与者，那么你应当多花点时间来解决上面提到的SPDY中的各种问题。举个例子，Chrome已经尝试在使用同一IP和SSL证书的主机间共享连接来减少总连接数。这些SPDY和SSL的修改无疑会扩展复用程度，既能加速页面又能降低服务器负载。另一种思路是让浏览器中的SPDY实现能进一步消除其他瓶颈。比如说更激进的前瞻策略能提前加载更多资源，请求优先级排队能减少拥堵。就我所知，这些观点中的一部分已被讨论过，但还没开始广泛推行。

我相信SPDY依然令人赞叹，同时它也是朝正确方向迈出的一步。这次研究及其结论并不意味着我们会停止在SPDY身上下功夫，相反它告诉我们应当继续深入，让SPDY变得更快。