这些是有关HTTP / 2的常见问题。
- 一般的问题
- 为什么要修改HTTP？
- 谁制作了HTTP / 2？
- 与SPDY有什么关系？
- 是HTTP / 2.0还是HTTP / 2？
- HTTP / 1.x的主要区别是什么？
- 为什么是HTTP / 2二进制文件？
- 为什么要对HTTP / 2进行多路复用？
- 为什么只有一个TCP连接？
- 服务器推送的好处是什么？
- 为什么我们需要头压缩？
- 为什么选择HPACK？
- HTTP / 2可以使Cookie（或其他标头）更好吗？
- 非浏览器的HTTP用户呢？
- HTTP / 2是否需要加密？
- HTTP / 2如何提高安全性？
- 我现在可以使用HTTP / 2吗？
- HTTP / 2会取代HTTP / 1.x吗？
- 会有HTTP / 3吗？
- 实施问题
- 部署问题
一般的问题
为什么要修改HTTP？
HTTP / 1.1在Web上已经服务了15多年，但是它的年龄正在开始显现。
加载网页比以往任何时候都需要更多资源（请参阅HTTP存档的页面大小统计信息），并且要高效地加载所有这些资产非常困难，因为HTTP实际上每个TCP连接只允许一个未完成的请求。
过去，浏览器使用多个TCP连接来发出并行请求。但是，这是有局限性的。如果使用的连接过多，则会适得其反（TCP拥塞控制被有效地取消，导致拥塞事件损害性能和网络），并且从根本上讲是不公平的（因为浏览器占用的资源超过了其网络资源的份额）。
同时，大量请求意味着“在线”上有大量重复数据。
这两个因素都意味着HTTP / 1.1请求具有与之相关的大量开销。如果提出过多的请求，则会影响性能。
这使该行业进入了一种被认为是“最佳实践”的地方，可以进行诸如拼写，数据：内联，域分片和连接之类的事情。这些黑客行为表明协议本身存在潜在问题，使用时会自行引发许多问题。
谁制作了HTTP / 2？
HTTP / 2是由IETF的HTTP工作组开发的，该工作组维护HTTP协议。它由许多HTTP实施者，用户，网络运营商和HTTP专家组成。
请注意，虽然我们的邮件列表托管在W3C网站上，但这不是W3C的努力。但是，Tim Berners-Lee和W3C TAG与WG的工作保持同步。
大量的人为这项工作做出了贡献，但是最活跃的参与者包括Firefox，Chrome，Twitter，Microsoft的HTTP堆栈，Curl和Akamai等“大型”项目的工程师，以及Python等语言的HTTP实现者，Ruby和NodeJS。
要了解有关参加IETF的更多信息，请参见IETF的Tao。您还可以在Github的贡献者图中了解谁为规范做出了贡献，以及谁在我们的实现列表中实现。
与SPDY有什么关系？
当SPDY逐渐受到实现者（例如Mozilla和nginx）的青睐时，首次讨论了HTTP / 2，并显示出对HTTP / 1.x的重大改进。
在征求建议书和进行选择过程之后，选择SPDY / 2作为HTTP / 2的基础。此后，根据工作组的讨论和实施者的反馈，进行了许多更改。
在整个过程中，SPDY的核心开发人员都参与了HTTP / 2的开发，包括Mike Belshe和Roberto Peon。
2015年2月，Google宣布了计划删除对SPDY的支持，而改为使用HTTP / 2。
是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中，只有一个代码路径。
确实不能通过telnet使用HTTP / 2，但是我们已经有了一些工具支持，例如Wireshark插件。
为什么要对HTTP / 2进行多路复用？
HTTP / 1.x存在一个称为“行头阻止”的问题，其中实际上一次只能在一个连接上处理一个请求。
HTTP / 1.1尝试通过流水线修复此问题，但并不能完全解决问题（较大或较慢的响应仍可能阻止其他问题在后）。此外，由于许多中介和服务器未正确处理管道，因此发现管道部署非常困难。
这迫使客户使用多种试探法（通常是猜测法）来确定什么请求在什么时候对原点进行哪个连接；由于页面通常加载可用连接数的10倍（或更多），因此这可能严重影响性能，通常导致被阻止请求的“瀑布”。
复用通过允许同时发送多个请求和响应消息来解决这些问题。甚至有可能将一条消息的一部分与另一条消息混合在一起。
反过来，这允许客户端在每个起点仅使用一个连接来加载页面。
为什么只有一个TCP连接？
使用HTTP / 1，浏览器在每个来源之间打开四个到八个连接。由于许多站点使用多个来源，因此这可能意味着单个页面加载会打开三十多个连接。
一个应用程序打开如此多的连接会同时打破许多建立TCP的假设。由于每个连接都会在响应中引发大量数据，因此存在中间网络中的缓冲区真正溢出的真正风险，从而导致拥塞事件并重新传输。
此外，使用如此多的连接会不公平地垄断网络资源，将它们从其他性能更好的应用程序（例如VoIP）“窃取”。
服务器推送的好处是什么？
当浏览器请求页面时，服务器会在响应中发送HTML，然后需要等待浏览器解析HTML并发出对所有嵌入式资产的请求，然后才能开始发送JavaScript，图像和CSS。
服务器推送可以通过“推送”它认为客户端将需要的响应到其缓存中来潜在地使服务器避免这种往返延迟。
但是，“推送”响应不是“神奇的” –如果使用不正确，可能会损害性能。正确使用Server Push是正在进行的实验和研究领域。
为什么我们需要头压缩？
Mozilla的Patrick McManus通过计算平均页面加载量的标题效果生动地展示了这一点。
如果您假设一个页面包含大约80个资产（在当今的Web中是保守的），并且每个请求具有1400字节的标头（再次，这并不罕见，这要归功于Cookie，Referer等），它至少需要7-8往返以使标头“在线”显示。这不包括响应时间-只是使它们脱离客户端。
这是因为TCP的慢启动机制，该机制根据已确认的数据包数量在新连接上加快数据包的发送速度-有效地限制了前几次往返可发送的数据包数量。
相比之下，即使对报头进行适度的压缩，这些请求也可以在一次往返（甚至一个数据包）内进入网络。
这种开销是相当大的，尤其是考虑到对移动客户端的影响时，即使在良好条件下，移动客户端的往返延迟通常也要几百毫秒。
为什么选择HPACK？
SPDY / 2建议在每个方向上使用单个GZIP上下文进行标头压缩，该方法易于实现且效率很高。
从那时起，针对加密内部使用流压缩（例如GZIP）的重大攻击已得到记录。犯罪。
使用CRIME，有能力将数据注入加密流中的攻击者可以“探测”明文并恢复它。由于这是Web，因此JavaScript使这成为可能，并且演示了使用CRIME来为TLS保护的HTTP资源恢复cookie和身份验证令牌。
结果，我们无法使用GZIP压缩。没有找到适合该用例并且可以安全使用的其他算法，我们创建了一种新的，特定于报头的压缩方案，该方案以粗粒度运行；由于HTTP标头通常在消息之间不更改，因此仍然可以提供合理的压缩效率，并且更加安全。
HTTP / 2可以使Cookie（或其他标头）更好吗？
这项工作被安排用于修订有线协议，即，如何将HTTP标头，方法等“置于网络上”，而不改变HTTP的语义。
这是因为HTTP被广泛使用。如果我们使用此版本的HTTP引入一种新的状态机制（已经讨论过一个示例）或更改了核心方法（很幸运，尚未提出该提议），则意味着新协议与现有Web不兼容。 。
特别是，我们希望能够在不丢失任何信息的情况下从HTTP / 1转换为HTTP / 2。如果我们开始“清理”头文件（大多数人会同意HTTP头文件很乱），我们将与许多现有的Web发生互操作性问题。
这样做只会导致反对采用新协议。
综上所述，HTTP工作组负责所有HTTP，而不仅仅是HTTP / 2。这样，我们可以开发与版本无关的新机制，只要它们与现有Web向后兼容即可。
非浏览器的HTTP用户呢？
如果非浏览器应用程序已经在使用HTTP，则它们也应该能够使用HTTP / 2。
早期的反馈是HTTP / 2具有HTTP“ API”的良好性能特征，因为API不需要在设计中考虑诸如请求开销之类的问题。
话虽如此，我们正在考虑的改进的主要焦点是典型的浏览用例，因为这是该协议的核心用例。
我们的章程对此表示：
The resulting specification(s) are expected to meet these goals for common
existing deployments of HTTP; in particular, Web browsing (desktop and
mobile), non-browsers ("HTTP APIs"), Web serving (at a variety of scales), and
intermediation (by proxies, corporate firewalls, "reverse" proxies and Content
Delivery Networks). Likewise, current and future semantic extensions to
HTTP/1.x (e.g., headers, methods, status codes, cache directives) should be
supported in the new protocol.
Note that this does not include uses of HTTP where non-specified behaviours
are relied upon (e.g., connection state such as timeouts or client affinity,
and "interception" proxies); these uses may or may not be enabled by the final
product.
HTTP / 2是否需要加密？
否。经过广泛讨论，工作组尚未达成共识，要求对新协议使用加密（例如TLS）。
但是，一些实现已声明，仅当通过加密连接使用HTTP / 2时，它们才会支持HTTP / 2，并且当前没有浏览器支持未加密的HTTP / 2。
HTTP / 2如何提高安全性？
HTTP / 2定义了必需的TLS配置文件；这包括版本，密码套件黑名单和使用的扩展名。
有关详细信息，请参见规格。
还讨论了其他机制，例如对HTTP：// URL使用TLS（所谓的“机会加密”）；参见RFC 8164。
我现在可以使用HTTP / 2吗？
在浏览器中，Edge，Safari，Firefox和Chrome的最新版本支持HTTP / 2。其他基于Blink的浏览器也将支持HTTP / 2（例如Opera和Yandex Browser）。有关更多详细信息，请参见犬。
还有一些可用的服务器（包括Akamai，Google和Twitter的主要站点提供的beta支持），以及可以部署和测试的许多开源实现。
有关更多详细信息，请参见实现列表。
HTTP / 2会取代HTTP / 1.x吗？
工作组的目标是HTTP / 1.x的典型用法可以使用HTTP / 2并看到一些好处。话虽如此，我们不能强迫世界迁移，并且由于人们部署代理和服务器的方式，HTTP / 1.x可能仍会使用很长时间。
会有HTTP / 3吗？
如果HTTP / 2引入的协商机制运行良好，则应该有可能比过去更轻松地支持HTTP的新版本。
实施问题
为什么围绕HEADERS框架上的Continuation的规则？
存在连续性是因为单个值（例如Set-Cookie）可能超过16KiB-1，这意味着它无法放入单个帧中。已确定处理此问题的最不容易出错的方法是要求所有标头数据都以背对背帧的形式出现，这使得解码和缓冲区管理更加容易。
HPACK状态的最小或最大大小是多少？
接收器始终控制HPACK中使用的内存量，并且可以将其最小设置为零，最大值与SETTINGS帧中的最大可表示整数（当前为2 ^ 32-1）有关。
如何避免保持HPACK状态？
将SETTINGS帧设置状态大小（SETTINGS_HEADER_TABLE_SIZE）发送为零，然后发送所有流RST，直到接收到设置了ACK位的SETTINGS帧为止。
为什么只有一个压缩/流控制上下文？
简单。
最初的提议具有流组，它们将共享上下文，流控制等。虽然这将使代理受益（以及代理用户的经验），但这样做却增加了相当的复杂性。我们决定先从简单的事情开始，看看它有多痛苦，并在将来的协议修订版中解决该痛苦（如果有的话）。
为什么HPACK中有EOS符号？
HPACK的霍夫曼编码，出于CPU效率和安全性的考虑，将霍夫曼编码的字符串填充到下一个字节边界；对于任何特定的字符串，可能需要0-7位之间的填充。
如果考虑隔离霍夫曼解码，则任何比所需填充长的符号都可以工作；但是，HPACK的设计允许按字节比较霍夫曼编码的字符串。通过要求将EOS符号的位用于填充，我们确保用户可以对霍夫曼编码的字符串进行字节比较，以确定是否相等。反过来，这意味着可以解释许多标头，而无需对其进行霍夫曼解码。
是否可以在不实现HTTP / 1.1的情况下实现HTTP / 2？
是的，主要是。
对于TLS（h2）上的HTTP / 2 ，如果您未实现http1.1ALPN标识符，则无需支持任何HTTP / 1.1功能。
对于基于TCP（h2c）的HTTP / 2 ，您需要实施初始升级请求。
h2c-仅客户端将需要生成“ *”的OPTIONS请求或“ /”的HEAD请求，这些请求相当安全且易于构造。希望仅实现HTTP / 2的客户端将需要将没有101状态代码的HTTP / 1.1响应视为错误。
h2c-仅服务器可以接受包含“升级标头”字段和固定101响应的请求。没有h2c升级令牌的请求可以通过包含升级标头字段的505（不支持HTTP版本）状态代码拒绝。不希望处理HTTP / 1.1响应的服务器应在发送连接序言后立即拒绝带有REFUSED_STREAM错误代码的流1，以鼓励客户端通过升级的HTTP / 2连接重试请求。
第5.3.2节中的优先级示例不正确吗？
否。流B的权重为4，流C的权重为12。要确定这些流中的每一个接收的可用资源的比例，请将所有权重相加（16），然后将每个流的权重除以总权重。因此，流B获得四分之一的可用资源，流C获得四分之三的可用资源。因此，如规范所述，流B理想地接收分配给流C的资源的三分之一。
我的HTTP / 2连接是否需要TCP_NODELAY？
应该是。即使对于仅使用单个流下载大量数据的客户端实现，仍然需要一些数据包以相反的方向发送回去，以实现最大的传输速度。如果未设置TCP_NODELAY（仍允许Nagle算法），则传出数据包可能会保留一段时间，以便允许它们与后续数据包合并。
例如，在这样的数据包告诉对方有更多可用窗口发送数据的情况下，将其发送延迟数毫秒（或更长时间）可能会对高速连接产生严重影响。
部署问题
如果HTTP / 2已加密，如何调试？
有很多方法可以访问应用程序数据，但是最简单的方法是将NSS键盘记录与Wireshark插件（包含在最新开发版本中）结合使用。Firefox和Chrome均可使用。
如何使用HTTP / 2服务器推送？
HTTP / 2服务器推送允许服务器无需等待请求即可向客户端提供内容。这可以改善检索资源的时间，尤其是对于具有大带宽延迟产品的连接，其中网络往返时间包括花费在资源上的大部分时间。
推送基于请求内容而变化的资源可能是不明智的。当前，浏览器仅在其他情况下才使用推送请求，否则它们将发出匹配请求（请参阅RFC 7234的第4节）。
某些缓存不考虑所有请求标头字段中的变化，即使它们在Vary标头字段中列出也是如此。为了最大化接受推送的资源的可能性，最好避免内容协商。accept-encoding缓存广泛遵循基于标头字段的内容协商，但是可能无法很好地支持其他标头字段。