• HTTP网络知识

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

    产品性能优化方案

    • HTTP网络层优化

    • 代码编译层优化 webpack

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

    • 安全优化 xss + csrf

    • 数据埋点及性能监控

    • ……

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

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

    第一步：URL解析

    • 地址解析

    • 编码

    第二步：缓存检查

    缓存位置：

    • Memory Cache : 内存缓存

    • Disk Cache：硬盘缓存

    打开网页：查找 disk cache 中是否有匹配，如有则使用，如没有则发送网络请求
    普通刷新 (F5)：因TAB没关闭，因此memory cache是可用的，会被优先使用，其次才是disk cache
    强制刷新 (Ctrl + F5)：浏览器不使用缓存，因此发送的请求头部均带有 Cache-control: no-cache，服务器直接返回 200 和最新内容

    强缓存 Expires / Cache-Control

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

    • Expires：缓存过期时间，用来指定资源到期的时间（HTTP/1.0）

    • Cache-Control：cache-control: max-age=2592000第一次拿到资源后的2592000秒内（30天），再次发送请求，读取缓存中的信息（HTTP/1.1）

    • 两者同时存在的话，Cache-Control优先级高于Expires

    协商缓存 Last-Modified / ETag
    协商缓存就是强制缓存失效后，浏览器携带缓存标识向服务器发起请求，由服务器根据缓存标识决定是否使用缓存的过程 

    数据缓存 

    第三步：DNS解析

    • 递归查询

    • 迭代查询

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

    • 减少DNS请求次数

    • DNS预获取（DNS Prefetch）

    1. "x-dns-prefetch-control" content="on">
    2.  
    3. <link rel="dns-prefetch" href="//static.360buyimg.com"/>
    4.  
    5. <link rel="dns-prefetch" href="//misc.360buyimg.com"/>
    6.  
    7. <link rel="dns-prefetch" href="//img10.360buyimg.com"/>
    8.  
    9. <link rel="dns-prefetch" href="//d.3.cn"/>
    10.  
    11. <link rel="dns-prefetch" href="//d.jd.com"/>

    服务器拆分的优势

    • 资源的合理利用

    • 抗压能力加强

    • 提高HTTP并发、

    • ……

    第四步：TCP三次握手

    • seq序号，用来标识从TCP源端向目的端发送的字节流，发起方发送数据时对此进行标记

    • ack确认序号，只有ACK标志位为1时，确认序号字段才有效，ack=seq+1

    • 标志位

      • ACK：确认序号有效

      • RST：重置连接

      • SYN：发起一个新连接

      • FIN：释放一个连接

      • ……

    三次握手为什么不用两次，或者四次?
    TCP作为一种可靠传输控制协议，其核心思想：既要保证数据可靠传输，又要提高传输的效率！

    第五步：数据传输

    • HTTP报文

      • 请求报文

      • 响应报文

    • 响应状态码

      • 200 OK

      • 202 Accepted ：服务器已接受请求，但尚未处理（异步）

      • 204 No Content：服务器成功处理了请求，但不需要返回任何实体内容

      • 206 Partial Content：服务器已经成功处理了部分 GET 请求（断点续传 Range/If-Range/Content-Range/Content-Type:”multipart/byteranges”/Content-Length….）

      • 301 Moved Permanently

      • 302 Move Temporarily

      • 304 Not Modified

      • 305 Use Proxy

      • 400 Bad Request : 请求参数有误

      • 401 Unauthorized：权限（Authorization）

      • 404 Not Found

      • 405 Method Not Allowed

      • 408 Request Timeout

      • 500 Internal Server Error

      • 503 Service Unavailable

      • 505 HTTP Version Not Supported

      • ……

    第六步：TCP四次挥手

     

    为什么连接的时候是三次握手，关闭的时候却是四次握手？

    • 服务器端收到客户端的SYN连接请求报文后，可以直接发送SYN+ACK报文

    • 但关闭连接时，当服务器端收到FIN报文时，很可能并不会立即关闭链接，所以只能先回复一个ACK报文，告诉客户端：”你发的FIN报文我收到了”，只有等到服务器端所有的报文都发送完了，我才能发送FIN报文，因此不能一起发送，故需要四步握手。

    Connection: keep-alive

    第七步：页面渲染

    性能优化汇总

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

    HTTP1.0和HTTP1.1的一些区别

    • 缓存处理，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时就可以直接从缓存中获取到，不用再发请求了

    1. // 通过在应用生成HTTP响应头信息中设置Link命令
    2.  
    3. Link: </styles.css>; rel=preload; as=style, example.png>; rel=preload; as=image
    4.

    多路复用（MultiPlexing） 

    1. - HTTP/1.0 每次请求响应，建立一个TCP连接，用完关闭
    2.  
    3. - HTTP/1.1 「长连接」 若干个请求排队串行化单线程处理，后面的请求等待前面请求的返回才能获得执行机会，一旦有某请求超时等，后续请求只能被阻塞，毫无办法，也就是人们常说的线头阻塞；
    4.  
    5. - HTTP/2.0 「多路复用」多个请求可同时在一个连接上并行执行，某个请求任务耗时严重，不会影响到其它连接的正常执行；

     第一步：URL解析和第二步缓存检查

    1.  
    2.  第一步：URL解析
    3.     URI:URL+URN
    4.       + URI统一资源标识符
    5.       + URL统一资源定位符
    6.       + URN统一资源名称
    7.     传输协议：
    8.       + HTTP  超文本传输协议
    9.       + HTTPS  HTTP+SSL(加密证书),相对于HTTP来讲会更加安全
    10.       + FTP 文件的传输，例如：FTP上传工具、FTP资源共享...
    11.     域名：服务器有一个外网IP，基于外网IP找到服务器，而域名就是给外网IP设置一个好记忆的名字
    12.     端口号：区分同一台服务器上的不同服务(或项目)的
    13.       + 取值范围：0~65535
    14.       + 默认值：我们自己不写端口号，浏览器默认加的  HTTP->80  HTTPS->443  FTP->21
    15.     编码问题：如果URL地址或者问号传参的信息中，出现中文或者某些特殊符号，传输中可能会乱码，此时需要客户端先进行编码，服务器端再解码..
    16.       + encodeURI / decodeURI：一般用于对整个URL的编码，它只编码中文和部分特殊符号，对于URL地址中的有效符号不编码
    17.       + encodeURIComponent / decodeURIComponent：一般用于对URL问号传参的值进行部分编码，因为除了encodeURI可以编码的东西外，对于URL地址中的有效符号也能编码，所以不适合整个URL
    18.       + escape / unescape：不是所有后端语言都支持这个API，所以只用于客户端两个页面间数据传输的编译
    19.  
    20.   第二步：缓存检查
    21.     “缓存”存储在哪了？
    22.       + 虚拟内存（内存条）：页面关闭，存储的东西会消失  Memory Cache
    23.       + 物理内存（硬盘）：持久存储  Disk Cache
    24.     关于“静态资源文件”的缓存有两种：强缓存、协商缓存
    25.       + 不论哪一种都是服务器设置规则，客户端浏览器会自动配合完成，无需我们写代码
    26.       + 一般真实项目中，强缓存、协商缓存都会设置「也可以只设置一个」，强缓存失效的情况下，再去走协商缓存的机制
    27.     强缓存：Cache-Control(HTTP/1.1)、Expires(HTTP/1.0) 服务器设置的“响应头”信息
    28.       + cache-control: max-age=2592000
    29.       + expires: Sun, 15 May 2022 20:14:22 GMT
    30.       + 不论是从服务器获取，还是从缓存中读取，HTTP状态码都是200
    31.       问题：如果本地缓存生效，但是服务器更新了这个资源，如何保证客户端可以获取最新的？
    32.         + HTML页面资源“绝对不能”做强缓存，因为其实页面渲染的入口，所有其它资源也是在渲染解析HTML代码的时候，再去请求的！！
    33.  
    34.  
    35. // let url = `http://www.xx.com/首页.html?lx=0&name=珠峰@培训`;
    36. // console.log(encodeURI(url)); //'http://www.xx.com/%E9%A6%96%E9%A1%B5.html?lx=0&name=%E7%8F%A0%E5%B3%B0'
    37.  
    38. // let url = `http://www.xx.com/?lx=0&name=${encodeURIComponent('珠峰@培训')}&from=${encodeURIComponent('http://www.wx.com/')}`;
    39. // console.log(url); //'http://www.xx.com/?lx=0&name=%E7%8F%A0%E5%B3%B0%40%E5%9F%B9%E8%AE%AD&from=http%3A%2F%2Fwww.wx.com%2F'
    40.  
    41. // console.log(escape('珠峰@培训://')); //'%u73E0%u5CF0@%u57F9%u8BAD%3A//'
    42. // console.log(unescape('%u73E0%u5CF0@%u57F9%u8BAD%3A//')); //'珠峰@培训://'

    url解析----页面渲染

    1.  
    2.  第一步：URL解析
    3.     URI:URL+URN
    4.       + URI统一资源标识符
    5.       + URL统一资源定位符
    6.       + URN统一资源名称
    7.     传输协议：
    8.       + HTTP  超文本传输协议
    9.       + HTTPS  HTTP+SSL(加密证书),相对于HTTP来讲会更加安全
    10.       + FTP 文件的传输，例如：FTP上传工具、FTP资源共享...
    11.     域名：服务器有一个外网IP，基于外网IP找到服务器，而域名就是给外网IP设置一个好记忆的名字
    12.     端口号：区分同一台服务器上的不同服务(或项目)的
    13.       + 取值范围：0~65535
    14.       + 默认值：我们自己不写端口号，浏览器默认加的  HTTP->80  HTTPS->443  FTP->21
    15.     编码问题：如果URL地址或者问号传参的信息中，出现中文或者某些特殊符号，传输中可能会乱码，此时需要客户端先进行编码，服务器端再解码..
    16.       + encodeURI / decodeURI：一般用于对整个URL的编码，它只编码中文和部分特殊符号，对于URL地址中的有效符号不编码
    17.       + encodeURIComponent / decodeURIComponent：一般用于对URL问号传参的值进行部分编码，因为除了encodeURI可以编码的东西外，对于URL地址中的有效符号也能编码，所以不适合整个URL
    18.       + escape / unescape：不是所有后端语言都支持这个API，所以只用于客户端两个页面间数据传输的编译
    19.  
    20.   第二步：缓存检查
    21.     “缓存”存储在哪了？
    22.       + 虚拟内存（内存条）：页面关闭，存储的东西会消失  Memory Cache
    23.       + 物理内存（硬盘）：持久存储  Disk Cache
    24.     关于“静态资源文件”的缓存有两种：强缓存、协商缓存
    25.       + 不论哪一种都是服务器设置规则，客户端浏览器会自动配合完成，无需我们写代码
    26.       + 一般真实项目中，强缓存、协商缓存都会设置「也可以只设置一个」，强缓存失效的情况下，再去走协商缓存的机制
    27.     强缓存：Cache-Control(HTTP/1.1)、Expires(HTTP/1.0) 服务器设置的“响应头”信息
    28.       + cache-control: max-age=2592000
    29.       + expires: Sun, 15 May 2022 20:14:22 GMT
    30.       + 不论是从服务器获取，还是从缓存中读取，HTTP状态码都是200
    31.       问题：如果本地缓存生效，但是服务器更新了这个资源，如何保证客户端可以获取最新的？
    32.         + HTML页面资源“绝对不能”做强缓存，因为其实页面渲染的入口，所有其它资源也是在渲染解析HTML代码的时候，再去请求的！！
    33.     协商缓存：哪怕本地有缓存也要去和服务器进行协商
    34.       第一次请求页面，本地没有缓存，向服务器发送请求，如果需要设置协商缓存，服务器会在响应头中返回：Last-Modified（记录资源最后一次更新的时间） / ETag（记录资源最后一次更新的标识）；客户端浏览器看到标识后，把标识和资源都缓存起来！！
    35.       第二次请求，也会向服务器发送请求，并且在请求头中，基于If-Modified-Since/If-None-Math分别把存储的Last-Modified/ETag值传递给服务器；服务器获取标识后，和本地资源(最新更新时间/标识)做对比；
    36.         + 如果资源没有更新过，则时间/标识是一致的，服务器返回304；客户端发现是304，则从本地缓存中获取；
    37.         + 如果资源更新了，则时间/标识是不一样的，服务器返回200和最新的内容以及最新的Last-Modified/ETag；客户端在把最新的信息存储起来!!
    38.       ......
    39.     ===>真实项目开发，建议大家：HTML页面只设置协商缓存、其余的静态资源强缓存和协商缓存都去设置！！
    40.     数据缓存：前端开发者，基于本地存储方案，对于“不经常更新”的数据请求，做的缓存处理
    41.       + 第一次从服务器获取数据，存储在本地「设置一个有效周期」
    42.         本地存储方案：受“源”和“浏览器”的限制
    43.           + cookie
    44.             具备有效期，设置cookie的时候自己设置
    45.             最多只允许存储4KB的内容
    46.             cookie和服务器有猫腻：在非跨域请求下，如果本地有cookie，不论服务器是否需要，每一次发送请求，都默认把cookie基于请求头传递给服务器「利：如果需要把cookie传递给服务器，我们比较省心；弊：cookie比较多，每一次请求都携带大量的信息进行传递，把请求变慢！」
    47.             cookie不稳定：清除历史记录、安全卫士清理垃圾可能会清除掉cookie；浏览器的隐私或者无痕模式，不记录cookie！
    48.           + localStorage
    49.             持久化存储，除非自己手动删除或者卸载浏览器
    50.             最多允许存储5MB的内容
    51.             localStorage默认和服务器是没有关系的，除非自己手动把它存的信息传递给服务器！！
    52.             localStorage相对比较稳定一些！！
    53.           + sessionStorage
    54.             会话存储，页面刷新存储的信息会在；页面关闭，存储的信息会消失；
    55.           + 虚拟内存存储「例如：全局变量、vuex、redux」
    56.             页面刷新或者关闭，存储的信息都会释放！！
    57.           + ...
    58.       + 以后再发送请求，我们校验本地是否有此数据的缓存(而且是否在有效期内)
    59.         + 如果没有：向服务器发送新的请求，获取最新的数据
    60.         + 如果有：直接从本地存储的数据中拿出来渲染
    61.  
    62.   第三步：DNS解析「域名解析」
    63.     浏览器地址栏输入域名，会去DNS服务器上找到对应的外网IP，然后基于服务器的外网IP，找到服务器！！
    64.     DNS解析记录也会有缓存「谷歌浏览器大概记录1min」
    65.     ----
    66.     前端优化：尽可能减少DNS解析需要的时间
    67.       + 正常：减少DNS解析的次数（也就是所有资源，尽可能都部署到，相同服务器的相同服务下）
    68.       + 真实：我们会把不同资源分不同的服务器部署「Web服务器、图片服务器、数据服务器...」
    69.         + 合理使用资源
    70.         + 提高并发数
    71.         + ...
    72.         导致域名解析的次数增加，DNS解析需要的时间也会增加
    73.     DNS Prefetch：DNS预解析，利用的异步性，在GUI渲染过程中，同时去解析域名
    74.  
    75.   第四步：TCP的三次握手「让客户端和服务器端建立一个“稳定可靠”的传输通道」
    76.     + TCP：稳定可靠，因为经过三次握手确定传输的稳定性，消耗时间久！！ ---> 常规业务都是用它
    77.     + UDP：快速传输，省略三次握手的步骤，直接进行传输；可能存在丢包的情况！！  --->  一般用于直播的业务中
    78.  
    79.   第五步：数据传输
    80.     + HTTP请求报文：请求头、请求起始行、请求主体
    81.     + HTTP响应报文：响应头、响应起始行、响应主体
    82.     -----在控制台的NetWork中都可以看到
    83.  
    84.   第六步：TCP的四次挥手「断开客户端和服务器端的连接通道」
    85.     + HTTP/1.1版本开始，默认开启了Connection: keep-alive长连接；当前请数据传输完成后，建立的通道不会被立即释放，下一次请求，继续基于这个通道传输，减少TCP三握四挥的规程，加快数据传输的速度！！
    86.     + 我们在Nginx配置的时候，可以设置keep-alive的周期「根据传输的数量 或者 设置时间」
    87.     + 在客户端把信息传递给服务器之后，四次挥手就已经开始了！！
    88.  
    89.   第七步：页面渲染
    90.     + DOM TREE
    91.     + CSSOM TREE
    92.     + RENDER TREE
    93.     + Layout「回流/重排」
    94.     + 分层
    95.     + Painting
    96.  
    97.  
    98.  
    99. let package_storage = _.storage.get('package_storage', 10000);
    100. if (package_storage) {
    101.   // 本地缓存生效，直接从本地获取即可
    102.   console.log('成功「缓存」:', package_storage);
    103. } else {
    104.   // 本地没有获取失效，则从服务器获取
    105.   axios.get(`./package.json?_=${+new Date()}`)
    106.     .then(response => {
    107.       console.log('成功「服务器」:', response.data);
    108.       // 获取后存储到本地
    109.       _.storage.set('package_storage', response.data);
    110.     });
    111. } 
    112.  
    113.  
    114. /* 设定具备有效期的localStorage存储方案 */
    115.     const storage = {
    116.         set(key, value) {
    117.             // 存储的时候,记录存储的时间
    118.             localStorage.setItem(key, JSON.stringify({
    119.                 time: +new Date(),
    120.                 value
    121.             }));
    122.         },
    123.         get(key, cycle = 60000) {
    124.             // 默认有效期是1分钟
    125.             cycle = +cycle;
    126.             if (isNaN(cycle)) cycle = 60000;
    127.             let data = localStorage.getItem(key);
    128.             if (!data) return null;
    129.             let { time, value } = JSON.parse(data);
    130.             if ((+new Date() - time) > cycle) {
    131.                 // 超过有效期,也不获取值
    132.                 storage.remove(key);
    133.                 return null;
    134.             }
    135.             // 在有效期内,才获取值
    136.             return value;
    137.         },
    138.         remove(key) {
    139.             localStorage.removeItem(key);
    140.         }

     强缓存和协商缓存都是在nginx上配置，数据缓存是前端自己写代码

  • 相关阅读:
    C#手动填充DataSet
    Collections和CollectionUtils集合操作
    完整javaEE学生信息管理系统
    《设计模式》桥接模式
    Springboot添加静态资源映射addResourceHandlers，可实现url访问
    2022最新解析最清晰 Java 系列面试题
    算法设计与分析-0/1背包问题
    详解Spring Boot中@PostConstruct的使用
    国民经济行业代码查询系统-公司行业代码查询
    SQL优化
  • 原文地址：https://blog.csdn.net/weixin_60968779/article/details/125774620