如果你正在使用Chrome浏览器查看Gmail邮件的话，那么你很可能已经在不知不觉中开始使用Google规划的下一代互联网通讯协议SPDY了。Google在2009年11月***对外宣布了SPDY协议，这是Google构建快速网络中非常关键的一环。
在过去的18个月里面，SPDY已经逐渐被集成到了Stable分支的Chrome中。简单来说SPDY是更先进，更有效率的HTTP协议。SPDY协议可以通过一个单独的TCP链接实现并行的多路复用流通信，并且支持优先级，优先传送最重要的HTML内容，而其他JavaScript，视频等不是太重要的内容的优先级则会相对较低。总之，SPDY协议可以将页面载入时间缩短到现在的一半左右。
SPDY***的优势在于其是一个开源项目，现在我们正在使用的HTTP 1.1像个笨拙的巨兽，急需一个可以实现低延迟以及实时计算的新协议来取而代之。SPDY是个非常好的选择，但是现在还没有被大家广泛接受，目前貌似只有一个适用于Apache的实验性mod。
要想现在体验SPDY的话，其实非常简单：下载并安装Chrome，打开某个Google的站点（比如Gmail），之后在Chrome里面打开chrome://net-internals即可看到当前活动的SPDY进程了。对于使用者来说，SPDY相比HTTP没有任何区别，我们也很难“看”出使用了SPDY协议后有什么改进，但是我们肯定可以感觉到Google服务在Chrome下异常的快，这就是SPDY的功劳了。
拓展阅读：
spdy的spec [ http://dev.chromium.org/spdy/spdy-protocol ] 里什么都说得很清楚了。这个spdy的想法似乎不是很高招，但是却这么多年了没人提出过，这也许不是因为其他人不够聪明。***将会说到为什么。
http的性能损失，在spdy看来，来源于多链接。比如打开一个页面，除了文本另外还有图片等，那么浏览器就必须建立多个TCP，对每个资源发送http request。
而spdy提供了在一个TCP连接里请求多个资源的能力，并且提供了类似QoS的机制，使得浏览器对每个请求可以指定不同优先级，避免低优先级的请求把高优先级的给block了。另外，对http做了一些精简，去掉了一些没必要的headers。除此之外才是gzip压缩。
spdy把payload用frame来划分。frame分为control和data两种，这点看起来类似于ftp和rtsp。每个frame有对应的flags，flags的设计类似于tcp。spdy的思想大概就这么多，剩下的都是细节，如果不是实现者，没必要去研究了。spdy***的优点就是***程度的减少了tcp连接。
但是spdy有两个与生俱来的缺点：
1 虽然减少了tcp连接数量，但是留下来的tcp全都是长连接。客户端的负担是减少了，但是对proxy和服务器来说，是否会带来性能影响？存疑。
2 与现有的服务器兼容。不可能100%兼容。spec也说了，是尽量使其与现有服务器端兼容。而且从服务器和proxy的实现来说，现在的趋势是欢迎大量短连接，以提高并发量，这恰恰与spdy的思想是相悖的。最乐观的估计，chrome霸占了客户端市场，那服务器端难道google也想把apache/iis/ngix以及各种proxy给swap了？
