标签：基于   完全   lin   服务   quic   控制   通信   影响   ons   

HTTP/2

HTTP/2相比HTTP/1而言提供了更加高效的传输方式，解决了HTTP/1.x中存在的很多问题，协议增加了二进制帧控制层，大多数改动都封装在这一层。以下会简单对比HTTP/1.0 & HTTP/1.1 从而引申出HTTP/2的改进。

• HTTP/1.0 & HTTP/1.1
  • 1.1新增对长链接的支持：1.0中每次client与server建立TPC链接并完成请求处理以后，TCP链接即断开，而在1.1中HTTP支持使用keep-alive选项来开启长链接，也就是HTTP连接会维持一段时间，这样在这段时间内这个连接上的数据就能够直接传输而不需要再次进行耗时的TCP建立连接的过程了。长短连接的关系问题可以参考HTTP长链接短链接
  • 1.1新增了对请求流水（piplining）的支持，就是图中第二栏所示。但是这里也有一个问题就是头部阻塞，HTTP/1.1必须按顺序接收三个请求，所以如果其中某一个请求失败，client必须等待请求重发并接收成功后才能继续向下处理
  • 1.1添加了更多的Catch缓存策略选项，比如：Entity tag，If-Unmodified-Since, If-Match, If-None-Match等,参考这个http缓存机制原理
  • 增加了一些错误通知类型
  • 支持host头域，这个主要是为了适应虚拟主机的使用
  • 允许部分请求资源，而不是像以前一样必须返回整个对象
• HTTP/2新增详细，这里我基本上是搬运了HTTP/2英文 良心翻译
  • HTTP2.0并没有改变之前HTTP的语义,也就是说高层的Api并没有改变,它是在底层通过二进制frame来改变性能的
  • 二进制帧层： http/1.x使用换行符分割文本，而HTTP/2则改用二进制来进行传输，虽然麻烦一些但是在效率和正确性上都得到了保证。
    • ASCII 协议能够很容易的看出来和开始使用。然而它们是没有效率的，且很难正确设计：可选的空白，改变终止序列和其他的毛病使得协议很难区别出payload。虽然二进制协议用起来需要做很多工作，但是它们能表现出更好的性能。
  • 消息传递方式：最小的消息单元为帧，是消息的切片，传输时可以乱序，可以组装。frame组成逻辑上的消息，即request和response。同一个TCP连接上有很多双向流供frame流通。注意，所有的通信都在同一个TCP连接上进行。
  • 多路复用解决头阻塞问题：HTTP/2使用的是frame为单元的二进制消息单元进行通信的，并且提供了乱序传递，然后组装的消息处理方式，使得多路数据可以混杂在一起进行传递，这也使得其中某个消息的丢弃并不会影响到其他消息的正常传递，所以也就没有了1.1中的头部阻塞问题。这一特性使得HTTP协议的速度有了一个大的提升。
    当然，也有部分资料提出由于HTTP/2通常基于TCP实现，所以依旧存在丢包会等待重传的问题（HOL阻塞），这里又引申出QUIC协议，这里本文就不在深入介绍啦。
  • 可以设定流的优先级和依赖
  • 服务推送：HTTP/1.x在现代网页渲染的时候为了处理一个完整的网页可能同时簇发几十甚至上百个请求，这是没有必要的，实际上服务器完全可以通过特定的请求和预先恰当的定义，分析得到前端需要哪些资源，然后由server主动推送这些资源。HTTP/2提供了这种能力。
  • 头部压缩：同样的，现代网页簇发多个request，但是它们的头很可能是没啥区别的，这是很大的浪费。甚至有的时候消息头的大小会超过实际需要的数据，这是不合理的。
    为了解决这个问题，HTTP/2引入了头部压缩。个人认为它实际上是在服务端建立了一个头部索引，client可以通过特定的索引来获取头信息，而不需要完整的携带它们，对于新的头选项client和server协作更新并保存。如图所示：

HTTP/2特性

标签：基于   完全   lin   服务   quic   控制   通信   影响   ons   

原文地址：https://www.cnblogs.com/souther-blog/p/10803710.html