争夺未来的互联网

互联网接入速度一再提升，但是在带宽提升到数十兆甚至上百兆之后，很多用户发现，他们除了需要掏更多的钱之外，网站的加载速度并没有比几兆带宽时快多少。同样，电脑硬件的升级也无法让Web服务明显加快，这是因为我们的浏览器正通过一些早已不合时宜的互联网协议与服务器进行通信，这些落后的协议严重地影响了网页和Web服务的加载速度。这些互联网协议早期仅用于加载一些图形简单的HTML页面，而现如今的Web服务或者网页内容已经大不一样，一个网页中通常包含几百行的脚本代码，并且需要同时加载来自多个网站的各种元素。此外，为了确保通信的安全和隐私，很多时候Web服务器或者浏览器还需要不断地进行加密与解密的操作。

最好的例子是HTTP协议，这是一个负责调控浏览器和服务器之间通信的核心應用协议。目前该协议的最新版本为1.1版，而这个所谓的最新版本只是在1999年进行了一些零星优化，该协议的主要缺点皆没有被修正，这样落后的一个网络协议，自然无法适应目前的网络应用环境，也无法充分利用带宽。

此外，使用HTTP 1.1协议处理通信数据的开销庞大，将产生许多不必要的数据流量。因而，负责互联网标准的开发和推动的互联网工程任务组（Internet Engineering Task Force，简称IETF）自2012年以来，一直致力于改进这个互联网的主要协议。目前，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强制性加密的规定，因为加密将增加设备的运算负担，而对于移动设备来说，这意味着续航时间大受影响。另外，这还将要求所有的网站都要安装加密证书，对于小型网站来说，加密证书的费用是一个不小的负担。

就在HTTP 2.0整装待发之时，爱德华·斯诺登披露的消息影响了该标准的发布计划。2013年9月初，所有人都清楚地了解到美国国家安全局等情报机构的所作所为，而更令人震惊的是他们竟然还可以拦截和窃取HTTPS的加密数据。加密专家布鲁斯·施奈尔认为，实际上美国政府已经背叛了互联网。因而，HTTP 2.0的安全问题成了人们关注的焦点，IETF必须根据斯诺登披露的信息重新评估该协议的安全性，并收集更多关于如何完善HTTP 2.0的加密功能以确保HTTP 2.0协议安全性的建议。

国家安全局的后门

现有的HTTPS加密是利用SSL和TLS协议来建立安全连接，这种非对称加密包含一个公共和一个私有密钥。首先，服务器发送一个经过认证的公共密钥到浏览器，浏览器将检查认证证书的有效性，并使用服务器的密钥将用于接下来加密通信数据的会话密钥加密发送到服务器，服务器将使用与其公共密钥对应的私钥来提取会话密钥，并开始使用会话密钥加密通信数据。接下来，服务器和浏览器之间就可以使用相同的会话密钥来加密通信以做进一步的沟通。

然而，美国国家安全局之类的情报机构可以截取全部的通信数据，并利用其权威或者其他的手段获取服务器的私钥，例如通过法庭的命令或者通过黑客手段，在拥有服务器私钥的情况下，所有的数据都将是透明的。因此，有人建议在HTTP 2.0中部署不同的密钥生成方法，正在开发中的TLS1.3加密协议将使用不需要交换密钥的完全转发保密（Perfect Forward Secrecy，简称PFS）技术。服务器和浏览器之间通过密码系统产生一个对称密钥用于加密接下来的通信数据，密钥将在会话结束之后被删除。

