Roy Fielding 谈 Google SPDY 协议

2010 年 8 月，HTTP 协议的原创作者 Roy Fielding 接受了“Geek of the Week”栏目记者 Richard Morris 的采访，其中有很长一段内容涉及到了 Google 的 SPDY 协议。Fielding 对于 SPDY 协议提出了一些批评意见：

• 改善网络延迟问题的最佳途径是使用缓存，SPDY 改善网络延迟的做法，从协议开发的角度来说是短视的。
• 除非 SPDY 协议能够像 HTTP 那样非常好地支持分层的缓存机制，才有可能取代 HTTP 协议。然而，SPDY 协议设计者的兴趣似乎更多地局限于其他方面，例如强制要求加密和建立穿越中间组件的隧道。如果这个趋势延续下去，仅仅那些需要认证服务的开发者会对 SPDY 协议感兴趣。在那些场景中，他们不想共享缓存，并且能够支付的起每个客户端保持长时间连接所需要的基础设施费用。
• SPDY 协议目前的设计无法很好地支持分层的服务注 1（layered services）。换句话说，中间组件很难看到消息内容，并且快速判断请求应该由哪个服务器来处理。而支持分层服务，对于所有的互联网规模（Internet-scale）的服务来说都是必不可少的。他怀疑 Google 的运维人员已经在教育这些工程师相关的经验教训了。如果在不远的未来，SPDY 协议的设计发生大的改变，他一点也不会感到奇怪。

不过 Fielding 也承认，HTTP/1.1 的线路语法注 2（wire syntax）中存在很多低效率的部分，HTTP/1.1 肯定会被某种类似 HTTP+SPDY 的协议所取代。事实上他在 2001 年就开始了相关的努力，开发了一个叫做 WAKA 的新协议，但是并没有选择在 IETF/W3C 内部来开发。

2012 年 3 月底，在 W3C 的邮件列表中，有一个标题为“SPDY = HTTP/2.0 or not ?”的讨论。这个讨论有很多人参与，值得关心 HTTP 协议发展方向的同学们仔细一读。在这个讨论中，Roy Fielding 与 SPDY 协议作者 Mike Belshe 阐述了各自针锋相对的观点。Mike Belshe 在他的第一次发言中提到：

我们现在正处在一个十字路口，需要做出重要的抉择。
[…] 请你们去满世界寻找到哪怕只有一个人，他想要一个不安全的互联网。我不相信世界上存在这样的用户。大多数用户没有意识到他们所使用的互联网是不安全的。我知道很多网站为了节省开支，甘愿让用户冒风险。我们究竟应该迎合这些网站呢，还是应该迎合用户？
[…] 在任何产品中，安全性都不是一个选项，而是一个必需品。用户期望安全性，并且需要安全性。

接下来他还提到两点，借以证明 SSL 可以，也有必要称为“必需品”：

• CPU 的成本在持续下降，摩尔定律使得应用 SSL 即使在廉价的硬件上也是可行的。如果网站甘愿让用户冒风险（如果你们来问我，我会认为这是完全不负责任的行为），那么继续使用 HTTP/1.1 好了。未来的互联网应该是安全的。
• 除非我们使得 SSL 成为一个必需品，而不是一个选项，否则 SSL 实现的性能将会一直低于标准。这是一个自我实现的预言，现在的 SSL 实现之所以很慢，正是因为我们没有尝试严肃地看待它们。

他补充道：

如果你们不相信我所说的安全性的重要性，请看看所有主要的社交网站内容提供商。Google 和 Twitter 已经 100% 使用了 SSL，Facebook 和 Microsoft 也没有落后多少。用户需要安全性，他们现在就需要！我们应该停止将安全性作为一个选项的讨论。
一个更好的争论话题应该是：“SSL 是否是保护 Web 的正确方式？”而不是：“我们是否应该保护 Web？”

Roy Fielding 在发言中提到：

我从不认为应该将 SSL 作为保障协议安全的必要手段。SSL 虽然有助于对被动的观察者隐藏数据交换的内容，但是传统的 User Agent 证书管理方式对于保证协议安全来说其实是有欠缺的。

Fielding 质疑“在任何时候，每一个用户都想要一个安全的协议”这个观点是不切题的。他指出，在实践中有很多使用 HTTP 的例子，开发者既不想用 SSL/TLS，也不适合使用 SSL/TLS。同样的，很多人在亭子间、公立学校、图书馆和其他区域使用 HTTP，SPDY 设计者所认为的用户对于隐私问题的关注，其实不如该区域所属组织对于防止 HTTP 协议被滥用的责任更重要注 3。

其实还有其他的方法既可以保证协议安全，又能保证协议对于中间组件的可见性，但是我们不必预先就同意安全性是一件“必需品”。如果协议的前提无法支持自己并自圆其说，那么我不需要一个新的协议。

