HTTP 1.0、HTTP 1.1 和 HTTP 2.0 是超文本传输协议（HTTP）不同版本的规范，各自进行了多项更新和改进：
1. HTTP/1.0
- 单一请求-响应：每次请求都需要建立一个新的 TCP 连接，完成后立即断开。
- 无状态连接：服务器无法保存客户端的状态信息。
- 缺少持久连接：无法复用连接，每次请求都要重新建立 TCP 连接。
- 缓存控制：采用
Expires头字段指定缓存到期时间，但不够灵活。
2. HTTP/1.1
- 持久连接：默认启用持久连接（Connection: keep-alive），允许一个 TCP 连接复用多次请求，降低了连接建立和关闭的开销。
- 分块传输编码：支持分块传输（Transfer-Encoding: chunked），可以在不确定消息长度时逐块传输数据，提高了实时性。
- 带宽优化：支持内容协商（Content Negotiation），根据客户端的能力动态返回合适的资源版本。
- 新增缓存机制：引入了
Cache-Control头，提供更灵活的缓存控制。 - Host 头：允许在同一 IP 上部署多个域名，不同请求通过
Host头区分。
3. HTTP/2.0
- 多路复用：在一个连接上支持多个请求和响应的并发，解决了 HTTP/1.x 的“队头阻塞”问题，提升了资源加载效率。
- 二进制分帧：使用二进制格式传输请求和响应，代替了 HTTP/1.x 的纯文本，便于解析。
- 头部压缩：通过 HPACK 算法压缩 HTTP 头部，减少了带宽消耗。
- 服务端推送：允许服务器在客户端请求之前主动推送资源（如 JS、CSS），加速页面加载。
总结
- HTTP/1.0：每次请求建立新连接，效率低，基本已淘汰。
- HTTP/1.1：增加持久连接和缓存机制，优化了传输效率，至今仍在广泛使用。
- HTTP/2.0：支持多路复用和服务端推送，提升了加载性能，逐渐普及中。
为什么http1.0 Expires 头字段指定缓存到期时间，不够灵活
Expires 头字段在 HTTP/1.0 中用于缓存控制，其值是一个绝对时间（即 GMT 时间），用于指定资源的过期时间。例如：
Expires: Wed, 21 Oct 2023 07:28:00 GMT
之所以说它“不够灵活”，主要原因在于以下几点：
1. 依赖客户端的时间设置
Expires依赖客户端的本地时间来判断资源是否过期。如果客户端的时间设置不准确或者时区不同步，可能导致缓存行为不一致，比如资源过早过期或误认为未过期。
2. 无法实现相对时间控制
Expires只能指定一个固定的绝对过期时间，而无法表示“从请求时间开始，缓存多长时间”。如果服务端更新了资源，必须同步更新所有的Expires时间，不然客户端可能会继续使用已过期的缓存。
3. 不支持更复杂的缓存策略
Expires缺乏灵活性，无法表达一些更细化的缓存需求，比如短期缓存、重新验证缓存等。在动态内容较多的场景中，绝对时间很难满足需求，容易导致缓存失效过多或过期缓存被误用。
Cache-Control 作为替代方案
- 在 HTTP/1.1 中，引入了
Cache-Control头，允许使用相对时间（如max-age=3600表示缓存 3600 秒），解决了Expires的不足。 Cache-Control还提供了更多控制选项（如no-cache、no-store、must-revalidate），使缓存策略更加灵活和细化。
因此，Expires 因为绝对时间的限制不够灵活，而 Cache-Control 则通过支持相对时间和更多选项，增强了缓存控制的灵活性和精确度。
http2.0 在http1 上有哪些优化点
1. 多路复用
- HTTP/1.1：每个 TCP 连接只能处理一个请求，必须等待当前请求完成才能发送下一个请求（容易造成队头阻塞）。
- HTTP/2：支持在一个连接上同时发送多个请求和响应，不再受限于“一个连接一个请求”的限制，这大大减少了连接开销，解决了 HTTP/1.1 中的队头阻塞问题。
- 优势：提升了页面加载速度，特别是对多个静态资源并发请求时，显著减少了延迟。
2. 二进制分帧
- HTTP/1.1：使用纯文本协议传输数据，存在较多的解析开销。
- HTTP/2：采用二进制分帧层，将数据分成更小的帧，并以二进制格式传输。请求和响应被分成独立帧，可以乱序发送，最后在客户端重新组装。
- 优势：提高了传输效率，并降低了协议解析的复杂性。
3. 头部压缩
- HTTP/1.1：每个请求和响应都携带完整的头部，尤其在较多资源请求时，带来重复的数据传输开销。
- HTTP/2：采用 HPACK 算法对头部进行压缩，并引入头部表（Header Table）来存储重复的头字段，仅传输增量更新。
- 优势：减少了带宽消耗和网络延迟，特别是在包含大量相同头部的请求中效果显著。
4. 服务器推送
- HTTP/1.1：浏览器只能请求页面中引用的资源，不能预先获取相关资源。
- HTTP/2：允许服务器在客户端请求之前主动推送资源，如 CSS、JS、图片等，不必等待客户端发起请求。
- 优势：提前将关键资源推送给客户端，减少等待时间，提高页面首次加载速度。
5. 连接共享
- HTTP/1.1：为了避免队头阻塞，通常会打开多个 TCP 连接，但这增加了服务器和客户端的资源开销。
- HTTP/2：一个连接上可以处理多个流，减少了打开多个连接的必要，从而降低了资源消耗。
- 优势：提高了网络资源利用率，更适合高并发场景。
总结
HTTP/2 的这些改进，使得其在数据传输的效率、加载速度、延迟和带宽占用等方面都有了显著优化，在加载复杂页面和处理大量资源时，HTTP/2 相比 HTTP/1.1 有明显的性能优势。
如何开启HTTP/2.0
1. 使用支持 HTTP/2 的服务器
- Apache：需要开启 HTTP/2 模块。
- Nginx：版本需在 1.9.5 或以上。
- Node.js：通过 HTTP/2 模块支持。
- 其他服务器：例如 IIS 10 及以上版本也支持 HTTP/2。
2. 启用 HTTPS（TLS）
- 虽然 HTTP/2 协议并未强制要求 HTTPS，但主流浏览器（如 Chrome、Firefox）只在 HTTPS 下支持 HTTP/2。
- 确保网站已配置 SSL/TLS 证书，并且能够通过
https://访问。
3. 配置服务器以支持 HTTP/2
根据服务器类型进行相应配置：
-
Nginx 示例 在 Nginx 配置文件中，将
listen指令配置为支持 HTTP/2：复制代码
server { listen 443 ssl http2; ssl_certificate /path/to/your/certificate.crt; ssl_certificate_key /path/to/your/private.key; ... } -
Apache 示例 在 Apache 配置文件中，启用 HTTP/2 模块并更新 SSL 配置：apache
LoadModule http2_module modules/mod_http2.so Protocols h2 http/1.1
4. 前端验证
- 部署后，通过浏览器的 开发者工具 进行验证。打开 Network（网络） 面板，查看请求的
Protocol列，确认是否为h2。 - 可以使用命令行工具
curl验证协议。例如：curl -I -k --http2 https://your-domain.com
通过上述配置，前端资源将自动通过 HTTP/2 进行传输，提升加载速度。
