新版本 Jetty 支持 SPDY 协议

伴随着 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 公司的注册商标。

查看英文原文： Jetty Gets Speedy