一、HTTP/1.1：基石初奠
HTTP/1.1 作为互联网发展历程中的重要里程碑，在相当长一段时间内撑起了网络通信的半边天。它引入了诸多关键特性，如持久连接，使得浏览器能够在一个 TCP 连接上发起多个请求，避免了反复建立和拆除连接的开销，大大提高了传输效率。默认开启的 Keep-Alive 头信息，让网页加载时不再需要为每个资源重新握手，像我们日常浏览新闻网站，图片、文字、样式表等众多元素得以较为流畅地依次呈现。
同时，HTTP/1.1支持的请求流水线技术极具开创性。在该技术框架下，浏览器得以突破传统请求模式的限制，能够连续不间断地向服务器发出多个请求，而不必像过去那样，每发出一个请求就需停顿下来，苦苦等待上一个请求的响应返回。从理论层面剖析，这种流水线式的请求处理模式，能让数据获取流程化、并行化，极大地缩短了整体的数据获取时间，进而显著加快传输速度。
以常见的简单文本网页为例，这类网页通常结构相对单一，内容主要以文字信息为主，涉及的外部资源链接较少。当用户点击链接访问此类网页时，得益于请求流水线技术，浏览器能够迅速将多个与文本展示相关的请求依次发出，服务器按序处理后快速反馈，用户便能在极短的时间内看到网页的基本内容，如文章标题、正文段落等信息，交互体验流畅高效。
然而，技术的发展总是在不断突破既有边界，互联网应用领域的飞速拓展超乎想象。特别是近年来，富媒体应用如高清视频流、在线直播，以及实时交互应用如多人在线游戏、实时音视频会议等如雨后春笋般大量涌现。这些新型应用对网络传输的实时性、稳定性以及高效性提出了极高要求，HTTP/1.1在面对此类复杂场景时，其固有的局限性便毫无保留地暴露出来，难以满足当下多元化网络应用的严苛需求。
二、瓶颈突显：HTTP/1.1 的困境
（一）队首阻塞
当一个 TCP 连接上的多个请求依次发出后，如果其中一个请求遭遇延迟，比如因为服务器处理缓慢、网络拥塞等原因，后续的请求即便服务器已经准备好数据，也只能干巴巴地等待队首请求完成。想象一下，你在网上抢购热门商品，下单请求卡在支付验证环节，而购物车更新、收货地址确认等后续操作统统被堵在后面，那种焦急等待的心情，就是队首阻塞带来的糟糕用户体验。在高并发场景下，大量请求堆积，这种阻塞效应会被成倍放大，导致网页加载缓慢，实时应用如在线游戏、视频会议卡顿严重。
产生的原因:
- 顺序处理请求: HTTP/1.1的持久连接中，同一连接上的多个请求需要按顺序处理，后续的请求必须等待前面的请求完成后才能进行
- 长连接的复用: 在HTTP/1.1中，一个TCP连接上通常只能同时处理一个请求。如果该请求长时间未完成（例如因为等待I/O操作），该连接上的请求就会被阻塞。
解决办法:
-
将同一个页面的资源分散到不同的域名下: 浏览器对同一个域名的TCP连接数量是有限制的,为了解决这个问题,程序员会将资源放到不同的域名下,比如早期的淘宝会把图标放到不同的images域名下,有的资源是放到 image1.taobao.com,有的是放到iamge2.taobao.com
-
将同一个页面的资源分散到不同的域名下: 浏览器对同一个域名的TCP连接数量是有限制的,为了解决这个问题,程序员会将资源放到不同的域名下,比如早期的淘宝会把图标放到不同的images域名下,有的资源是放到 image1.taobao.com,有的是放到iamge2.taobao.com
现在还是能看到不不同域名下的资源
-
合并小资源,减少请求次数:很经典的
雪碧图就是为了减少请求设计出来的 -
资源内联: 比如一些小的图标不用单独请求了,而是直接使用base64的方式嵌套到有页面上
-
HTTP2: 多路复用技术
（二）传输性能受限
HTTP/1.1 基于文本格式传输数据，头部信息冗长且重复。每次请求都要携带大量诸如用户代理、Cookie 等相同的头部字段，这无疑增加了传输的数据量。以图片密集型的电商页面为例，众多图片请求的头部信息累计起来，占用了可观的带宽资源，使得真正有用的图片数据传输反而受到挤压，页面加载时间延长，转化率也随之受到影响。
产生的原因
- 无状态: 因为HTTP的无状态,导致每次请求都是独立的,服务器没有状态,只能靠客户端每次都携带一些状态的数据到服务器端
解决办法:
- 在HTTP1.1中可以通过缓存的方式减少请求,从而减少http头(其实有点扯)
- 在HTTP2中添加了Header压缩,能很好的解决这个问题
三、SPDY 与 HTTP/2：过渡的探索
为了打破 HTTP/1.1 的僵局，谷歌率先推出了 SPDY 协议，它像是划破夜空的一道曙光，为后续 HTTP 协议的革新指明了方向。SPDY 引入了多路复用技术，一个 TCP 连接上可以同时传输多个请求和响应，彻底解决了队首阻塞问题。它将 HTTP 请求拆分成更小的帧，不同请求的帧可以交错发送，服务器也能按序返回响应，浏览器再重新组装。就好比高速公路拓宽成多车道，不同车辆（请求）可以并行前进，交通效率大幅提升。
受 SPDY 启发，HTTP/2 应运而生，它继承并发扬了多路复用的优势，成为新一代 HTTP 协议的主流。不仅如此，HTTP/2 采用了二进制格式传输数据，相比 HTTP/1.1 的文本格式，二进制更加紧凑、高效，头部信息经过压缩，进一步减少了传输的数据量。在加载大型网站时，HTTP/2 能让页面资源如潮水般迅速涌入，视频播放前的广告加载、社交媒体的动态刷新都变得敏捷许多，用户几乎察觉不到延迟。
HTTP2的优势
- 二进制传输 : HTTP/2 采用二进制格式传输数据，而非HTTP/1.x 里纯文本形式的报文 ，二进制协议解析起来更高效。HTTP/2 将请求和响应数据分割为更小的帧，并且它们采用二进制编码。
它把TCP协议的部分特性挪到了应用层，把原来的"Header+Body"的消息"打散"为数个小片的二进制"帧"(Frame),用"HEADERS"帧存放头数据、"DATA"帧存放实体数据。HTP/2数据分帧后"Header+Body"的报文结构就完全消失了，协议看到的只是一个个的"碎片"。 在1.1中最小传输单位是
报文,在2中拆分的更小的帧后,理由多路复用技术,这种帧在一个TCP链路上独立的传输,相互之间不影响,从而解决了队首堵塞的问题
没有了队首堵塞的问题后,上面提到的一些优化,也就没有多大的意义了 - Header压缩: 我们在1.1中提到了Header的两个问题,1重复: 每次都要发一样的头重复率很高,2重: 不仅仅是重复了,而且很多时候是头重Body轻,为了解决这两个问题HTTP2做了头部压缩:HTTP/2并没有使用传统的压缩算法，而是开发了专门的"HPACK”算法，在客户端和服务器两端建立“字典”，用索引号表示重复的字符串，还采用哈夫曼编码来压缩整数和字符串，可以达到50%~90%的高压缩率。
具体来说:
在客户端和服务器端使用“首部表”来跟踪和存储之前发送的键-值对，对于相同的数据，不再通过每次请求和响应发送；
首部表在HTTP/2的连接存续期内始终存在，由客户端和服务器共同渐进地更新;
每个新的首部键-值对要么被追加到当前表的末尾，要么替换表中之前的值
- 多路复用: 解决同一个域名的限制下的请求数量问题
- 同域名下所有通信都在单个连接上完成
- 单个连接可以承载任意数量的双向数据流
- 数据流以消息的形式发送，而消息又由一个或多个帧组成，多个帧之间可以乱序发送，因为根据帧首部的流标识可以重新组装
- Server Push HTTP/2引入了一项名为“Server Push”（服务器推送）的新功能，这项功能允许服务器在客户端请求某个资源时，主动向客户端推送其他相关资源。以下是Server Push的一些关键点
- 当客户端请求一个页面时，服务器可以主动发送与该页面相关的资源，比如CSS、JavaScript和图片文件等，而无需客户端明确请求它们
- 服务器推送的资源通过和常规响应一样的方式发送，但在推送之前，服务器会发送一个
PUSH_PROMISE帧，通知客户端即将推送哪些资源
为什么要强调二进制传输呢?
HTTP/1.1和HTTP/2之间的区别在于协议层面的表示和传输。尽管在底层，即通过TCP/IP协议进行传输时，数据在网络上以二进制形式传递，但是这与HTTP协议本身的数据表示和处理格式不同。HTTP/2选择了在协议层上使用二进制帧进行通信，而HTTP/1.1在协议层使用的是文本格式的报文。这种在协议层的二进制表述带来了多种优势
- 协议解析简化: 在HTTP/1.1中需要解析和理解文本格式的报文，解析器要处理字符编码、换行符等，增加了复杂性。而HTTP/2采用二进制帧，使解析更简单，因为每个帧都有明确的结构
- 多路复用: HTTP/2的帧结构允许在单个连接上并行处理多个流，二进制格式使得帧交换管理变得更有效和灵活。相比之下，HTTP/1.1的文本格式和报文结构不利于多路复用，容易引发队头阻塞。
虽然在底层传输中看起来最终都是二进制，但选择在协议层使用二进制格式代表了一种设计策略，旨在实现更高性能、更高效的资源利用和协议功能增强的目的。HTTP/2在协议设计上走向二进制化，正是为了克服HTTP/1.1的这些固有限制，并充分利用网络传输的潜在能力。
Server Push 和 WebSocket
这里的Server Push和WebSocket有本质上的区别,不能因为有了Server Push就觉得可以不用WebSocket了,HTTP2的Server Push 还是在运优化资源加载,增强单向通信能力的基础上,而WebSocket是一样全双工的通信通道,能保持连接持续进行通讯
HTTP2的缺点
虽然HTTP2在1.1的基础上解决了很多问题,但也还有一些问题需要解决 TCP效率低下 TCP为了保证数据不丢失,引入了很多保护机制,例如连接时的三次握手,超时重传机制等,这一方面是保护,另一方面也是束缚,让传输效率低下 这也是HTTP3出现的原因
