今天给各位分享深入解析：HTTP/2 协议核心特性与应用的知识，其中也会对进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！
request报文
image
response报文
image
http/1.1的问题
HTTP协议为早期互联网的普及做出了巨大的贡献，构建了现代互联网的基础设施。但由于该协议制定较早，因此在很多方面仍然存在局限性。在互联网飞速发展、信息爆炸的今天，难免会出现一些短缺。主要体现在以下几个方面：
传输报文采用ascii文本形式，http头不会被压缩。这对可读性比较友好，但对计算机不太友好。另外，传输效率低。请求只能由客户端发起，不能由服务器发起。该模式限制了一些主动推送或双工要求的使用场景。当然还有websocket等解决方案，但严格来说它们已经不在http协议的范围之内了。同步阻塞通信：其实http/1.1中已经默认使用了持久连接，可以为多个请求复用同一个TCP连接。同时，利用管道机制（pipelined），可以同时在同一个TCP连接上发出请求。但HTTP 本质上是一个请求/响应模型。服务器仍然需要按照请求的顺序进行回复，不能乱序回复。这样的话，如果前面的响应特别慢，后面就会有很多请求在排队等待。这称为“队头阻塞”。由于队头拥塞问题，当客户端想要下载大量资源时，必须与服务器建立多个TCP连接（大多数浏览器允许最多6个到指定服务器的持久连接）来实现并发传输的限制。众所周知，建立和销毁TCP连接的成本非常高（如果是https的话就更高），同时也增加了服务器的资源消耗。基于以上痛点，http/2诞生了。
HTTP/2
SPDY
http/2 源自Google 的SPDY 项目（是的，又是Google -_-），于2009 年中期发布。它的主要目标是解决HTTP/1.1 中一些众所周知的性能限制。减少网页加载延迟（我上面提到的那些众所周知的限制）。具体而言，本项目设定的目标如下：
页面加载时间(PLT) 减少了50%。网站作者无需修改任何内容。最大限度地降低部署复杂性，无需更改网络基础设施。这个新协议是与开源社区合作开发的。收集真实的性能数据来验证该实验协议是否有效。到2012年，这个新的实验性协议得到了Chrome、Firefox和Opera的支持，越来越多的大型网站（如Google、Twitter、Facebook）和小型网站开始在其基础设施内部署SPDY。事实上，在被业界越来越多地采用后，SPDY已经具备成为标准的条件。
观察到这一趋势，HTTP工作组（HTTP-WG）将这项工作提上了议程，吸取了SPDY的教训，并在此基础上制定了官方的“HTTP/2”标准。在制定声明草案、向社区征求HTTP/2 提案并进行内部讨论后，HTTP-WG 决定使用SPDY 规范作为新HTTP/2 协议的基础。 2015年初，IESG审核了新的HTTP/2标准并批准发布。
二进制分层帧
HTTP/2 中所有性能增强的核心是新的二进制帧层，它定义了HTTP 消息如何在客户端和服务器之间封装和传输。
正如您所看到的，http 的语义没有改变（包括各种动词、方法和标头）。不同之处在于它们在传输过程中的编码方式发生了变化。 HTTP/1.x 协议使用换行符作为纯文本的分隔符，而HTTP/2 将所有传输的信息分割成更小的消息和帧，并以二进制格式对它们进行编码。原始http标头包含在HEADERS帧中，原始http主体包含在DATA帧中。这样，为了客户端和服务器能够互相理解，就必须支持http/2消息格式。由于引入了二进制分层帧这个新概念，该协议不向后兼容，这就是它被称为http/2的原因。而不是http/1.2的根本原因。
数据流、消息和帧
新的二进制成帧机制改变了客户端和服务器之间交换数据的方式。为了说明这个过程，我们需要了解HTTP/2 的三个概念：
数据流：已建立的连接内的双向字节流，可以承载一个或多个消息。
消息：对应于逻辑请求或响应消息的完整帧序列。
帧：HTTP/2 通信的最小单位。每个帧都包含一个帧头，帧头至少标识当前帧所属的数据流。
这些概念之间的关系总结如下：
所有通信都是通过TCP 连接完成的，该连接可以承载任意数量的双向数据流。
每个数据流都有唯一的标识符和可选的优先级信息，用于承载双向消息。
每条消息都是一个逻辑HTTP 消息（例如请求或响应），包含一个或多个帧。
帧是最小的通信单元，承载特定类型的数据，例如HTTP 标头、消息负载等。来自不同数据流的帧可以交错发送，然后根据每个帧头中的数据流标识符重新组装。
简而言之，HTTP/2 将HTTP 协议通信分解为二进制编码帧的交换，这些交换对应于特定数据流中的消息。所有这些都在一个 TCP 连接内多路复用。这是HTTP/2 协议所有其他功能和性能优化的基础。
请求与响应复用
在HTTP/1.x 中，如果客户端想要发出多个并行请求以提高性能，则必须使用多个TCP 连接（请参阅使用多个TCP 连接）。这是HTTP/1.x 交付模型的直接结果，该模型保证每个连接一次仅交付一个响应（响应排队）。更糟糕的是，这种模型还会导致队头阻塞，导致底层TCP 连接效率低下。
HTTP/2 中新的二进制成帧层突破了这些限制，实现了完整的请求和响应复用：客户端和服务器可以将HTTP 消息分解为相互独立的帧，然后将它们交织并在另一端再次发送。把它们放回一起。
image.png 快照在同一连接内并行捕获多个数据流。客户端正在向服务器传输DATA 帧（数据流5）。同时，服务器正在向客户端发送一系列数据流1和数据流3帧。因此，一个连接上同时存在三个并行数据流。
将HTTP 消息分解成独立的帧，将它们交错，然后在另一端重新组装它们，是HTTP 2 最重要的增强之一。事实上，这种机制将在整个网络技术栈中引发连锁反应，从而带来巨大的性能提升改进，使我们能够：
多个请求并行、交错发送，请求之间互不影响。多个响应并行且交错发送，互不干扰。使用一个连接并行发送多个请求和响应。不再需要绕过HTTP/1.x 限制（请参阅优化HTTP/1.x，例如串联文件、图像精灵和域分片）。消除不必要的延迟，提高现有网络容量的利用率，从而减少页面加载时间等……HTTP/2中新的二进制帧层解决了HTTP/1.x的问题。存在的队头阻塞问题还消除了并行处理和发送请求和响应时对多个连接的依赖。因此，应用程序速度更快，开发更简单，部署成本更低。
数据流优先级
这是http/2协议的高级功能。通过将HTTP 消息分解为许多独立的帧，我们可以在多个数据流中重用这些帧，并且客户端和服务器交错发送和传输这些帧的顺序成为关键的性能决定因素。为了做到这一点，HTTP/2 标准允许每个数据流具有关联的权重和依赖性：
每个数据流可以分配一个1 到256 之间的整数。
每个数据流可以对其他数据流具有显式依赖性。
数据流依赖性和权重的组合允许客户端构建并传递“优先级树”，指示它更喜欢如何接收响应。反过来，服务器可以使用此信息通过控制CPU、内存和其他资源的分配来确定数据流处理的优先级。资源数据可用后，带宽分配可以确保高优先级响应以最佳方式传递给客户端。
图片.png
HTTP/2 中的数据流依赖关系是通过引用另一个数据流的唯一标识符作为父级来声明的；如果省略该标识符，则相应的数据流将依赖于“根数据流”。声明数据流依赖关系表明，只要有可能，就应先将资源分配给父数据流，然后再将资源分配给其依赖关系。换句话说，“请先处理和发送响应D，然后处理和发送响应C”。
共享相同父级的数据流（即同级数据流）应根据其权重按比例分配资源。例如，如果流A 的权重为12，其兄弟流B 的权重为4，则确定每个流应接收的资源比例：
将所有权重相加：4 + 12=16 将每个数据流权重除以总权重：A=12/16，B=4/16 因此，数据流A 应该获得数据流B 应该获得的可用资源的四分之三可用资源的四分之一；流B 应该获得流A 获得的资源的三分之一。让我们看一下上图中的其他几个动手示例： 顺序是从左到右：数据流A 和数据流B 都没有指定的父依赖项，并且依赖于显式的“根数据流”； A的权重为12，B的权重为4。因此，按照比例加权：数据流B获得A获得的资源的三分之一。数据流D取决于根数据流； C 依赖于D。因此，D 应该先于C 获得完整的资源分配。权重并不重要，因为C 的依赖项具有更高的优先级。数据流D应该先于C获得完整的资源分配； C应该先于A和B获得完全的资源分配；数据流B 应该获得A 获得的资源的三分之一。数据流D应该先于E和C获得充分的资源分配； E和C应该先于A和B获得相同的资源分配； A和B应根据其权重按比例分配。如上例所示，数据流依赖性和权重的组合清楚地表达了资源优先级，这是提高浏览性能的关键特征。网络中存在多种具有不同依赖关系和权重的资源类型。不一样（比如在网页上，我们应该首先保证文本资源被加载，然后是图片和视频）。不仅如此，HTTP/2协议还允许客户端随时更新这些优先级，进一步优化浏览器性能。换句话说，我们可以根据用户交互和其他信号改变依赖关系并重新分配权重。
每个来源一个连接
这是http/2协议带来的重大性能提升。通过新的成帧机制，HTTP/2不再依赖多个TCP连接来并行复用数据流；每个数据流被分成许多帧，并且这些帧可以被交织并分别确定优先级。所以，所有 HTTP/2 连接都是永久，而且只需要每个来源一个连接，这带来了很多性能上的好处。
大多数HTTP 传输都是短暂且突发的，而TCP 针对长时间、批量数据传输进行了优化。通过重用相同的连接，HTTP/2 既可以更有效地利用每个TCP 连接，又可以显着降低总体协议开销。不仅如此，使用更少的连接占用更少的内存和处理空间，还缩短了完整的连接路径（即客户端、可信中介和源服务器之间的路径），从而降低了总体运营成本并提高了效率。网络利用率和容量。因此，迁移到HTTP/2 不仅可以减少网络延迟，还有助于提高吞吐量并降低运营成本。
减少连接数量对于提高HTTPS 部署的性能来说是一个特别重要的特性：众所周知，建立基于TLS 的http 连接非常耗时。 http/2 可以减少昂贵的TLS 连接数量、提高会话重用并提高HTTPS 部署的性能。所需的客户端和服务器资源总体减少。
流控制
流量控制是一种机制，可防止发送方向接收方发送超出后者需求或能力的大量数据：发送方可能非常繁忙、负载较高，或者可能只需要为特定数据流分配固定数量的资源。例如，客户端可能请求了具有较高优先级的大视频流，但用户已暂停视频，并且客户端现在希望暂停或限制来自服务器的传输以避免提取和缓冲不必要的数据。再比如，代理服务器可能有较快的下游连接和较慢的上游连接，并且还希望调整下游连接传输数据的速度以匹配上游连接的速度，以控制其资源利用率；等等。
上面的需求是不是让你想到了TCP流控呢？你应该预料到这一点；因为问题基本上是相同的（参见流量控制）。然而，由于HTTP/2 数据流在TCP 连接内进行多路复用，因此TCP 流量控制的粒度不够细，也无法提供必要的应用程序级API 来调节各个数据流的传输。为了解决这个问题，HTTP/2 提供了一组简单的构建块，允许客户端和服务器实现自己的数据流和连接级流控制：
流量控制是定向的。每个接收器可以选择为每个流和整个连接设置它想要的任何窗口大小。流量控制是基于信用的。每个接收方都可以发布其初始连接和数据流流量控制窗口（以字节为单位），每次发送方发送DATA 帧时，该窗口都会减少，而每当接收方发送WINDOW_UPDATE 帧时，该窗口就会增加。无法禁用流量控制。建立HTTP/2 连接后，客户端将与服务器交换SETTINGS 帧，服务器设置双向的流量控制窗口。流量控制窗口的默认值设置为65,535 字节，但接收方可以设置更大的最大窗口大小（2^31-1 字节），并通过在接收到任何数据时发送WINDOW_UPDATE 帧来维持此大小。流量控制是逐跳控制，而不是端到端控制。也就是说，可信中介可以使用它来控制资源使用，并根据自己的条件和启发式实施资源分配机制。 HTTP/2 没有指定任何特定的算法来实现流量控制。然而，它提供了简单的构建块并推迟了客户端和服务器的实现，支持自定义策略来调节资源使用和分配，并启用新的传输功能，同时提高网络应用程序的实际和感知性能（请参阅速度、性能和人类感知）。
例如，应用程序层流控制允许浏览器仅获取特定资源的一部分，通过将数据流控制窗口减小到零来暂停获取，然后再恢复。换句话说，它允许浏览器获取图像预览或第一次扫描结果，显示它并允许其他高优先级的获取继续，然后在更关键的资源完成加载后恢复获取。
服务器推送
如前所述，HTTP/1.1 无法主动将信息从服务器推送到客户端。这是HTTP/2添加的又一个强大的新功能。服务器可以对客户端请求发送多个响应。换句话说，除了响应初始请求之外，服务器还可以向客户端推送其他资源，而无需客户端明确请求它们。
image.pngHTTP/2 打破了严格的请求-响应语义，支持一对多和服务器发起的推送工作流程，在浏览器内部和外部开辟了新的交互可能性。这是一个重要的功能，对于我们如何看待协议、协议的用途以及如何使用协议具有重要的长期影响。
为什么我们在浏览器中需要这样的机制呢？典型的Web应用程序包含多种资源，客户端需要检查服务器提供的文档来一一查找它们。那么为什么不让服务器提前推送这些资源，从而减少额外的延迟呢？服务器已经知道客户端接下来要请求什么资源，这个时候服务器推送就可以派上用场了。
事实上，如果您曾经通过网页中的数据URI 内联CSS、JavaScript 或其他资源（请参阅资源内联），那么您就已经亲身体验过服务器推送。通过手动将资源内联到文档中的过程，我们实际上是将资源推送给客户端，而不是等待客户端请求它。使用HTTP/2，我们不仅获得了相同的结果，而且还获得了额外的性能优势。推送资源可以进行如下处理：
被客户端缓存不同页面之间复用与其他资源复用由服务器优先被客户端拒绝
PUSH_PROMISE 101
所有服务器推送数据流均由PUSH_PROMISE 帧发起，表明服务器正在向客户端推送资源Intent，并且需要在请求推送资源之前传输响应数据。这种传输顺序非常重要：客户端需要知道服务器打算推送哪些资源，以避免对这些资源创建重复的请求。满足此要求的最简单策略是在父响应（即DATA 帧）之前发送包含承诺资源的HTTP 标头的所有PUSH_PROMISE 帧。
客户端收到PUSH_PROMISE帧后，可以根据自身情况选择拒绝该数据流（通过RST_STREAM帧）。 （如果资源已在缓存中，则可能会发生这种情况。）这是相对于HTTP/1.x 的重要改进。相反，使用资源内联（流行的HTTP/1.
使用HTTP/2，客户端仍然可以完全控制服务器推送的使用方式。客户端可以限制并行推送的流数量；调整初始流量控制窗口，以控制首次打开流时推送的数据量；或完全禁用服务器推送。这些优先级在HTTP/2 连接开始时在SETTINGS 帧中传输，并且可以随时更新。
每个推送的资源都是一个数据流。与嵌入资源不同，客户端可以对推送的资源进行一一重用、优先级和处理。浏览器强制执行的唯一安全限制是推送的资源必须遵守同源策略：服务器必须对所提供的内容具有权威性。
标头压缩
每个HTTP 传输都带有一组标头，用于描述所传输的资源及其属性。在HTTP/1.x 中，此元数据始终为纯文本形式，通常会为每次传输增加500-800 字节的开销。如果使用HTTP cookie，增加的开销有时会达到数千字节。 （请参阅测量和控制协议开销。）为了减少这种开销并提高性能，HTTP/2 使用HPACK 压缩格式来压缩请求和响应标头元数据，该格式使用两种简单但强大的技术：
此格式支持通过静态霍夫曼代码对传输的标头字段进行编码，从而减少单个传输的大小。这种格式要求客户端和服务器同时维护和更新先前看到的标头字段的索引列表（换句话说，它建立共享压缩上下文）。然后将该列表用作先前传输的参考。该值被有效编码。使用霍夫曼编码，可以在传输过程中压缩各个值，并且使用先前传输的值的索引列表，我们可以通过传输索引值对重复值进行编码，这可以用于高效地查询和重建完整的标头。键值对。
image.png
HPACK 的安全性和性能
早期版本的HTTP/2 和SPDY 使用zlib（带有自定义字典）来压缩所有HTTP 标头。这种方法将传输的标头数据的大小减少了85% - 88%，从而显着减少了页面加载时间延迟：
在上行链路速度仅为375 Kbps 的较低带宽DSL 链路上，单独压缩请求标头可显着减少某些网站（即发出大量资源请求的网站）的页面加载时间。我们发现仅由于标头压缩，页面加载时间就减少了45 - 1142 毫秒。 （SPDY 白皮书，chromium.org）
【深入解析：HTTP/2 协议核心特性与应用】相关文章：
2.米颠拜石
3.王羲之临池学书
8.郑板桥轶事十则
用户评论
我一直听说HTTP/2更快，真的吗？具体是怎么实现的呢？
有19位网友表示赞同！
我现在还在用的网站都是基于HTTP/1.1的吗？怎么才能知道它是不是HTTP/2?
有9位网友表示赞同！
学习新的网络协议总是很挑战！感觉 HTTP/2 有点复杂，希望可以有简单易懂的解释。
有16位网友表示赞同！
听说HTTP/2 对静态资源传输特别有效，对网站加载速度有没有显著提升？
有17位网友表示赞同！
用HTTP/2 会影响安全性吗？
有7位网友表示赞同！
我还在纠结使用TLS/SSL和 HTTP/2 一起使用的问题...
有19位网友表示赞同！
这篇文章能介绍下HTTP/2 的未来发展吗？
有5位网友表示赞同！
学习了这个协议，我对网速进步更有所了解了！
有6位网友表示赞同！
原来HTTP/2 还可以解决头部重复的问题啊！太棒了！
有7位网友表示赞同！
我想知道 HTTP/2 和 HTTPS 的关系是什么？
有15位网友表示赞同！
HTTP/2 能加速网站吗？具体提升多少速度呢？
有9位网友表示赞同！
文章里有具体的案例分析吗？看个例子更容易理解
有16位网友表示赞同！
对开发者来说，使用HTTP/2 有哪些好处？
有16位网友表示赞同！
学习新协议感觉很费劲，不过为了更好地理解网站技术的魅力，还是得坚持下去！
有18位网友表示赞同！
这篇文章内容比较专业，希望能有更简洁易懂的讲解。
有8位网友表示赞同！
我一直在关注 HTTP/2 的最新进展，现在这个版本已经稳定了吗?
有14位网友表示赞同！
HTTP/2 和 HTTP/3 的区别是什么？哪个更好用?
有11位网友表示赞同！
学习完这个协议应该有哪些实践操作可以巩固知识呢？
有15位网友表示赞同！
希望能看到更多关于 HTTP/2 实战应用的文章，更加深入浅出！
有17位网友表示赞同！