SPDY
英文原文：
Not as SPDY as You Thought
SPDY令人赞叹。这是十几年来对HTTP的第一次真正的升级，它不仅解决了高延迟移动网络的性能问题，还增强了Web的安全性。SPDY与HTTP有许多区别，但它最大的价值是它能通过复用仅仅一条（或几条)TCP连接，在客户端与服务器间发送几十个请求或回应。
之前的评测吹嘘说SPDY极其强力，从页面加载速度变两倍到相比纯HTTP用SPDY和HTTPS能让无线网站加载速度快23%。不过在实际生活中的网站上我没发现有这么大的进步。老实说，我的测试表明SPDY仅比HTTPS快一点点，同时还比HTTP要慢。
为什么？简单的说，SPDY改进了HTTP，但对大多数网站来说，HTTP不是瓶颈。
主要内容
你如果没有时间了解完整细节，可以看看这个快速介绍。
我用Chrome浏览器测量了美国500强（Alex）网站HTTPS和HTTP加载时间。又用Cotendo代理测试这些网站的SPDY加载时间——HTTPS和HTTP也经过Cotendo代理，保证比较的公平性。
结果显示SPDY平均比HTTPS只快4.5%，比HTTP慢3.4%。SPDY没有给页面加载提升多少，不能抵消从SSL切换的成本。
其它翻译版本 (1)
加载中
因为先前测试效果不好，我开始了这一轮测试。修改了一些测试细节：
网站管理者无法控制第三方域名及其传输方式
先前的测试把所有内容复制在同一域名下的页面中，即SPDY服务商生成的代理页面
客户端代理生成一次连接，将所有请求复合成一个。虽然这样更有利于SPDY处理，但是不符合实际。
测试包括页面中的很多域名、没优化的页面、效率低的后端等等。我主要关注的测试数据是来自高度优化的Google站点的，或是静态内容。这样可以消除现实世界（未优化，效率低等）造成的瓶颈。
其它翻译版本 (1)
加载中
测试结果的好坏我们让您自行判断，但它能帮助理解为什么结果会如此不同。
SPDY有许多原因没有改善性能，但以下两个问题很明显：
1.Web页面使用许多不同的域，SPDY在每个域都要建立连接。这意味着在多个跨域请求的时候SPDY并不能减少连接，此时SPDY的价值会减弱。
2.Web页面的其他瓶颈导致SPDY无法发起请求。例如，SPDY无法预防脚本阻塞，也不能使CSS无阻塞渲染。SPDY比HTTP好，但大多数页面的瓶颈不在HTTP协议上。
其它翻译版本 (1)
加载中
为了完成这个实验，我需要一组网站去测试，一个支持SPDY的客户端以及反向代理。
网站，我选择了Alexa上美国前500的网站。令人担忧的是这里面有相当数量的黄色网站，但它很好的表现了人们的需求。
反向代理，我选择了Cotendo CDN（最近被Akamai收购了）。Cotendo是最早适配SPDY协议的代理之一，有工业级的SPDY支持和高性能服务器。Cotendo支持三种协议 - HTTP，HTTPS以及SPDY。
其它翻译版本 (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个，这能确保统计的精度。
其它翻译版本 (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没起多大作用。
如果SPDY这么赞，为啥它没让网站变快呢？
简单答案是：它没解决当前的网络瓶颈。通过深入挖掘这份数据，我整理出了一套理论来阐明为什么SPDY没起到加速效果。
域名使用过多
SPDY针对单个域名优化。在每个资源都放在不同域名中的极端情况下，SPDY根本起不了作用。现在的网页都引用大量域名（不少是第三方域名），这限制了SPDY的发挥。
在这个测试中，平均每个网页都从18个不同的域名加载资源。低于一半的资源与引用它们的HTML文件在同一域名下。SPDY的价值主要体现在通过复用请求减少网络连接这一方面，而每个网页上如此巨大的域名数量无法体现这个价值。
分别仔细观察每个测试，我们可以发现相比于HTTPS，SPDY将每网页域名的平均连接数从6.2奇迹般的减少到了2.6*（见上图）。然而，包括所有域名在内的总连接数从HTTPS的34.9减少到了SPDY的30.5，绝对数字有所下降，但相对比例不高。
即便所有域名都启用了SPDY，结果也不太可能有什么变化。平均来看，18个域名中的9个每次仅被1个请求所引用，4个附加域名提供了另外2个资源。每个这类域名都需要一个TCP连接，这种情况无法从SPDY中受益。
*Chrome对页面使用一个连接，对资源使用第二个连接，在某些情况下对延迟加载资源或者从网站的非SSL版本引用的随机资源使用第三个连接，导致平均连接数升高到了2.6。
资源阻塞
加载一个网页并不是简简单单的并行下载完所有资源就搞定了。比如说当加载一个网页时，浏览器一般不会下载任何图片，除非JavaScript和CSS文件获取完毕并得到处理。CSS文件也有可能导入其他CSS文件，浏览器还没先进到能预测这种情况。有些脚本也会产生需要浏览器加载的新资源。
SPDY对这种延迟无能为力，并且总的来说我能断定相关的浏览器行为并无改变。对于许多（要么就是大多数）网页来说，这些延迟才是真正的瓶颈，只留下极少的空间给SPDY发挥。
本文中的所有译文仅用于学习和交流目的，转载请务必注明文章译者、出处、和本文链接。
2KB翻译工作遵照
CC 协议，如果我们的工作有侵犯到您的权益，请及时联系我们。
2KB项目（www.2kb.com，源码交易平台）,提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务
