彻底掌握基于HTTP网络层的 “前端性能优化”

叮当猫逃跑了
400 阅读18分钟

产品性能优化方案

  • HTTP网络层优化

  • 代码编译层优化 webpack

  • 代码运行层优化 html/css + javascript + vue + react

  • 安全优化 xss + csrf

  • 数据埋点及性能监控

    ……

    CRP（Critical [ˈkrɪtɪkl] Rendering [ˈrendərɪŋ] Path）关键渲染路径

从输入URL地址到看到页面，中间都经历了啥

第一步：URL解析

URI=URL+URN

URI：统一资源标识符

URL:统一资源定位符[URL地址]

URN:统一资源名称

地址解析

下载.png

1. 传输协议：http / https /ftp :客户端和服务器端传输信息的方式“快递小哥”

  • http:超文本传输协议

  • https:http ssl 比http更加安全，因为经过ssl加密【一般支付类网站使用】

  • ftp:文件上传下载协议【往服务器端上传资源等->ftp上传工具:FileZilla】 2. 域名：购买服务器后，一般都有一个外网IP地址，基于这个外网地址可以找到服务器；但是没有人能记住这个IP，所以我们会设置一个让别人好记忆的名字，这个名字就是“域名”

  • 外网IP：供外部访问

  • 内网IP：局域网访问

    • 移动端测试：手机端和电脑端连接同一个局域网，首先保证PC端使用本地局域网IP可以正常访问项目，这样在手机浏览器访问相同的地址，也可以访问到这个项目...{可能需要关闭电脑防火墙}
  • 顶级域名:qq.com
  • 一级域名：www.qq.com
  • 二级域名：sports.qq.com
  • 三级域名：kbs.sports.qq.com com[国际的]、cn[中国的]、org[官方的]、gov[官方政府]、edu[教育]、net[管理系统]、vip......

3. 端口号：0~65535 区分同一台服务器的不同项目的

  • 默认端口号：我们自己不写，浏览器会自己帮我们写上；
    • http->80
    • https->443
    • ftp->21 4.hash值的作用：锚点定位 、哈西路由、

