伴随着 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
评论