HTTP/1.1 优化

避免发送 HTTP 请求
对于一些具有重复性的 HTTP 请求，比如每次请求得到的数据都一样的，我们可以把这对「请求-响应」的数据都缓存在本地，通过缓存技术减少请求次数。

客户端会把第一次请求以及响应的数据保存在本地磁盘上，其中将请求的 URL 作为 key，而响应作为 value，两者形成映射关系。之后再发起相同请求，就在本地磁盘查找 key 对应的 value，直接本地读取响应。

首先，服务器发送 HTTP 响应会估算过期时间并发送给客户端，客户端发现未超时就会直接使用本地；如果过期了，客户端重新发送请求，并在请求的 Etag 头部带上第一次请求时响应头部的摘要，服务器会比较服务器本地资源，如果是一样的，仅返回不含有包体的 304 Not Modified 响应来减少传输延时，如果不一样那就传输最新资源。

缓存的使用

减少 HTTP 请求次数
减少重定向请求次数。重定向请求就是服务器的资源从 url1 迁移到 url2，那么请求 url1 之后就会返回 302 响应码以及对应的 Location 头部。要知道的是服务器也有多级，一般客户端与代理服务器沟通，而代理服务器再去源服务器请求资源；那么重定向的工作交由代理服务器完成，就能减少 HTTP 请求次数了

把多个访问小文件的请求合并成一个大的请求，虽然传输的总资源还是一样，但是减少请求，也就意味着减少了重复发送的 HTTP 头部。同时为了防止 HTTP/1.1 的队头阻塞问题，一般浏览器会同时发起 5-6 个请求，每一个请求都是不同的 TCP 连接，那么如果合并了请求，也就会减少 TCP 连接的数量，因而省去了 TCP 握手和慢启动过程耗费的时间。合并请求的方式就是合并资源，以一个大资源的请求替换多个小资源的请求。但是这样的合并请求会带来新的问题，当大资源中的某一个小资源发生变化后，客户端必须重新下载整个完整的大资源文件，这显然带来了额外的网络消耗。

延迟发送请求。可以通过「按需获取」的方式，来减少第一时间的 HTTP 请求次数。

减少 HTTP 响应的数据大小
无损压缩，资源压缩后信息不被破坏，仍能还原到压缩前的原样，适合用在文本文件、程序可执行文件、程序源代码。

无损压缩，就可以在客户端请求的时候通过头部中的 Accept-Encoding 字段告诉服务器：

Accept-Encoding: gzip, deflate, br
服务器收到后压缩，最后通过响应头部的Content-Encoding 字段告诉客户端该资源使用的压缩算法。

Content-Encoding: gzip
有损压缩，解压的数据就会与原始数据有不同，但非常接近。有损压缩主要将次要的数据舍弃，牺牲一些质量来减少数据量、提高压缩比，这种方法经常用于压缩多媒体数据，比如音频、视频、图片。

可以通过 HTTP 请求头部中的 Accept 字段里的「 q 质量因子」，告诉服务器期望的资源质量。

Accept: audio/*; q=0.2, audio/basic
目前压缩比较高的是 Google 推出的 WebP 格式。常用于压缩图片。如果是音视频，会通过在一个静态的关键帧，使用增量数据来表达后续的帧来压缩。对于视频常见的编码格式有 H264、H265 等，音频常见的编码格式有 AAC、AC3。