非浏览器用户的HTTP会是什么情况呢?
人们期望非浏览器应用程序也能够用上HTTP/2，如果它们曾今使用过HTTP的话。
早起收到针对HTTP的“API”，HTTP/2具有性能好等特点这样的反馈，是因为API的设计中不需要考虑像请求开销这样一些事情。
之前说过，我们所要考虑的主要的提升重点是在典型的浏览器用例下, 因为这是协议主要的使用场景。
我们的章程里面是这样说的:
正在组织的规范能满足现在已经普遍部署了的HTTP的功能要求;
具体的，（桌面端和移动端的）Web浏览，（“HTTP API”形式的）非浏览器, （大范围的）Web服务,
还有各种（借助代理，企业防火墙，反向代理以及内容分发网络实现的）中介。
同样的，对HTTP/1.x当前和未来的语义扩展 (例如，消息头，方法，状态码，缓存指令) 都应该在新的协议中支持。
注意，这里没有涵盖将HTTP用于非特定行为所依赖的（例如超时，连接状态以及拦截代理）场景中；
这些使用可能不会被最终的产品启用。
HTTP/2 需要加密吗？
不需要。在广泛的讨论后，工作组没有就新协议是否使用加密（如TLS）而达成共识。
不过，有些实现者说，只有HTTP/2使用加密链接他们才提供支持。
HTTP/2为提高安全性做了什么？
目前，HTTP/2定义了TLS的轮廓，包括版本、密码套件和用到的扩展。
细节参见相关规范。
也讨论了额外的机制，如对HTTP://URLs(所谓的“机会主义加密”)使用TLS；参见 issue #315。
现在可以用HTTP/2吗？
HTTP/2暂时在主流浏览器中还不可用，不过还是有一些体验版的可以用，或许在“每夜（nightly）”频道可以找到。
还是有几个服务器可用的（包括 Akamai 和 Twitter主流网站提供了测试服务器），以及几个开源版的，你可以用来部署和测试。
HTTP/2会代替HTTP/1.x
工作组的目的是让那些使用HTTP/1.x也可以使用HTTP/2，并能感受到HTTP/2所带来的好处。工作组说过，由于人们部署代理和服务器的方式的原因，我们不能强迫整个世界进行迁移，所以HTTP/1.x很可能仍要使用了一段时间。
HTTP/3 会出现么?
如果通过HTTP/2引入的沟通协作机制运行良好, 那就有可能比过去更加容易的支持新版本的HTTP.
实现中的问题
为什么规则会围绕消息头帧的数据接续?
数据接续的存在是由于一个值（例如cookie)可以超过 16kb, 这意味着它不可能全部装进一个帧里面. 所以就决定以最不容易出错的方式让所有的消息头数据以一个接一个帧的方式传递, 这样就使得对消息头的解码和缓冲区的管理更加的容易.
HPACK状态的最小和最大尺寸是多少 ?
接收一方总是会控制HPACK中内存的使用量, 并且最小能设置到0，最大则要看SETTING帧中能表示的最大整型数是多少，目前是 2^32 - 1.
我怎样才能避免保持 HPACK 状态?
发送一个 SETTINGS 帧将状态尺寸 (SETTINGS_HEADER_TABLE_SIZE) 设置到0, 然后 RST 所有的流，知道一个带有ACT设置位的 SETTINGS 帧发送了过来.
为什么会有一个单独的压缩/流控制上下文?
简洁.
原来的提案里面流分组这个概念，它可以共享上下文，流控制等等. 那样有利于代理 (也有利于经过它们的用户的体验),
而这样做相应也会增加一点复杂度.
所以我们就决定先以一个简单的东西开头，看看它会有多糟糕的问题，并且在未来的协议版本中解决这些问题（如果有的话）.
在HPACK中为什么会有EOS符号？
由于CPU效率和安全的原因，HPACK的霍夫曼编码填充了霍夫曼编码字符串的下一个字节边界。因此对于任何特定的字符串可能需要0-7个比特的填充。
如果单独考虑霍夫曼解码，任何比所需要的填充长的符号都可以正常工作。但是，HPACK的设计允许按字节对比霍夫曼编码的字符串。通过填充EOS符
号需要的比特，我们确保用户在做霍夫曼编码字符串字节级比较时是相等的。反之，许多 headers 可以在不需要霍夫曼解码的情况下被解析。
实现 HTTP/2 的时候我可以不用去实现 HTTP/1.1 么?
可以，完全可以.
对于运行在 TLS (h2) 之上的 HTTP/2 而言, 如果你没有实现 http1.1 的 ALPN 标识, 那你就就准备不需要支持任何 HTTP/1.1 特性的.
对于运行在 TCP (h2c) 之上的HTTP/2 而言, 你需要实现最原始的升级（Upgrade）请求.
只支持h2c的客户将需要生成一个请求 OPTIONS 的请求，因为 “*” 或者一个针对“/”的 HEAD 请求已经相当安全，并且也很容易构建. 寻求实现 HTTP/2 的客户将只需要把没有带上101状态码的HTTP/1.1响应看做一个错误就行了.
只支持h2c的服务器可以使用一个固定的101响应来接收一个包含升级（Upgrade）消息头字段的请求 .
没有h2c的Upgrade令牌的请求可以使用一个包含了Upgrade消息头字段的505（HTTP版本不支持）状态码来拒绝. 那些不希望处理
HTTP/1.1 响应的服务器应该在发送了带有鼓励用户在升级了的HTTP/2连接上重试的连接序言之后立即用带有 REFUSED_STREAM
错误码拒绝该请求的第一份数据流.
部署的问题
怎么调试加密过的 HTTP/2 ?
存取应用程序数据的方法很多, 最简单的方法是使用 NSS keylogging 加 Wireshark 插件 (包含在最新开发版中). 这种方式对 Firefox 和 Chrome 都适用.
