1、争夺未来的互联网互联网接入速度一再提升，但是在带宽提升到数十兆甚至上百兆之后，很多用户发现，他们除了需要掏更多的钱之外，网站的加载速度并没有比几兆带宽时快多少。同样，电脑硬件的升级也无法让 Web 服务明显加快，这是因为我们的浏览器正通过一些早已不合时宜的互联网协议与服务器进行通信，这些落后的协议严重地影响了网页和 Web 服务的加载速度。这些互联网协议早期仅用于加载一些图形简单的 HTML 页面，而现如今的 Web 服务或者网页内容已经大不一样，一个网页中通常包含几百行的脚本代码，并且需要同时加载来自多个网站的各种元素。此外，为了确保通信的安全和隐私，很多时候 Web 服务器或者浏览器还需要
2、不断地进行加密与解密的操作。 最好的例子是 HTTP 协议，这是一个负责调控浏览器和服务器之间通信的核心应用协议。目前该协议的最新版本为 1.1 版，而这个所谓的最新版本只是在 1999 年进行了一些零星优化，该协议的主要缺点皆没有被修正，这样落后的一个网络协议，自然无法适应目前的网络应用环境，也无法充分利用带宽。 此外，使用 HTTP 1.1 协议处理通信数据的开销庞大，将产生许多不必要的数据流量。因而，负责互联网标准的开发和推动的互联网工程任务组（Internet Engineering Task Force，简称 IETF）自 2012 年以来，一直致力于改进这个互联网的主要协议。目前，
3、HTTP 2.0 已经基本准备就绪，IETF 希望能够在 2014 年年底开始正式实施它，而相关的草案已于2013 年 8 月开始进行测试。 对于 HTTP 2.0 的竞争提案 2012 年，Google 和微软分别提交了自己的 HTTP 2.0 建议，Google开发的是早以闻名遐迩的 SPDY 协议，微软与之竞争的则是 HTTP Speed+Mobility，两者之间的主要争议在于 HTTP 2.0 是否应该完全采用加密的形式。目前，虽然 SPDY 已经被接受成为 HTTP 2.0 的基础，但是IETF 免除了 SPDY 强制性加密的规定，因为加密将增加设备的运算负担，而对于移动设备来说，
4、这意味着续航时间大受影响。另外，这还将要求所有的网站都要安装加密证书，对于小型网站来说，加密证书的费用是一个不小的负担。 就在 HTTP 2.0 整装待发之时，爱德华斯诺登披露的消息影响了该标准的发布计划。2013 年 9 月初，所有人都清楚地了解到美国国家安全局等情报机构的所作所为，而更令人震惊的是他们竟然还可以拦截和窃取 HTTPS 的加密数据。加密专家布鲁斯施奈尔认为，实际上美国政府已经背叛了互联网。因而，HTTP 2.0 的安全问题成了人们关注的焦点，IETF 必须根据斯诺登披露的信息重新评估该协议的安全性，并收集更多关于如何完善 HTTP 2.0 的加密功能以确保 HTTP 2.0
5、协议安全性的建议。国家安全局的后门 现有的 HTTPS 加密是利用 SSL 和 TLS 协议来建立安全连接，这种非对称加密包含一个公共和一个私有密钥。首先，服务器发送一个经过认证的公共密钥到浏览器，浏览器将检查认证证书的有效性，并使用服务器的密钥将用于接下来加密通信数据的会话密钥加密发送到服务器，服务器将使用与其公共密钥对应的私钥来提取会话密钥，并开始使用会话密钥加密通信数据。接下来，服务器和浏览器之间就可以使用相同的会话密钥来加密通信以做进一步的沟通。 然而，美国国家安全局之类的情报机构可以截取全部的通信数据，并利用其权威或者其他的手段获取服务器的私钥，例如通过法庭的命令或者通过黑客手段，在
6、拥有服务器私钥的情况下，所有的数据都将是透明的。因此，有人建议在 HTTP 2.0 中部署不同的密钥生成方法，正在开发中的 TLS1.3 加密协议将使用不需要交换密钥的完全转发保密（Perfect Forward Secrecy，简称 PFS）技术。服务器和浏览器之间通过密码系统产生一个对称密钥用于加密接下来的通信数据，密钥将在会话结束之后被删除。 不过，要确保 PFS 的安全，首先要求用于生成密钥的加密方法必须是安全的。很多人怀疑，过去美国国家安全局一直积极致力于参与加密方法的研发是别有用心的，因为选择一个掌握在自己手上的加密方法不难设置后门让自己可以通行无阻。众所周知，双椭圆曲线确定性随机
7、比特生成器（dual elliptic curve deterministic random bit generator，缩写 Dual_EC_DRBG）是如何被植入后门的。因而，目前所有由美国国家标准技术研究所（National Institute of Standards and Technology，简称 NIST）发布的曲线都是受到质疑的，因而，由西蒙约瑟夫松提交给 IETF 的一个名为 25519 的椭圆曲线，由于不是来自NIST，所以将有可能用于 TLS 1.3。这样一来，TLS 1.3 应该可以关上NSA 的后门。 不过，光有一个新的 TLS 加密协议是不够的，因为人们也同样怀疑
8、用于 HTTPS 的 RC4 加密方法中包含 NAS 留下的一个漏洞。RC4 是 TLS 加密协议的一部分，根据相关的研究显示，目前 Web 加密数据中约有 50%使用此加密方法，因而，对于了解该漏洞的人来说，他们当然不会在 TLS 1.3中选择使用 RC4 加密方法。遗憾的是，目前的 Web 安全应用中具体使用什么安全协议是由服务器决定的，尽管 Chrome 和 IE 浏览器的最新版本都已经支持当前最新的 TLS 1.2，但是大多数 Web 服务器仍然在使用过时的 SSL 3.0 和 TLS 1.0，用户也只能被迫使用这些过时的安全协议，而这些协议存在可以被黑客利用的漏洞已经是公开的秘密。H
9、TTP 2.0 方案有可能要扭转这一局面，也就是说，未来由浏览器来确定应该使用哪一个安全协议，用户可以指定使用什么样的加密方法来保护 HTTPS 连接。 修补 SSL、TLS 中的安全漏洞 当前，SSL、TLS 的数据包有可能被截取和操纵，黑客可以对SSL、TLS 通信进行有效的攻击。通信过程中的每一个数据包中包含起核心作用的消息认证码（Message Authentication Code，简称 MAC） ，MAC由会话密钥和传送的数据产生，接收者可以通过 MAC 确定收到的数据是否来自发送者，从而避免数据包被截取和操纵。但是目前使用的SSL、TLS 采用所谓“MAC then encryp
10、t”的方法进行处理，传输的是明文与明文的 MAC 值加密的结果，未加密的数据包内容被用于生成 MAC，这种方法早在 1999 年就已经被证实是不可靠的。为此，作为对策，TLS 的升级版本采用“Encrypt then MAC”的处理方法，这种方法传输的是密文与密文的 MAC 值，黑客很难有所作为。当然，仍然无法确定这些方法是否已经足以防止情报机构的嗅探，但是这起码修补了已知的安全漏洞。而对于互联网工程任务组来说，HTTP 2.0 是否应该完全采用加密的形式，这一最具争议的话题仍然会再出现在议程上。 去除性能缺陷 IETF 成员同时需要考虑的问题是新的技术标准如何消除 HTTP 1.1 的性能缺
11、陷。目前，解决这一问题的基础是 Google 的 SPDY 协议，该协议将可以解决 HTTP 1.1 的结构性缺陷，而 Chrome、IE、Firefox 和 Opera这些浏览器的最新版本都已经支持该协议，仅有苹果公司的 Safari 浏览器暂时未能支持。 在 HTTP 1.1 协议中，服务器需要为网页中的每个元素建立一个单独的 TCP 连接，因此需要启动多个并行连接，这将导致产生不必要的数据流量，并且很容易出现线头阻塞（Head of Line Blocking，HOL） ，影响数据包的处理速度。因为数据包的处理总是按照既有的顺序进行，而不论该请求是否出现问题或处理的时间是否太长。此外，H
12、TTP 连接是由客户建立的，浏览器必须不断地查询网站以了解内容是否发生了变化，而服务器本身不会自动发送更新内容。 一个 HTTP 2.0 连接一旦被建立，那么它将在浏览器和服务器之间打开数据流通道来发送它们的数据包，数据可以在同一时间并行进行传输。与 HTTP 1.1 相比，HTTP 2.0 实现了单个 TCP 连接的并行处理，这意味着服务器不再需要应付大量的浏览器查询，所以可以大幅度减轻服务器的负荷。而且，数据帧标有优先顺序，解码时浏览器或服务器可以相应地调整顺序，彻底地避免线头阻塞的问题。此外，HTTP 2.0 中服务器还可以将信息发送到浏览器，同时数据包报头也得到了优化。在 HTTP 1
13、.1 中数据包报头以未经压缩的文本形式传输，这使得报头过大，同时在处理之前还需要转换成二进制码。而 HTTP 2.0 将报头压缩，以二进制代码来发送它们，这除了减少了数据量之外，也减少了处理的等待时间（响应时间） 。 HTTP 1.1 和 TCP 在许多方面是相关联的，以并行处理的问题为例，HTTP 1.1 中实际上是通过 TCP 协议来提供 HTTP 中缺少的功能，但是 TCP为了完成这一功能必须建立大量的连接，还需要负责确定数据的序列并完成数据传输过程中的检测和修复等工作，而这些工作都将产生一定的延迟。对于 TCP 连接来说，仅建立连接的过程中 3 个阶段的握手就已经增加了不少延迟。 而
14、HTTP 2.0 中很多工作不再需要 TCP 协议来承担，或者更确切地说，HTTP 2.0 将接管这些任务，例如数据帧的优先级设定将确定数据包如何进行处理，不再需要 TCP 确定数据包的序列。因此，Google 甚至建议使用基于更快但不那么可靠的用户数据报协议（User Datagram Protocol，简称 UDP）作为 HTTP 2.0 的传输协议。Google 的快速 UDP 互联网连接（Quick UDP Internet Connections，简称 QUIC）正是基于UDP 的，只是加入了纠正错误的机制。使用 QUIC 作为传输协议的话，TCP的错误检测等操作将不再是必要的了，T
15、CP 最为尴尬的 3 次握手产生的延迟也将不会再是问题，因为 HTTP 2.0 建立的是服务器与浏览器之间相互通信的数据流。从长远来看，Google 并不打算取代 TCP，而是希望将QUIC 融入到 TCP 中。我们可以预期从 HTTP 1.1 到 HTTP 2.0 的切换是非常顺利的，用户需要做的只是更新浏览器以支持 HTTP 2.0，在浏览器支持 HTTP 2.0 的情况下将自动向服务器发出请求，并开启一个焕然一新的互联网。 HTTP 2.0 路线图 历经 15 年，互联网工程任务组（IETF）终于计划升级作为互联网核心的 HTTP 协议，按照 IETF 的计划，要在 2014 年年底前完成新标准的制定。
