HTTP/1.1

改进

• 使用长连接的方式改善了 HTTP/1.0 短连接造成的性能开销。
• 支持管道（pipeline）网络传输，只要第一个请求发出去了，不必等其回来，就可以发第二个请求出去，可以减少整体的响应时间。

优缺点

优点：

1. 简单：报文格式 header + body，头部信息 key-value文本的形式。

2. 灵活和易于扩展：各类请求方法、URI/URL、状态码、头字段等允许自定义和扩充。工作在应用层下层可以随意变化，比如：

   1. HTTPS 在 HTTP 与 TCP 层之间增加了 SSL/TLS 安全传输层；
   2. HTTP/1.1 和 HTTP/2.0 传输协议使用的是 TCP 协议，而到了 HTTP/3.0 传输协议改用了 UDP 协议。

3. 应用广泛和跨平台

缺点：

• 无状态

  • 解决办法：Cookie 、Session

• 明文传输

• 不安全：窃听、伪造、篡改

• 请求 / 响应头部（Header）未经压缩就发送，首部信息越多延迟越大。只能压缩 Body 的部分；

• 发送冗长的首部。每次互相发送相同的首部造成的浪费较多；

• 队头阻塞：服务器是按请求的顺序响应的，如果服务器响应慢，会招致客户端一直请求不到数据；

• 没有请求优先级控制；

• 请求只能从客户端开始，服务器只能被动响应。

缓存

请求-响应的数据都缓存在本地，下次就直接读取本地的数据。

强制缓存

强缓存：只要浏览器判断缓存没有过期，则直接使用浏览器的本地缓存，主动性在于浏览器。

实现方法：

• Cache-Control， 是一个相对时间；
• Expires，是一个绝对时间；

Cache-Control 的优先级高于 Expires 。

协商缓存

Why？

过期就重新获取，但是过期也可能有效，再问问服务端即可。

How？

协商缓存：服务端告知客户端是否可以使用缓存，请求的响应码是 304。

基于两种头部实现：

• 第一种：请求头 If-Modified-Since与响应头Last-Modified：

  • Last-Modified：标示这个响应资源的最后修改时间；
  • If-Modified-Since：当资源过期了，再次发起请求时带上 Last-Modified 的时间，服务器收到请求后发现有 If-Modified-Since 则与被请求资源的最后修改时间进行对比（Last-Modified），如果最后修改时间较新（大），说明资源又被改过，则返回最新资源，HTTP 200 OK；如果最后修改时间较旧（小），说明资源无新修改，响应 HTTP 304 走缓存。

• 第二种：请求头 If-None-Match 与响应头 ETag 字段：

  • Etag：唯一标识响应资源；

  • If-None-Match：当资源过期时再次向服务器发起请求时，会将请求头 If-None-Match 值设置为 Etag 的值。服务器收到请求后进行比对，如果资源没有变化返回 304，如果资源变化了返回 200。

同时有 Etag 和 Last-Modified 字段时，Etag 的优先级更高：

1. 没有修改文件内容情况下文件的最后修改时间可能也会改变，导致客户端认为这文件被改动了，从而重新请求；
2. 可能有些文件是在秒级以内修改的，If-Modified-Since 能检查到的粒度是秒级的，使用 Etag就能够保证这种需求下客户端在 1 秒内能刷新多次；
3. 有些服务器不能精确获取文件的最后修改时间。

协商缓存这两个字段都需要配合强制缓存中 Cache-Control 字段来使用，只有在未能命中强制缓存的时候，才能发起带有协商缓存字段的请求。

强制缓存和协商缓存的工作流程：

减少请求次数

• 减少重定向请求次数

  • 代理服务器进行重定向工作，保存重定向，下一次直捣黄龙
  • 

• 合并请求

  • 合并资源，多个访问小文件的请求合并成一个大的请求：CSS Image Sprites、webpack打包
  • 缺点：当大资源中的某一个小资源发生变化后，客户端必须重新下载整个完整的大资源文件

• 延迟发送请求

  • 只获取当前用户所看到的页面资源，动态加载

减少响应的数据大小

• 无损压缩

  • # 客户端
    Accept-Encoding: gzip, deflate, br
    # 服务端
    Content-Encoding: gzip
    

• 有损压缩

  • # 客户端，q 质量因子
    Accept: audio/*; q=0.2, audio/basic