伴随着Jetty 7.6.2版本的发布，SPDY™协议现在在同名的服务器软件中也得到了支持。该协议之前是为8.2版本开发的，现在它已经向下移植到了7.6.2版本，8.1.2版本也支持，二者未来的版本同样会支持，还有Hightide应用服务器。
SPDY™是HTTP连接传输层协议的进化版本，在Google Chrome中得到默认支持，在Firefox 11版本中有对应配置选项。尽管目前还不是标准，但是它已经作为草案提交给IETF的httpbis工作组。很多Google的服务都已经通过SPDY提供，其他公共站点（比如Webtide和Twitter）也支持该协议。
SPDY™对传输层安全协议TLS的规范提出“下次协议协商（Next Protocol Negotiation）” 改进，在传输层安全协议TLS的升级版本上工作。其结果是：SPDY™是隐式安全的协议，而且，目前端口443的流量不会执行中间人校验（man-in- the-middle inspection），而允许此类流量的HTTP代理将会透明支持使用该协议。为了理解SPDY™带来的好处，InfoQ找到Jetty项目组的 Greg Wilkins和Simone Bordet，向他们的提问，从SPDY的速度优势开始：
Greg Wikins：SPDY有几个方面都让其具有性能提升。首先，它使用多路复用连接，创建新连接造成的 延迟（有时每个浏览器会达到6）就可以避免了。而且，压缩HTTP头之后，它在每次请求和响应中都节省了数百个字节，因为很多页面在呈现时都要用10、 20乃至更多请求和响应，这样做节省了大量数据传输损耗。更进一步的是，降低了需要的连接数目之后，这会减少服务器上每个客户端占用的资源，释放更多内存 和CPU，可以完成更有用的工作。
要注意的是，这么做不是没有代价的。SPDY需要服务器使用传输层安全协议TLS和压缩，因此，这么做需要CPU和内存资源。不过，对于专用的SPDY中间服务器来说，如果使用更多CPU成为问题，这样的负载很容易卸掉。
Simone Bordet：提到资源负载，多路复用还会带来其他好处。典型的web页面有10-30个次要资 源，包含在页面中，需要从服务器取得。当今的浏览器只能向同一个服务器发出6个并行请求，使用SPDY，这个限制就没有了，浏览器可以按需求自由打开多个 多路复用的“流”，大大提升页面加载速度，并且不再需要HTTP管道。同时，多路复用“流”可以设置优先级，先传输像CSS这样更重要的资源，后传输网站 图标（favicon）之类不太重要的资源。这么做的结果提升了TCP连接的利用率，同时提升了TCP的性能。
发出多路复用“流”而且没有6个连接的限制，这种能力让实时web应用（基于Comet技术的应用）对实现细节的依赖更低。目前，一个Comet web应用必须确保不会用尽浏览器分配的4到6个连接，使用SPDY，这个限制也就不存在了。
InfoQ：对于SPDY和HTTP之间的性能对比，你是否能提供一些评测分数？
Greg Wilkins：Jetty还没有。Google已经发现：页面加载延迟方面的改进超过60%；但是他们没有说明CPU和内存用量上的变化。
对于Jetty来说，我们最初的实现必须要考虑到不支持多路复用HTTP协议的软件架构，因此我们认为会存在效率降低。然而，我们现在已经开始开发 jetty-9版本了，它为SPDY风格的连接重新设计了架构。我们希望很快能够有一些性能方面的数字，随着jetty-9版本工作的推进，这些数字也会 不断改进。
InfoQ：使用SPDY对HTTP代理的缓存有哪些影响？是否有计划开发SPDY缓存服务器？
Greg Wilkins：影响非常大！现有的HTTP代理讲无法看到SPDY流的内容，因为它们被加密了。不 过，SPDY的确有对缓存的出色支持，因为它的内部机制会预测客户端需要的资源，并支持内容的推送和提醒。但是任何代理缓存都必须理解SPDY，并成为 SSL会话的一部分。因此，一些传输层安全协议TLS的扩展可能需要允许SPDY连接中的活跃中间代理。
InfoQ：对于现有的web应用，Jetty中有哪些代码或配置需要改变，才能支持SPDY？在服务器上是否有特定的配置需要开启？还是说这是默认设置？
Greg Wilkins：SPDY带有HTTP请求，因此，应用不需要改变，请求和响应的语义也没有变化。将来，可能会有人提出在应用中直接针对SPDY层编程，但是目前，对于应用来说可以看做是透明的变化。
Simone Bordet：没有，跟以前一样，现有的Java web应用可以向Jetty中直接部署，而且能够享有绝大多数SPDY特性的好处，比如头压缩和流的多路复用，不需要任何改变。只有服务器的配置需要更新，而且变动很小：只需将SSL连接组件替换为SPDY连接组件（org.eclipse.jetty.spdy.http.HTTPSPDYServerConnector）。
InfoQ：客户端如何将他们的HTTP连接升级到SPDY？这是不是能在Jetty现有的Http客户端类中透明完成？
Greg Wilkins：使用“下次协议协商（Next Protocol Negotiation，简称NPN）”扩展，在443端口打开一个TLS连接，SPDY连接就建立起来了。如果服务器理解NPN扩展，那么它就会看到一 个SPDY连接正在请求，而且它可以接受。否则，连接就会退回成为一个普通的https连接。
NPN扩展还不是一个标准，而且JVM还不支持。Simone使用一些非常聪明的做法，扩展了现有的开放JDK类，使其支持NPN。希望这很快能成为标准，并且最终在所有的JVM中得到支持。
Simone Bordet：我们还没有把SPDY整合到Jetty的HttpClient中，但是我们提供一个纯SPDY客户端，可以用来向允许SPDY的服务器发出SPDY调用（因此，目前HTTP分层必须手工由客户端完成）。
SPDY的另一个有趣之处，在于它可以在客户端请求资源之前就推送给它们。因此，举个例子，当下载一个静态HTML页面的时候，服务器可以意识到： 页面包含一个CSS资源、一个JS脚本，还有多张图片。服务器会开始下载页面开始数行HTML标签，然后推送CSS，继续下载几行，然后推送JS，下载更 多行，推送图片，如此往复。这会节省很多个来回的时间，最终在页面呈现上带来大量节省。
目前大家也在讨论，服务器如何才能看到这些要推送的资源。解决方案包括加入更多元数据文件（比如加入index.html.spdy文件，包括要为 index.html推送的资源），还有能够分析服务器发出请求的运行时，还有针对主要资源请求完成后总是要请求的次要资源，对每个资源都提供缓存等等。 服务器是否要实现这些特性，要看服务器的实现，但是关键在于：SPDY让大量服务器端的优化成为可能，而这些优化使用普通的HTTP无法完成。
最后是关于浏览器的，SPDY完全集成在浏览器端的每个HTTP请求中，因此不仅仅是从地址栏请求页面，通过XMLHttpRequest的请求也支持SPDY。
InfoQ：客户端与服务器能否使用SPDY完成除HTTP之外的更多请求？比如为了推送更多信息。
Greg Wilkins：是的，不过目前浏览器还不行，但是在服务器端可以直接访问SPDY。浏览器是否可以直接暴露SPDY语义，或是继续将其隐藏在HTTP或WebSockets应用层之下，目前还要观察。
InfoQ：SPDY要想得到广泛使用，必须要成为IETF标准，而不仅仅是一个Google的项目。是否有一个RFC说明SPDY协议目前的状态？如果没有，您认为什么时候可能发生？Google将SPDY注册成为一个商标，这样的担心是否有必要？
Greg Wilkins：首先，我要为Google一直以来处理这个项目的方式鼓掌。在很多方面，这可以看作 是Google对自己市场支配力的滥用，因为他们利用自己广泛使用的浏览器和web服务，在互联网上强行推广了一种新的私有协议，而不管大众是否需要。从 另一面来说,Google对于他们的意图和协议的开发非常开放。该协议在过去两年，都是Google的研发项目，那里的研发人员与社区结合很紧密，他们会 思考反馈，并为设计和实现做出贡献。
Google声称将会把该协议提交到IETF，以将其标准化，他们已经提交了一个草案，交给了httpbis工作组。我不熟悉整个标准化过程具体的时间周期，但是我认为目前的举措很符合IETF对标准的偏好，包括粗略的结论共识和可工作的代码。
因此，确实有些疑问，质疑这是否是Google对自己市场份额力量的滥用，但是我认为我们不必过分担心，只要它在一定时间内提交给IETF。重要的 是：没有哪些Google提供的特性与SPDY绑定在一起。如果你不喜欢，你随时可以阻止它，那么你得到的还是同样通过HTTP的服务，只不过延迟稍微长 一点。
InfoQ：最后，Jetty也支持WebSockets作为通用通信机制，它使用HTTP来传输数据包。你能解释下SPDY与WebSockets之间的区别么？二者将来是否可能相遇？
Greg Wilkins：WebSockets就像HTTP，可以看做两部分：通信交互的语义，和传输语义的 协议。WebSocket向浏览器引入双向数据图，提供的协议完成服务器端的数据发送和接收。SPDY替换了HTTP的打包协议，它也可以替换 WebSocket的打包协议。现在已经有了使用SPDY替换WebSocket的相关提议和beta实现。
SPDY™是Google公司的注册商标。