#HTTP/2.0

#期望目标

• 相比使用HTTP/1.1，最终用户可感知的多数延迟都有能够量化的显著改善
• 解决HTTP中的队头阻塞问题
• 并行的实现机制不依赖于服务器建立多个连接，从而提升TCP连接的利用率，特别是在拥塞控制方面
• 保留HTTP/1.1的语义，可以利用已有的文档资源，包括HTTP方法，状态码，URI和headers
• 明确定义HTTP/2.0和HTTP/1.*交互的方法，特别是通过中介时的方法
• 明确指出它们可以被合理使用的新的扩展点和策略

TLS(Transport Layer Security)

#分层

• 分帧层
  • 二进制协议
  • 首部压缩
  • 多路复用
  • 加密传输
• 数据层

#解析 HTTP/1 请求或响应可能出现的问题

• 一次只能处理一个请求或响应，完成之前不能停止解析
• 无法预判解析需要多少内存。这会带来一系列问题： 你要把一行读到多大的缓冲区里；如果行太长会发生什么，应该增加并重新分配内存，还是返回400错误。为了解决这些问题，保持内存处理的效率和速度可不简单。

#未解决的问题(QUIC)

• 无序的包处理

  如果TCP流上丢了一个数据包，那么整个h2连接都会停顿下来，直到该数据包重发并被接收到。QUIC将允许应用层继续接收并处理那些来自未受到丢包影响的流的包

• 灵活的拥塞控制

  UQUIC的拥塞控制机制被设计成插件式的，所以它非常容易实验新的算法，甚至可以根据实时条件切换不同算法

• 更低的建立连接开销

  QUIC的目标时建立连接时的‘零’往返延时(0-RTT)，包括加解密以及身份认证。依据当今的技术(TCP & TLS1.2)，建立连接所需的最小往返数是3

• 传输细节的身份验证

  在注入攻击以及针对TCP天生的信任特点开展的攻击手段面前，目前的TCP是比较脆弱的。QUIC会验证包的首部，增加对这类攻击的防御程度

• 连接迁移

  移动互联网时代，在逻辑长连接的通信当中，IP地址可能会变化。从TCP的角度看，连接需要断开在重连。即使客户端在移动，QUIC也会尝试提供维持连接的语义。