前端缓存: Http缓存 + 浏览器缓存

Soldier33
91 阅读10分钟

前端缓存: Http缓存 + 浏览器缓存

  1. 浏览器缓存： 需要在客户端和服务器之间传递少量数据，例如登录状态：Cookie。 httpOnly传递token , 4k • 需要在客户端长期存储大量数据，例如用户偏好设置：LocalStorage , 5m • 需要在客户端临时存储数据，例如填写表单的中间数据：SessionStorage， 5m

    A、 cookie的属性

    • HttpOnly：表示 Cookie 只能通过 HTTP 请求访问，不能通过 JavaScript 访问。
    • Expires：表示 Cookie 的过期时间。
    • Secure：表示 Cookie 只能通过 HTTPS 协议传输。

    B、 token 信息在客户端的存储及传输是用户不必重复登录的关键

    客户端存储 token 信息的方式有两种：服务端自动植入和前端手动存储 服务端自动植入：响应报头中设置首部字段 set-cookie

    C、 IndexedDB 是一个大规模的 NoSQL 存储系统， 它几乎可以存储浏览器中的任何数据内容， 包括二进制数据（ArrayBuffer 对象和 Blob 对象），其可以存储不少于 250M 的数据

    D、拓展gin中的使用： store := cookie.NewStore([]byte(setting.CookieSetting.Key)) store.Options(sessions.Options{MaxAge: 0, Path: "/", HttpOnly: true}) r.Use(sessions.Sessions("xxx-session", store)) 这代码作用是什么 根据 客户端请求 → 中间件校验 Cookie → if 有效 → 继续处理请求 → 处理完成后 → 生成新Session Cookie → 返回客户端 else → 返回 401 未授权

  2. http缓存 A.强缓存： 1. expires，废弃，因为本地时间和服务器时间不同步的问题 2. cache-control http1.1添加 'Cache-Control':'max-age=10' Cache-control有max-age、s-maxage、no-cache、no-store、private、public这六个属性。

         * no-cache表示是强制进行协商缓存。
     * no-store是表示禁止任何缓存策略。

     资源加载大小变成了 `disk cache`，还有 `Memory Cache`（内存缓存），memory Cache 比 disk cache 更快
     * **s-maxage 仅在代理服务器中生效**
     * **在代理服务器中 s-maxage 优先级高于 max-age，同时出现时 max-age 会被覆盖**

    B. 协商缓存：服务器响应请求时返回的报头首部e-tag 、 last-modified 1. last-modified 获取时间， Cache-Control字段值设置为:no-cache 判断依据： last-modified （响应头） === If-Modified-Since （请求头） 则采用缓存 （存在漏洞，比如只修改文件名、修改时间极短（假如毫秒）， 秒单位，）

         2. e-tag 作为补充。 比较文件指纹，资源内容hash 的信息摘要  。
     （文件太多就影响性能，所以有强验证和弱验证，弱验证就去文件部份属性进行hash）

     判断依据： Etag （响应头） 值与   If-None-Match （请求头）不一致时，说明服务器上的文件已经被更新

     
     3、304 状态码主要与以下 HTTP 响应头有关：
     一、Last-Modified 和 If-Modified-Since
     二、ETag 和 If-None-Match
     ETag的生成  1 、基于资源内容生成（hash）  
                 2. 基于资源属性生成 （时间戳） 
                 3. 动态生成（服务端逻辑 特定业务）

    C、启发式缓存 缓存新鲜度 = max(0,（date - last-modified)) * 10% 根据响应报头中 date 与 last-modified 值之差与 0 取最大值后取其值的百分之十作为缓存时间

    D、根据 HTTP 缓存的规则最终我们便可以总结出如下缓存方案：

     - **频繁变动的资源，比如 HTML， 采用协商缓存**
 - **CSS、JS、图片资源等采用强缓存，使用 hash 命名**

    E、状态码： 301 Moved Permanently（永久重定向） 302 Found（临时重定向）

    • 测试环境：使用 302 将流量临时导向测试服务器，完成后移除重定向。

    400 Bad Request（错误请求） 401 Unauthorized（未授权） 403 Forbidden（禁止访问） 405 Method Not Allowed（方法不被允许） 408 Request Timeout（请求超时） 429 Too Many Requests（请求过多）

    F、模式一：正常重新加载 模式二：硬性重新加载： 硬性重新加载并没有清空缓存，而是禁用缓存 模式三：清空缓存并硬性重新加载： 触发该操作会将浏览器存储的本地缓存都清空掉后再重新向服务器发送请求，同时其影响的并不是当前网站，所有访问过的网站缓存都将被清除

     为什么 Ctrl + F5 还是命中了缓存？（硬性重新加载）
 发现那些命中缓存的资源都是随着页面渲染而加载的，
 而不走缓存的则是等待页面加载完通过脚本异步插入到 DOM 中去的，
 于是便得到了资源异步加载命中缓存不受硬性重新加载控

 还有一种资源比异步资源更加“顽固”，几乎永远都是 `from memory cache`：
 Base64 格式的图片被塞进 memory cache 可以视作浏览器为节省渲染开销的“自保行为”。

    G、memory Cache 比 disk cache 更快， 生命周期短，当网页关闭后内存就会释放 顺序：内存 -> 磁盘 -> 网络请求

      base64 的图片永远从内存加载，内存还会有必须渲染的js
  被内存抛弃的资源我们也可以发现其都是异步加载的资源
  磁盘缓存会将命中强缓存的 js、css、图片

 preload 也被称为预加载，其用于 link 标签中，可以指明哪些资源是在页面加载完成后即刻需要的
 prefetch 则表示预提取，告诉浏览器加载下一页面可能会用到的资源，浏览器会利用空闲状态进行下载并将资源存储到缓存中
 
 优化浏览器资源加载的顺序和时机

  3. http 不同版本 1.x： 文本格式，序列和阻塞机制
    1.1 keep-alive支持长连接 三次握手 2： 二进制帧层、多路复用、头部压缩、服务器推送、流优先级 (1) 二进制帧层 二进制数据帧， 帧属于哪个流有标识 (2) 多路复用（Multiplexing） 无队头阻塞的多路复用，避免旧版的队头阻塞，允许在同一个 TCP 连接上并行发送多个请求和响应, (3) 头部压缩（Header Compression） 对于相同的数据，不再通过每次请求和响应发送 (4) 服务器推送（Server Push） 服务器可以在客户端请求之前，主动将资源推送到客户端。 减少客户端请求的往返时间（RTT），提升页面加载速度。 (5) 流优先级（Stream Prioritization） 客户端可以为请求设置优先级，服务器根据优先级处理请求。 确保关键资源（如 CSS、JavaScript）优先加载。 3： udp， 采用quic协议，无队头阻塞的多路复用，丢包不阻塞 无队头阻塞的多路复用 1-RTT建连 ， 0-RTT连接建立 （Round-Trip Time，RTT） 无歧义重传

     1.  多路复用升级版
 * HTTP/2 的痛点：虽然支持多请求并发（多路复用），但底层 TCP 一旦丢包，所有请求被阻塞。
 * HTTP/3 的改进：QUIC 为每个请求分配独立流（Stream），丢包只影响当前流，其他流正常传输。

 2. 「快递车道」协议（QUIC）
 加密直接集成到协议中（强制 HTTPS）：再次连接：0-RTT 极速恢复
 QUIC 用 连接 ID 标识会话，IP 或网络变化时，无需重新握手，直接继续传输
 QUIC 还支持拥塞控制，它可以根据网络条件调整数据包的发送速率，以避免网络拥塞
 前向安全性
 	缺点：
 	QUIC协议更容易受到分布式拒绝服务（DDoS）
 	兼容性问题
 	较小数据包的传输速率较低
 	故障排除困难


 Keep-Alive解决的核心问题是： 一定时间内，同一域名多次请求数据，只建立一次 HTTP 请求，其他请求可复用每一次建立的连接通道
 Keep-Alive还是存在如下问题：
 串行的文件传输。
 同域并行请求限制带来的阻塞（6~8）个

    H、Service Worker 本质上是一种用 JavaScript 编写的脚本，其作为一个独立的线程， 它可以使应用程序能够控制网络请求，缓存这些请求以提高性能，并提供对缓存内容的离线访问。

     Service Worker 缓存是持久的，独立于浏览器缓存或网络状态

    同时出于安全考虑，Service worker 只能在 https 及 localhost 下被使用。

  4. 建立TCP连接，三次握手; 确认双方的接收和发送能力 客户端：你好，你听得到么。（客户端发送能力） 服务器：你好，我听得到，你听得到么？（服务器：接收能力、响应能力） 客户端：我也听得到。（客户端接收能力）

    关闭TCP连接，四次挥手； 1. A要断开了，2. B同意， 3. B可以断开 4. A断开

     客户端：我没什么要说的了，我们分手吧。（客户端没有数据发送了）
 服务器：好的，我们分手吧。（服务器同意分手）
 服务器：我也没什么要说的了，我们分手吧。（服务器没有数据推送了）
 客户端：好的，我们分手吧。（客户端知道服务器没有数据了，果断分手）

  5. 输入网址到网页显示，背后发生了什么？ 1、浏览器解析URL 2、DNS域名解析 3、浏览器与服务器建立三次握手 4、浏览器向服务器发送HTTP请求报文 5、服务器给浏览器发送HTTP响应报文以及首页的HTML文件 6、浏览器渲染HTML页面 7、浏览器和服务器四次挥手，断开连接

    URL解析：浏览器首先会对输入的URL进行解析，包括协议、域名、端口、路径、查询参数等。 DNS解析：浏览器会通过DNS解析将域名解析为IP地址。 组装HTTP请求：浏览器会根据解析后的IP地址，组装HTTP请求 检查缓存：浏览器在发送请求前会检查是否有缓存，有缓存则直接使用缓存，否则发送请求。（html一般不缓存的，这步略过） 建立TCP连接：浏览器会与服务器建立TCP连接，包括三次握手。 发送HTTP请求：浏览器会向服务器发送HTTP请求，包括请求行、请求头、请求体等。 服务器处理请求响应结果：服务器会根据请求的路径和参数，返回相应的资源 断开TCP连接：浏览器与服务器断开TCP连接，包括四次挥手。 解析HTML：浏览器会解析HTML，构建DOM树。 构建CSSOM树：浏览器会解析CSS，构建CSSOM树。 构建渲染树：浏览器会根据DOM树和CSSOM树，构建渲染树。 布局渲染树：浏览器会根据渲染树，计算每个节点的位置和大小。 绘制渲染树：浏览器会根据渲染树，绘制页面。 链接：juejin.cn/post/740477…

  6. https使用过吗 怎么保证安全 HTTP 是明文传输的，存在数据窃听、数据篡改和身份伪造等问题。而 HTTPS 通过引入 SSL/TLS，解决了这些问题。 SSL/TLS 在加密过程中涉及到了两种类型的加密方法：

    非对称加密：服务器向客户端发送公钥，然后客户端用公钥加密自己的随机密钥，也就是会话密钥，发送给服务器，服务器用私钥解密，得到会话密钥。 对称加密：双方用会话密钥加密通信内容

avatar
文章
阅读
粉丝