不过，要确保PFS的安全，首先要求用于生成密钥的加密方法必须是安全的。很多人怀疑，过去美国国家安全局一直积极致力于参与加密方法的研发是别有用心的，因为选择一个掌握在自己手上的加密方法不难设置后门让自己可以通行无阻。众所周知，双椭圆曲线确定性随机比特生成器（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加密协议是不够的，因为人们也同样怀疑用于HTTPS的RC4加密方法中包含NAS留下的一个漏洞。RC4是TLS加密协议的一部分，根据相关的研究显示，目前Web加密数据中约有50%使用此加密方法，因而，对于了解该漏洞的人来说，他们当然不会在TLS 1.3中选择使用RC4加密方法。遗憾的是，目前的Web安全应用中具体使用什么安全协议是由服务器决定的，尽管Chrome和IE浏览器的最新版本都已经支持当前最新的TLS 1.2，但是大多数Web服务器仍然在使用过时的SSL 3.0和TLS 1.0，用户也只能被迫使用这些过时的安全协议，而这些协议存在可以被黑客利用的漏洞已经是公开的秘密。HTTP 2.0方案有可能要扭转这一局面，也就是说，未来由浏览器来确定应该使用哪一个安全协议，用户可以指定使用什么样的加密方法来保护HTTPS连接。

修补SSL、TLS中的安全漏洞

当前，SSL、TLS的数据包有可能被截取和操纵，黑客可以对SSL、TLS通信进行有效的攻击。通信过程中的每一个数据包中包含起核心作用的消息认证码（Message Authentication Code，简称MAC），MAC由会话密钥和传送的数据产生，接收者可以通过MAC确定收到的数据是否来自发送者，从而避免数据包被截取和操纵。但是目前使用的SSL、TLS采用所谓“MAC then encrypt”的方法进行处理，传输的是明文与明文的MAC值加密的结果，未加密的数据包内容被用于生成MAC，这种方法早在1999年就已经被证实是不可靠的。为此，作为对策，TLS的升级版本采用“Encrypt then MAC”的处理方法，这种方法传输的是密文与密文的MAC值，黑客很难有所作为。当然，仍然无法确定这些方法是否已经足以防止情报机构的嗅探，但是这起码修补了已知的安全漏洞。而对于互联网工程任务组来说，HTTP 2.0是否应该完全采用加密的形式，这一最具争议的话题仍然会再出现在议程上。

去除性能缺陷

IETF成员同时需要考虑的问题是新的技术标准如何消除HTTP 1.1的性能缺陷。目前，解决这一问题的基础是Google的SPDY协议，该协议将可以解决HTTP 1.1的结构性缺陷，而Chrome、IE、Firefox和Opera这些浏览器的最新版本都已经支持该协议，仅有苹果公司的Safari浏览器暂时未能支持。

在HTTP 1.1协议中，服务器需要为网页中的每个元素建立一个单独的TCP连接，因此需要启动多个并行连接，这将导致产生不必要的数据流量，并且很容易出现线头阻塞（Head of Line Blocking，HOL），影响数据包的处理速度。因为数据包的处理总是按照既有的顺序进行，而不论该请求是否出现问题或处理的时间是否太长。此外，HTTP连接是由客户建立的，浏览器必须不断地查询网站以了解内容是否发生了变化，而服务器本身不会自动发送更新内容。

一个HTTP 2.0连接一旦被建立，那么它將在浏览器和服务器之间打开数据流通道来发送它们的数据包，数据可以在同一时间并行进行传输。与HTTP 1.1相比，HTTP 2.0实现了单个TCP连接的并行处理，这意味着服务器不再需要应付大量的浏览器查询，所以可以大幅度减轻服务器的负荷。而且，数据帧标有优先顺序，解码时浏览器或服务器可以相应地调整顺序，彻底地避免线头阻塞的问题。此外，HTTP 2.0中服务器还可以将信息发送到浏览器，同时数据包报头也得到了优化。在HTTP 1.1中数据包报头以未经压缩的文本形式传输，这使得报头过大，同时在处理之前还需要转换成二进制码。而HTTP 2.0将报头压缩，以二进制代码来发送它们，这除了减少了数据量之外，也减少了处理的等待时间（响应时间）。

HTTP 1.1和TCP在许多方面是相关联的，以并行处理的问题为例，HTTP 1.1中实际上是通过TCP协议来提供HTTP中缺少的功能，但是TCP为了完成这一功能必须建立大量的连接，还需要负责确定数据的序列并完成数据传输过程中的检测和修复等工作，而这些工作都将产生一定的延迟。对于TCP连接来说，仅建立连接的过程中3个阶段的握手就已经增加了不少延迟。

而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的错误检测等操作将不再是必要的了，TCP最为尴尬的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年年底前完成新标准的制定。