Mike Belshe回应了 Roy Fielding 的言论：

实际上，我没见过哪个例子能证明用户想要一个不安全的产品或者协议。我们当然无法解决所有的问题，但是这不意味着我们能对其置之不理。我们现在已经能够解决大多数的偷听问题（eavesdropping problem）了。所以问题在于：为何我们不应该去做这件事情？ […] 协议只有在提供了真正的价值时才会成功。这里有一个主观的问题是，安全性和隐私保护是否是价值的一部分。

笔者点评：

在“SPDY = HTTP/2.0 or not ?”这个大讨论中，Mike Belshe 并没有完全理解 Roy Fielding 的观点，甚至有些抵触。笔者怀疑 Roy Fielidng 在 2010 年“Geek of the Week”访谈中对 SPDY 协议的批评让他很不满，因为 Fielding 甚至怀疑 Mike Belshe 没有做运维的经验（特别是高可伸缩性网站架构的设计和实践的经验），需要 Google 做运维的同事给他上上课。

总的说来，Fielding 的批评还是比较中肯的，考虑问题也更加全面。因为设计一个像 HTTP 这样的 Web 基础协议，除了安全性之外，还有一些同样重要的考量，例如可伸缩性，甚至还需要考虑一些社会性方面的问题。在安全性、可伸缩性、社会性等方面的考量，常常存在着冲突，无法兼顾，在每一方面都要达到完美的境界，因此需要非常慎重地加以权衡。这些权衡，Fielding 已经很清楚地写在了他于 2000 年所发表的博士论文之中。正是在这篇博士论文中，Fielding 通过讨论架构风格所要满足的架构约束，严谨地推导出一种专门为面向互联网的Web 应用量身定制的架构风格——REST。

笔者推测Mike 并没有认真读过这篇论文，不然他应该能更容易地理解Fielding 和IETF/W3C 中一些其他专家的观点。REST 要满足的一个非常重要的架构约束就是“分层系统”（Layered System）。HTTP/1.1 协议为何如此设计，背后的指导原理正是REST。HTTP/1.1 协议有一个很重要的目标就是支持分层系统的架构设计（常见的分层系统例如分层的缓存、分层的代理服务器、分层的防火墙等等）。分层系统要求整个系统实现统一接口，保持HTTP 消息的语义对于中间组件具有可见性。

而SPDY 协议因为强制使用SSL，只支持端到端（User Agent 到Origin Server）的密钥协商和通信，将参与到HTTP 通信链路之中的其他中间组件（缓存、代理服务器、防火墙等等）完全排除，因此无法满足“分层系统”的架构约束。SPDY 协议最大的问题就在于此，引起争论最多的正是强制使用SSL，这会给协议的部署工作带来很多麻烦。其实还有其他的方法，在满足“分层系统”架构约束的情况下，解决安全性的问题。

如果网站已经大量使用了SSL，例如国内像支付宝、网上银行一类的网站，那么可以将SPDY 协议作为一种优化的HTTPS 实现。这样做不会有什么问题，部署起来难度也不算大。但是如果网站没有大量使用SSL，选择SPDY 协议时需要非常慎重。

SPDY 协议中确实有很多值得借鉴的地方，其团队也才华横溢。但笔者认为 SPDY 协议不大可能在未来直接取代 HTTP/1.1，认为 SPDY 协议就是未来的 HTTP/2.0，要么是夸大其词，要么是故意的市场炒作。事实上，IETF 的 HTTPbis 工作组的主要工作，正是对 HTTP/1.1 协议进行重新评估和改造，欲了解他们的工作成果，可以访问其官方 Wiki 。他们已经将 HTTP/1.1 协议模块化，划分成了 7 个模块：

（图片源自： http://restlet.files.wordpress.com/2011/10/http-1-1-bis.png?w=460 ）

估计在大约两年之内，IETF 将会发布一个 HTTP/1.1 协议的修订版（但不是传说中的 HTTP/2.0 协议）。SPDY 协议中多路复用、头信息压缩、设置请求优先级的做法可能会被最基础的 Messaging 模块所借鉴。但是强制使用 SSL，以及 SSL 是否就是解决 Web 安全性问题的正确选择，在 IETF/W3C 仍然受到广泛的质疑。笔者认为在可预期的未来，强制使用 SSL 不可能成为 HTTP 协议的一部分。

各位读者朋友，您又是如何看待 SPDY 协议的呢？

注 1：“分层系统”是 REST 所要满足的一个架构约束，常见的分层系统有分层的缓存、分层的代理服务器、分层的防火墙等等。

注 2：就是一些标准头信息的语法。

注 3：考虑一下恐怖分子在这些区域散布恐怖信息。

作者李锟，网名 dlee，知名技术专家，出版过《REST 实战》、《Ajax 实战》等多部译作。

感谢丁雪丰对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。