Google与微软想要改进HTTP

   <p> Google 与微软想要通过 SPDY 与 Speed+Mobility 改进 HTTP。本文将会介绍这两个提案并指出他们对广为使用的 Internet 协议带来了哪些好处。</p>    <p> 目前，<a>Internet 工程任务组</a>（IETF）与 <a href="/misc/goto?guid=4958346892428604543">W3C</a> 正在网络路由、传输与安全等问题上紧密合作，包括 1999 年由 Roy Fielding 与T. Berners-Lee 等人联合签名的关于 HTTP 1.1 的 <a href="/misc/goto?guid=4958346893219778865">RFC 2616</a>规范提案。自从上一个 HTTP 版本发布以来已经过去了 12 年多的时间，一些人已经开始注意到这个广为使用的 Internet 协议需要进行增强以面对时代的需要。目前，针对 HTTP 2.0 已经有<a href="/misc/goto?guid=4958346894012734377">多份提案</a>被提交到了 IETF，这其中包括 <a href="/misc/goto?guid=4958346894809974127">Google SPDY</a> 与微软的 <a href="/misc/goto?guid=4958346895616148547">HTTP Speed+Mobility</a>。这两个提案都向后兼容于前一个版本的协议，旨在构建在现有的基础设施之上。</p>    <p> Google 想要重点解决现有 HTTP 1.1 的速度问题：</p>    <blockquote>    HTTP 实现的一个瓶颈在于 HTTP 需要通过多个连接来解决并发问题。这会导致一些问题，比如说为了建立连接所需的额外的往返过程、慢启动的延迟以及客户端的连接配额，这是由于客户端会防止对任何一个服务器打开过多的连接。   </blockquote>    <p> 出于以上原因，SPDY 旨在：</p>    <blockquote>    在一个单独的 TCP 连接（或是任何可靠的传输流）之上增加一个 Framing Layer 以实现多个并发的流。Framing Layer 会针对类似于 HTTP 请求响应的流进行优化，比如说现在运行在 HTTP 之上的应用也可以运行在 SPDY 之上，对于 Web 应用来说只需做很少的修改或是无需修改。   </blockquote>    <p> 实际上，SPDY 对 HTTP 1.1 进行了 4 个主要的改进，分别是多路请求、对请求划分优先级、压缩头以及服务器的流推送。虽然目前 SPDY 还仅仅是个提案，但它已经被实现出来并形成了产品。Google 在其很多服务与 Chrome 中都使用到了 SPDY。<a href="/misc/goto?guid=4958346896434861837">其他的实现</a>还有 Apache SPDY 模块、用于 node.js 的 SPDY 服务器、Netty、Firefox 与 Amazon Silk，Ngnix 很快也会跟进。</p>    <p> 微软针对 HTTP 2.0 提出的<a href="/misc/goto?guid=4958346895616148547">规范</a>将重点放在了速度问题与移动上，该提案从 SPDY 开始到 WebSockets 结束。在之前与 InfoQ 的一封邮件交流中，来自于微软开放技术的高级程序经理及微软提案的签署者 Adalberto Foresti 提到“SPDY 做的非常漂亮，它让人们认识到了 Web 性能问题并采取了全新的方式改进 HTTP 以让 Web 变得更快”。微软的提案改进了 SPDY，这是通过简化”会话控制消息以删除对于 WebSockets 控制帧来说冗余的条目来实现的，但与现有的 HTTP 语义并不兼容，或是实现一些在传输层上的重要概念”。</p>    <p> 微软的 HTTP Speed+Mobility 还增加了两节内容，旨在改进“物联网”上对于 HTTP 的使用，考虑到了 CPU 消耗、设备电池与资源、安全等问题。名为“Client is in control of content”的1.1.4节中提到：</p>    <blockquote>    考虑到 Internet 上各种各样的客户端以及连接数场景，客户端是定义下载什么内容的最佳场所。浏览器或是应用有关于用户当前正在做什么以及哪些数据在本地存在的第一手信息。比如说，目前使用的大多数浏览器都拥有强大的缓存，我们应该使用他们来存储不经常变化的 Web 元素。    <p>HTTP 2.0 提案不应该强制浏览器或是应用下载没有请求的或是已经被缓存的内容。此外，客户端要有拒绝不想要或是不需要内容的权利。客户端要能通知服务端自己已经拥有了已经缓存，不需要下载的元素。在理想情况下，这种来自于客户端，发向服务端的反馈应该考虑到内容的增量审批，这样才会形成一个高效的“推送”扩展以通过适当的安全性与正确的格式递送正确的内容。</p>    </blockquote>    <p> 在名为“Network Cost and Power”的1.1.5节中，作者重点谈到了电源与带宽使用问题：</p>    <blockquote>    速度、消耗与电源之间的抉择并不是一个简单的问题。有时，速度可能是最需要考虑的事情。但有时，带宽消耗或是电池寿命可能是决定因素。HTTP 2.0 必须要能使开发者针对其具体的问题域约束进行优化（约束可能会随着时间的流逝而发生变化）而不是对通用问题给出一个统一的解决方案。    <p>我们需要对更快的速度、更少的消耗、更低的电源使用量进行均衡处理。比如说，在网线上传递更少的数据会使页面的加载速度更快，更省电以及占用更少的带宽。但考虑到 HTTP 2.0 的使用场景千差万别，事实并不总是如此。比如说，对于一个电池即将耗尽或是缓存即将占满的设备来说，如果在保留 HTTP 2.0 中其他优化的同时能够禁用掉服务端推送更新将会提供更好的用户体验。因此，工作组需要同时考虑电源、消耗与速度问题。</p>    </blockquote>    <p> 为了解决方才提到的问题，微软提出通过 WebSocket 升级来实现会话握手、保持与 Framing，规范包含了用户希望看到的一些底层细节信息。</p>    <p> 微软已经在今年 3 月举办的 <a href="/misc/goto?guid=4958346897961633154">IETF 83</a>大会上提交了其提案。他们还实现了一个开源的概念验证<a href="/misc/goto?guid=4958346898755880315">原型</a>，可以让开发者评估 HTTP Speed+Mobility 提案，项目<a href="/misc/goto?guid=4958346899550132919">代码</a>位于 GitHub 上。</p>    <p> 至于业界会选择哪一个来实现还不明朗。根据 <a href="/misc/goto?guid=4958346900339614693">IETF 标准进程</a>，“规范要经历一个开发期、经过 Internet 社区的几轮审查并根据体验进行修订、然后被恰当的组织采纳为标准、最后发布”。</p>    <p> 相关资源：<a href="/misc/goto?guid=4958346901145164741">HTTPbis 工作组开始考虑 HTTP/2.0</a></p>    <p> <strong>查看英文原文：</strong><a href="/misc/goto?guid=4958346901937551814">Google and Microsoft Want to Improve HTTP</a></p>