URL编码

  1. encodeURL 编码 & decodeURL 解码 编码整个URL{编码空格和中文}
  2. encodeURLComponent & decodeURLComponent 只编码？传递的参数值{它的编码规则比较多，类似于：//这样的特殊字符也会编码}

上述两种处理前后端通信中的编码解码

  1. escape & UNescape 也可以实现编码解码，但是只能客户端不同页面之间自已用，因为很多后台都不支持这个API

第二步：缓存检查

  • 缓存位置：
    • Memory Cache : 内存缓存
    • Disk Cache：硬盘缓存
  1. 打开网页：查找 disk cache 中是否有匹配，如有则使用，如没有则发送网络请求
  2. 普通刷新 (F5)：因TAB没关闭，因此memory cache是可用的，会被优先使用，其次才是disk cache
  3. 强制刷新 (Ctrl + F5)：浏览器不使用缓存，因此发送的请求头部均带有 Cache-control: no-cache，服务器直接返回 200 和最新内容 先检查是否存在强缓存，如果存在则使用强缓存信息；如果不存在则再检测协商缓存，如果协商缓存生效，则使用协商缓存信息，如果不生效，则从服务器重新拉取资源信息 但是两种缓存针对的都是资源文件【HTML css js....】,而基于ajax等获取数据

强缓存 Expires / Cache-Control【服务器来设置的】

  • 如果获取的是强缓存信息，HTTP状态码是200
  • 如果是从服务器获取信息，HTTP状态码是200

HTML页面基本上不做强缓存

  • 一个页面的渲染都是从HTML开始的，在渲染HTML代码的时候，再去发送其他资源（例如：css、js、图片）的请求，一旦HTML都做强缓存，完了，接下来有效期内处理Ctrl+F5刷新处理，只要访问这个页面，用的都是本地缓存的内容，即使人家服务器已经把内容更新了，你也拿不到....

如何保证其他资源在服务器更新后，即使本地有对应的强缓存信息，我们也能及时更新

  1. 请求文件后面设置时间戳
  2. 文件的名字根据内容更改后，设置不同的HASH名
//第一次请求 index.html
<link href ='css/index.css?20210526181400'> 时间戳一般放文件最后一次“修改”的时间
缓存了index.css?202105261814002

浏览器对于强缓存的处理：根据第一次请求资源时返回的响应头来确定的

  • Expires：缓存过期时间，用来指定资源到期的时间（HTTP/1.0）
  • Cache-Control：cache-control: max-age=2592000第一次拿到资源后的2592000秒内（30天），再次发送请求，读取缓存中的信息（HTTP/1.1）
  • 两者同时存在的话，Cache-Control优先级高于Expires 下载 (1).png

协商缓存 Last-Modified / ETag

协商缓存就是强制缓存失效后，浏览器携带缓存标识向服务器发起请求，由服务器根据缓存标识决定是否使用缓存的过程 下载 (2).png

  • 第一次请求： 无协商缓存对应的标识，则直接向服务器发送请求，而服务器直接将资源信息给客户端【同样也会在响应头中设置对应字段：last-modified（存储当前文件在服务器最后修改的时间） & Etag（服务器把当前文件修改后，可以生成一个唯一的标识）给客户端；客户端获取到内容后，把资源文件和标识都缓存到本地】
  • 第二次请求： 我们需要把本地存储的last-modified或Etag基于请求头中的if-modified-since /if-none-match这俩个字段，传递给服务器；服务器收到对应的标识后，会去检查现有的服务器文件最后修改的时间，和你传递给我的时间是否一致；
    • 如果一致的，说明这个文件从上一次请求到现在没有修改过，服务器无需重新返回这个文件信息，只需要返回304状态码即可；客户端获取到304状态码，会从本地缓存中读取信息进行渲染
    • 如果不一致，说明服务器的文件修改过，此时服务器返回200的状态码，并且把最新的资源及最新的last-modified/Etag都返回给客户端；客户端从新存储到本地和渲染即可...
  • html资源不能做强缓存，但是可以做协商缓存，其他资源既可以做强缓存也可以做协商缓存【很多项目中是两者都做的】

数据缓存 ☆☆☆☆☆

基于ajax和fetch获取的数据如何做缓存

  • 对于页面中不经常更新的数据我们期望能够做一下缓存，【缓存周期可以自己来定】
  • 本地存储的解决方案：
  • 控制台->application[可以看到本地存储的信息（明文->不安全）]

不论何种方案，存储到本地的信息，如果一些比较隐私的，最好不存储，存储也一定要加密

  1. cookie
    • 通过document.cookie设置和获取
    • 兼容所有浏览器
    • cookie能存储的信息比较少：同源下：同源下最多可以存储4KB内容
    • cookie是有过期时间和“域”的限制的【不能跨域访问】
    • cookie存储的信息非常不稳定【1.浏览器的无痕模式或无痕浏览器是存储不上cookie 】【2.而且基于浏览器清理工具或一些杀毒软件，清理垃圾时，有可能把没有过期的cookie给清理掉】
    • cookie并不是单纯的本地存储，和服务器之间有“猫腻”的：每一次向服务器发送请求，客户端都会在请求头中基于cookie字段，把本地存储的cookie传递给服务器
    • ..... 2.webstorage H5新增的
  • localStorage
    1. localStorage.setItem([key],[value])
    2. localStorage.getItem([key])
    3. localStorage.removeItem([key])
    4. localStorage.clear()
    5. 特点：：不兼容IE 678
      • 同源下最多可存储5MB，比cookie存储很多
      • 永久本地存储，没有过期时间，【除非手动清除，或者卸载浏览器】
      • 也会受到跨域和浏览器的限制
      • 稳定性非常好，清理垃圾的时候，对他没影响。
      • 和服务器没有关系
  • sessionStorage
    1. 语法和特点与localStorage基本一致
    2. 区别
      • sessionStorage是会话存储，基于他设置的信息，只要页面不关闭（哪怕F5刷新），信息都在，但是页面一旦关闭，存储的信息都清空了；localStorage是持久存储，不论是刷新还是页面关闭，信息都在。 3.IndexDB 本地数据库存储
  • WebSQL 4. 全局变量 & 公共状态管理（vuex/redux）
  • 都只在开辟的堆栈内存中存储，页面只要刷新或关闭，信息都没了

同源：（协议、域名、端口号三者完全一样->同源）

非同源（跨域）：三者只要有一个不一样就是跨域

下载.png

第三步：DNS解析

DNS解析定义

定义： 如果想找到服务器，则需要基于服务器的外网IP；旦外网IP太难记，需要买个域名好记一些，我们需要根据域名找打服务器外网IP【去DNS服务器上查找】....=>这个操作叫DNS解析

  • 发布项目流程
    • 买域名->域名解析[域名备案]{把域名和外网IP放到DNS服务器上}
  • 递归查找
  • 迭代查找 下载 (1).png

每一次DNS解析时间预计在20~120毫秒

  • 减少DNS请求次数
  • DNS预解析（DNS Prefetch）
  • DNS解析是缓存的
    • 当前如果我们解析过这个域名，则会把解析记录缓存到本地，所以每一次DNS解析一定要经历俩步骤
      • 本地DNS解析缓存查找
      • 本地没有缓存记录，则在去公网DNS服务器上去查找【迭代查找】

DNS优化技巧

  1. 减少DNS解析次数【资源都放在一个服务器/一个域名下，这样解析一次就够了】
    • 但是真实项目上不这样做，我们会分散到不同的服务器上，这样带来的问题是，需要解析更多域名
      • @1服务器的资源的合理利用
      • @2提高HTTP同时并发的数量【同源下，同时允许最多的HTTP并发数5~7个】
      • @3提高抗压能力 .....
    • 在DNS解析次数增加的情况下，我们基于“DNS与获取（DNS Prefetch）”进行优化

第四步：TCP三次握手

定义

当我们获取到服务器外网IP，通过外网IP找到服务器，让客户端和服务器端建立连接通道,，而三次握手建立一套稳定的通道，

传输控制协议: TCP / UDP....

  • TCP:是安全可靠地，但是消耗时间
  • UDP：不稳定的传输通道，但是比较快【不需要经过3次握手】
  • seq序号，用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记
  • ack确认序号，只有ACK标志位为1时，确认序号字段才有效，ack=seq+1
  • 标志位
    • ACK：确认序号有效
    • RST：重置连接
    • SYN：发起一个新连接
    • FIN：释放一个连接 …… 下载.png

第五步：数据传输

  • 获取当前浏览器的版本信息：navigator-userAgent

客户端想把信息传递给服务器？

  • 设置请求头【含cookie信息】
  • 设置请求主体
  • 设置URL地址的问号传参

服务器想把信息返回给客户端？

  • 设置响应头【含服务器时间】
  • 设置相应主体

HTTP报文

  • 请求报文
  • 响应报文

http报文：客户端和服务器端所有的通信信息，统称为HTTP报文[谷歌浏览器控制台->network中都可以看到]

  • 起始行：请求起始行、响应起始行
  • 首部：请求头、响应头【包含：自定义的请求/响应头】
  • 主体：请求主体、响应主体

请求起始行+请求头+请求主体，包含了客户端给服务器的所有信息【请求阶段Request】；同理，响应起始行+响应头+响应主体，包含了服务器给客户端的所有信息【响应阶段Response】；一个完整的HTTP事务

微信图片_20210531171314.png

请求方式

  • GET(get/head/delete/options...)：从服务器获取【一般是给服务器的少，从服务器拿的多】
  • POST(post/put/patch...)：向服务器推送信息【一般是给服务器的多，服务器返回的少】
  • HEAD：只获取响应头的信息，服务器不会返回任何响应主体的信息
  • xhr的状态 xhr.readyState
    • UNSENT: 0 当你创建出实例，readyState就是0
    • OPENED: 1 当open执行就会从0变成1
    • HEADERS_RECEIVED: 2 响应头信息已经返回
    • LOADING: 3 响应体正在接收（在返回的路上）
    • DONE: 4 当响应主体信息返回
  • DELETE:删除服务器端的文件
  • PUT：向服务器存放文件
  • options：试探性请求，在cors跨域资源共享，发送真正的请求之前，先发送一个试探性请求，验证客户端和服务器端是否实现通信，可以通信，再去发送真正请求 1. 从服务器获取静态资源文件（HTML/CSS/JS/图片）都是GET请求，一般在AJAX/fetch数据请求中才会遇到其余的请求方式

2. 不论是那一种方式，客户端肯定能把信息给服务器，服务器也可以把信息返回给客户端

GET和POST的区别

约定规范：

  1. get请求，需要基于URL的问号传参，把信息传递给服务器
  2. post请求，是基于请求主体，把信息传递给服务器的【格式：application/json、application/x-www-form-urlencoded、multipart/from-data】；
  3. get系列传递给服务器的信息是有大量限制的【浏览器对于URL长度是有限制的IE一般是2KB，谷歌一般是8KB】，post理论上是没有的【旦显示开发中，为保证传输效率，我们自己会限制大小】
  4. get相对于post来说不安全，【俩者都不安全；对于重要信息传输，一定要加密】
  5. get会产生缓存【俩次请求地址参数等信息都一样，则第二次请求很可能是拿到上一次缓存的结果】解决办法：在每次请求末尾加一个随机数或时间戳，保证每一次请求不一样，

HTTP响应状态码

以2开头

  • 200 OK
  • 202 Accepted ：服务器已接受请求，但尚未处理（异步）
  • 204 No Content：服务器成功处理了请求，但不需要返回任何实体内容
  • 206 Partial Content：服务器已经成功处理了部分 GET 请求（断点续传 Range/If-Range/Content-Range/Content-Type:”multipart/byteranges”/Content-Length….）

以3开头

  • 301 Moved Permanently 永久重定向「域名迁移」
  • 302 Move Temporarily 临时重定向 「负载均衡、登录」（大网站常用）
  • 304 Not Modified 一个附带条件的请求，但未找到与条件有关的内容（与重定向无关）
  • 305 Use Proxy 使用代理

以4开头

  • 400 Bad Request : 请求参数有误
  • 401 Unauthorized：权限（Authorization）
  • 403 Forbidden 服务器拒绝执行「拒绝原因可能会以响应主体返回」
  • 404 Not Found 地址错误，也可以在服务器拒绝访问并不想返回具体原因时使用
  • 405 Method Not Allowed 请求方式不被允许
  • 408 Request Timeout 请求超时

以5开头

  • 500 Internal Server Error 未知服务器错误
  • 502 Bad Gateway 作为网关或者代理工作的服务器尝试执行请求时，从上游服务器接收到无效的响应。
  • 503 Service Unavailable 超负荷
  • 505 HTTP Version Not Supported HTTP版本不支持 ……

第六步：TCP四次挥手

断开客户端和服务器之间的连接通道

  1. 当客户端把信息给服务器后，会主动发送一个释放通道的请求 下载 (1).png 为什么连接的时候是三次握手，关闭的时候却是四次握手？
  • 服务器端收到客户端的SYN连接请求报文后，可以直接发送SYN+ACK报文【客户端把信息给服务器，告诉服务器，我把东西给你了，你注意查收，我要断开连接】
  • 但关闭连接时，当服务器端收到FIN报文时，很可能并不会立即关闭链接，所以只能先回复一个ACK报文，告诉客户端：”你发的FIN报文我收到了”，只有等到服务器端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送，故需要四步握手。

如果每一次前后端通道都需要握手和挥手，则性能消耗比较大；我们期望建立连接后，先别着急断开，后续有请求，则还是基于这个通道传输即可->Connection: keep-alive[如果HTTP1.0版本，需要自己设置，但是如果是HTTP1.1版本{目前最常用}，则默认就设置为长链接]

第七步：页面渲染

性能优化汇总

  1. 利用缓存
  • 对于静态资源文件实现强缓存和协商缓存（扩展：文件有更新，如何保证及时刷新？）
  • 对于不经常更新的接口数据采用本地存储做数据缓存（扩展：cookie / localStorage / vuex|redux 区别？）
  1. DNS优化
  • 分服务器部署，增加HTTP并发性（导致DNS解析变慢）
  • DNS Prefetch
  1. TCP的三次握手和四次挥手
  • Connection:keep-alive
  1. 数据传输
  • 减少数据传输的大小
  • 内容或者数据压缩（webpack等）
  • 服务器端一定要开启GZIP压缩（一般能压缩60%左右）
  • 大批量数据分批次请求（例如：下拉刷新或者分页，保证首次加载请求数据少）
  • 减少HTTP请求的次数
  • 资源文件合并处理
  • 字体图标
  • 雪碧图 CSS-Sprit
  • 图片的BASE64
  • ......
  1. CDN服务器“地域分布式”
  2. 采用HTTP2.0
  • ============== 网络优化是前端性能优化的中的重点内容，因为大部分的消耗都发生在网络层，尤其是第一次页面加载，如何减少等待时间很重要“减少白屏的效果和时间”
  • LOADDING 人性化体验
  • 骨架屏：客户端骨屏 + 服务器骨架屏
  • 图片延迟加载
  • ....

HTTP1.0 VS HTTP1.1 VS HTTP2.0

下载.png

  • 缓存处理，HTTP1.0中主要使用 Last-Modified，Expires 来做为缓存判断的标准，HTTP1.1则引入了更多的缓存控制策略：ETag，Cache-Control…

  • 带宽优化及网络连接的使用，HTTP1.1支持断点续传，即返回码是206（Partial Content）

  • 错误通知的管理，在HTTP1.1中新增了24个错误状态响应码，如409（Conflict）表示请求的资源与资源的当前状态发生冲突；410（Gone）表示服务器上的某个资源被永久性的删除…

  • Host头处理，在HTTP1.0中认为每台服务器都绑定一个唯一的IP地址，因此，请求消息中的URL并没有传递主机名（hostname）。但随着虚拟主机技术的发展，在一台物理服务器上可以存在多个虚拟主机（Multi-homed Web Servers），并且它们共享一个IP地址。HTTP1.1的请求消息和响应消息都应支持Host头域，且请求消息中如果没有Host头域会报告一个错误（400 Bad Request）

  • 长连接，HTTP1.1中默认开启Connection： keep-alive，一定程度上弥补了HTTP1.0每次请求都要创建连接的缺点

HTTP2.0和HTTP1.X相比的新特性

  • 新的二进制格式（Binary Format），HTTP1.x的解析是基于文本，基于文本协议的格式解析存在天然缺陷，文本的表现形式有多样性，要做到健壮性考虑的场景必然很多，二进制则不同，只认0和1的组合，基于这种考虑HTTP2.0的协议解析决定采用二进制格式，实现方便且健壮

  • header压缩，HTTP1.x的header带有大量信息，而且每次都要重复发送，HTTP2.0使用encoder来减少需要传输的header大小，通讯双方各自cache一份header fields表，既避免了重复header的传输，又减小了需要传输的大小

  • 服务端推送（server push），例如我的网页有一个sytle.css的请求，在客户端收到sytle.css数据的同时，服务端会将sytle.js的文件推送给客户端，当客户端再次尝试获取sytle.js时就可以直接从缓存中获取到，不用再发请求了

// 通过在应用生成HTTP响应头信息中设置Link命令
Link: </styles.css>; rel=preload; as=style, </example.png>; rel=preload; as=image
  • 多路复用（MultiPlexing）
- HTTP/1.0  每次请求响应，建立一个TCP连接，用完关闭
- HTTP/1.1 「长连接」 若干个请求排队串行化单线程处理，后面的请求等待前面请求的返回才能获得执行机会，一旦有某请求超时等，后续请求只能被阻塞，毫无办法，也就是人们常说的线头阻塞；
- HTTP/2.0 「多路复用」多个请求可同时在一个连接上并行执行，某个请求任务耗时严重，不会影响到其它连接的正常执行；
avatar
文章
阅读
粉丝