http协议+缓存机制

---

前言

http协议：基于TCP/IP协议，建立TCP连接，需要经过三次握手。
TCP协议：相对UDP协议来说，它是面向连接，传输是可靠的。

强缓存：通过expires和cache-control控制。
协商缓存：通过last-modified（if-modified-since）和etag（if-none-matched）控制。

---

一、http

1.http1.0/1.1

http1.0和1.1都通过响应头：Connection: keep-alive，来实现长连接，http1.1时，默认长连接。（服务器设置的响应头才有效）
短连接和长连接：
短连接：http每一次请求，都会重新建立tcp连接然后发送请求，完成请求后就会关闭tcp连接。
长连接：http第一次建立tcp连接并发送请求，并不会关闭tcp连接，后续请求可以直接发送请求，不用重新建立tcp连接。（长连接保持时间：服务器控制）
http建立长连接
当需要建立 HTTP 长连接时，HTTP 请求头将包含如下内容：

Connection: Keep-Alive

如果服务端同意建立长连接，HTTP 响应头也将包含如下内容：

Connection: Keep-Alive
Keep-Alive: timeout=5, max=100 （同时可以定义Keep-Alive模式的属性）
timeout：表示TCP连接可以保留5s，max：表示最大能建立100个请求。

当需要关闭连接时，HTTP 头中会包含如下内容：

Connection: Close

2.http2.0

http2.0优化体现在三个方面：

• HPACK算法： 对header进行压缩
• 多路复用：一个TCP连接可以同时处理多个请求（不用担心请求的个数）
• 服务器推送：请求一次请求html时，会同时返回html+css+js+img等

3.一个TCP连接可以发送多少个HTTP请求

长连接默认不会断开TCP连接，因此理论上是可以往同一个host发送无数个HTTP请求。

4.浏览器最多可以向同一个host建立几个TCP连接

这和浏览器有关系，chrome最多允许向同一个host建立 6 个TCP连接。

5.其他关于http

• 状态码

• 请求头/响应头/请求体/响应体

• https

• 正向代理和反向代理

• 数据data传输压缩

客户端请求头：
Accept-Encoding: gzip, deflate,br （表示data传输时，采用gzip/deflate/brotli 压缩传输）
服务器响应头：
content-encoding: gzip/deflate/br （如果有表示采用了压缩传输，否则就表面服务器没有开启压缩）

二、缓存

1.强缓存

强缓存通过expires和cache-control字段控制：

cache-control优先级比expires高，expires作为兜底使用

cache-control有一下属性：

max-age：31536000; 表示强缓存时间为31536000秒，换算也就是365天。
max-age：31536000,public：365天内客户端和代理服务器都可以缓存该资源。
max-age：31536000,private：365天内只让客户端可以缓存该资源；代理服务器不缓存。
max-age：31536000,immutable：365天内，就算用户刷新页面仍然使用缓存。
no-cache：不做强缓存，但是协商缓存仍然可以配置。
no-store：强缓存和协商缓存都不做。

2.协商缓存

协商缓存通过last-modified（if-modified-since）或者etag（if-none-matched）控制。

服务器响应头：
last-modified：Sun, 20 Feb 2022 08:52:52 GMT（时间戳，精确到秒）
etag：W/“7dbe2-/YNbrYQfoVaEN68JFm2CHs8koug”（hash字符串）


客户端请求头：
if-modified-since: Sun, 20 Feb 2022 08:52:52 GMT
if-none-matched：W/“7dbe2-/YNbrYQfoVaEN68JFm2CHs8koug”

缓存原理：第一次客户端发送请求，服务器返回last-modified（表示数据最后一次更新的时间）或者etage（单一个文件发生变化，这个文件的hash值就会变化），客户端将数据存入缓存。第二次请求时，将第一次请求时服务器返回的last-modified或者etae的值，对应if-modified-since和if-none-matched放入请求头，向服务器发生请求。服务器拿到这2个值，进行对比如果数据没有发生变化，那就只响应状态码304，客户端从本地拿资源。也就是：

客户端第一次发送请求 --> 客户端响应缓存值 --> 客户端保留缓存值 --> 客户端第二次请求(带缓存值) --> 服务器比对是否鲜活，如果鲜活返回304 || 如果不鲜活返回200，响应新的缓存值 --> 客户端更新缓存值

3.etag解决了last-modified不能解决的问题

• 一些文件也许会周期性的更改，但是他的内容并不改变(仅仅改变的修改时间)，这个时候我们并不希望客户端认为这个文件被修改了，而重新请求。
• 某些文件修改非常频繁，比如在秒以下的时间内进行修改，(比方说1s内修改了N次)，if-modified-since能检查到的粒度是秒级的，这种修改无法判断(或者说UNIX记录MTIME只能精确到秒)。
• 某些服务器不能精确的得到文件的最后修改时间。

注意：协商缓存受强缓存的影响，只有当强缓存过期了且Cache-Control不为no-store时是否缓存才由协商缓存决定。

4.Nginx如何配置缓存

配置协商缓存

location / public {add_header Cache-Control no-cache;etag on;if_modified_since exact;
}

配置强缓存

location / public {add_header   Cache-Control max-age=315360000;
}