英文原文：HTTP/2 Frequently Asked Questions

常见问题

为什么修订HTTP？

HTTP/1.1已经很好的服务Web超过15个年头，但它的劣势开始显现。

载入一个Web页面比之前占用更多的资源（详情可见HTTP压缩页大小统计），有效的载入这些资源很难，因为HTTP实际上对每个TCP连接，只允许一个优先的请求。

在过去，对于并发请求，浏览器使用多个TCP连接。然而，这也是有局限的；如果使用了过多的连接，这既是一种计数上的高产（TCP阻塞控制是被有效否定的，导致阻塞事件影响性能和网络），也基本上是不公平的（因为浏览器承受的资源大于它们享有的网络资源）。

同时，大量的请求意味着“线上”有很多重复的数据。

HTTP/1.1耗费大量的开销是与这两个因素有关。如果发生过多的请求，会影响性能。

这些导致了相关行业成为了像雪碧、数据内联、域共享和级联的最佳练习场地。这些问题被认为是底层协议自身的问题，并导致在使用它们时产生了一系列的问题。

谁正在做这件事？

IETF的HTTPbis工作组正在开发HTTP/2，他们负责维护HTTP协议。是由若干HTTP实现者、用户、网络运营商和HTTP专家组成。

注意虽然工作组的邮件列表是托管在W3C网站上，不过却不是W3C的功劳。但是， Tim Berners-Lee 和 W3C TAG与WG的进程保持了一致。

大量的人对相关工作作出了共享，不过大部分活跃参与者是来自像Firefox、Chrome、Twitter、Microsoft的HTTP栈、Curl和Akamai这样大项目的工程师，以及若干Python、Ruby和NodeJS的HTTP实现者。

要了解更多IETF参与者，请看IETF之道。你也可以在Github的贡献者图表中了解到哪些人正在对规范做贡献，在我们的实现者列表了解哪些人正在参与实施。

和SPDY是怎样的关系？

HTTP/2 第一次出现并被讨论的时候， SPDY 正得到厂商 (像 Mozilla 和 nginx)的青睐和支持, 并被看成是HTTP/1.x 基础上的重大改善.

经过建议和投票之后, SPDY/2 被列为HTTP/2 的基础.从那时起, 根据工作组的讨论和厂商的反馈，它已经有了很多变化。

在整个过程中,SPDY 的核心开发成员都参与了HTTP/2 的发展, 其中也包括 Mike Belshe 和 Roberto Peon. 事实上,已经发布的 SPDY/4 revision 正是基于 HTTP/2的 ,因为SPDY社区现在发现它是作为一种进一步实验反馈到 HTTP/x的工具, 而不是竞争对手.

是 HTTP/2.0 还是 HTTP/2?

工作组决定去掉小版本 (“.0”) 因为这在HTTP/1.x中导致了很多困惑.

也就是说, HTTP 的版本仅代表它的兼容性,不表示它的特性和 “亮点”

和HTTP/1.x的关键区别是什么?

在高版本 HTTP/2中:

• 是二进制的，代替原有的文本

• 是多路复用的, 代替原来的序列和阻塞机制

• 所以可以在一个连接中并行处理

• 压缩头部信息减小开销

• 允许服务器主动推送应答到客户端的缓存中

HTTP/2为什么是二进制的？

比起像HTTP/1.x这样的文本协议，二进制协议解析起来更高效、“线上”更紧凑，更重要的是错误更少。因为它们对如空白字符的处理、大小写、行尾、空链接等的处理很有帮助。

例如，HTTP/1.1定义了四个不同的方法来解析一条消息；在HTTP/2中，仅需一个代码路径即可。

HTTP/2在telnet中将不可用，但是我们有一些工作提供支持，比如Wireshark plugin。

为什么 HTTP/2 需要多路传输?

HTTP/1.x 有个问题叫线端阻塞(head-of-line blocking),  它是指一个连接(connection)一次只提交一个请求的效率比较高, 多了就会变慢.

HTTP/1.1 试过用流水线(pipelining)来解决这个问题, 但是效果并不理想(数据量较大或者速度较慢的响应, 会阻碍排在他后面的请求). 此外, 由于网络媒介(intermediary )和服务器不能很好的支持流水线, 导致部署起来困难重重. 

客户端使用一些启发式的方法(基本靠猜) 来决定通过哪些连接提交哪些请求; 由于一个页面加载的数据量, 往往比可用连接能处理的数据量的10倍还多, 对性能产生极大的负面影响, 结果经常引起瀑布式阻塞(waterfall of blocked requests).

而多路传输(Multiplexing)能很好的解决这些问题, 因为它能同时处理多个消息的请求和响应; 甚至可以在传输过程中将一个消息跟另外一个掺杂在一起.

所以客户端只需要一个连接就能加载一个页面

为什么只要一个 TCP 连接?

目前的浏览器, 每个点 (origin) 打开 4 到 8 个连接(Connection). 而很多网站都支持多点传输(multiple origins), 也就是说, 光加载一个网页, 打开的连接数量就超过 30 个. 

一个应用同时打开这么多连接, 已经远远超出了当初设计 TCP 时的预期; 每一个连接接收过多的数据, 又存在网络缓存溢出的风险, 结果导致网络堵塞和数据重传.

此外, 使用这么多连接还会强占许多网络资源. 这些资源都是从别人那 “偷” 来的. 你说这些应用够遵纪守法吧? ( VoIP 就是个很好的例子).

服务器推送的好处是什么？

当浏览器请求一个网页时，服务器将会发回HTML，在服务器开始发送JavaScript、图片和CSS前，服务器需要等待浏览器解析HTML和发送所有内嵌资源的请求。

服务器推送服务通过“推送”那些它认为客户端将会需要的内容到客户端的缓存中，以此来避免往返的延迟。

消息头为什么需要压缩?

来自Mozilla的Patrick McManus通过计算消息头对平均页面负载的印象，对此进行了形象且充分的说明.

假定一个页面有80个资源需要加载（这个数量对于今天的Web而言还是挺保守的）, 而每一次请求都有1400字节的消息头（着同样也并不少见，因为Cookie和引用等东西的存在）, 至少要7到8个来回去“在线”获得这些消息头。这还不包括响应时间——那只是从客户端那里获取到它们所花的时间而已.

这全都由于TCP的慢启动机制，它会基于对已知有多少个包，来确定还要来回去获取哪些包 – 这很明显的限制了最初的几个来回可以发送的数据包的数量.

相比之下，即使是头部轻微的压缩也可以是让那些请求只需一个来回就能搞定——有时候甚至一个包就可以了。

这种开销是可以被节省下来的，特别是当你考虑移动客户端应用的时候，即使是良好条件下，一般也会看到几百毫秒的来回延迟。

本文中的所有译文仅用于学习和交流目的，转载请务必注明文章译者、出处、和本文链接。 2KB翻译工作遵照 CC 协议，如果我们的工作有侵犯到您的权益，请及时联系我们。

2KB项目（www.2kb.com，源码交易平台）,提供担保交易、源码交易、虚拟商品、在家创业、在线创业、任务交易、网站设计、软件设计、网络兼职、站长交易、域名交易、链接买卖、网站交易、广告买卖、站长培训、建站美工等服务