我的笔记

啦啦啦007
412 阅读21分钟

前端缓存

image.png

  1. 前端缓存

前端优化

image.png

image.png

网络层面

请求过程优化

  1. 减少 HTTP 请求

  2. 使用 HTTP2

  3. 使用服务端渲染

    客户端渲染: 获取 HTML 文件，根据需要下载 JavaScript 文件，运行文件，生成 DOM，再渲染。 服务端渲染：服务端返回 HTML 文件，客户端只需解析 HTML。

    优点：首屏渲染快，SEO 好。
    缺点：配置麻烦，增加了服务器的计算压力。

  4. 静态资源使用 CDN

  5. DNS 预解析 （采用DNS Prefetch 一种DNS 预解析技术）

<link rel="dns-prefetch" href="www.baidu.com" />
//只有部分浏览器支持

6.压缩 (采用Gzip压缩)

减少不必要的请求（浏览器缓存）
  1. 强缓存
  2. 协商缓存（对比缓存）
  3. CDN缓存
  4. 预加载
<link rel='prefetch' href='main.js'>
//只有部分浏览器支持

5. 预渲染

<link rel='prerender' href='http://www.a.com'> 
//只有部分浏览器支持

6. 应用缓存(Cookie,Storage,Service Worker)

浏览器渲染层面优化

1. 优化资源加载

  • CSS文件放在head中，先外链，后本页 　
  • JS文件放在body底部，先外链，后本页
  • 异步script标签 （defer: 异步加载，在HTML解析完成后执行。defer的实际效果与将代码放在body底部类似async: 异步加载，加载完成后立即执行）

2.减少重绘回流

避免使用层级较深的选择器，避免使用CSS表达式，元素适当地定义高度或最小高度，给图片设置尺寸,不要使用table布局，能够使用CSS实现的效果，尽量使用CSS而不使用JS实现

前端性能优化（一）

前端性能优化的七大手段

前端性能优化 24 条建议（2020）

HTTP

超文本传输协议（英文：HyperText Transfer Protocol，缩写：HTTP）是一种用于分布式、协作式和超媒体信息系统的应用层协议。HTTP是万维网的数据通信的基础。

HTTP状态码

HTTP状态代码的第一个数字代表当前响应的类型：

  • 1xx消息——请求已被服务器接收，继续处理
  • 2xx成功——请求已成功被服务器接收、理解、并接受
  • 3xx重定向——需要后续操作才能完成这一请求
  • 4xx请求错误——请求含有词法错误或者无法被执行
  • 5xx服务器错误——服务器在处理某个正确请求时发生错误

image.png

image.png

HTTPS与HTTP的一些区别

  1. HTTPS协议需要到CA申请证书，一般免费证书很少，需要交费。

  2. HTTP协议运行在TCP之上，所有传输的内容都是明文，HTTPS运行在SSL/TLS之上，SSL/TLS运行在TCP之上，所有传输的内容都经过加密的。

  3. HTTP和HTTPS使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443。

  4. HTTPS可以有效的防止运营商劫持，解决了防劫持的一个大问题。

HTTPS之所以比HTTP更安全，主要在于它实现了数据的加密传输和服务器身份的验证，这通过SSL/TLS协议来完成。SSL/TLS协议在HTTPS中结合了对称加密和非对称加密两种加密方式，以充分利用它们各自的优势。以下是HTTPS如何实现比HTTP更安全的具体过程，以及对称加密和非对称加密在其中的应用：

HTTPS的安全性实现

  1. 数据加密：

    • HTTPS通过SSL/TLS协议对数据进行加密，确保在传输过程中数据的私密性，防止数据被窃取或篡改。

  2. 身份验证：

    • HTTPS能够验证服务器的身份，确保客户端正在与真正的服务器进行通信，而不是一个假冒的服务器。

  3. 数据完整性：

    • HTTPS能够检测数据在传输过程中是否被篡改，保证数据的完整性。

非对称加密的应用

  • 密钥交换：在HTTPS通信的初始阶段，即密钥交换阶段，使用非对称加密来安全地交换对称加密所需的会话密钥。这是因为非对称加密的公钥可以公开，私钥由接收方保密，发送方可以使用公钥加密数据，只有接收方使用私钥才能解密，从而保证了密钥交换的安全性。
  • 数字签名的生成与验证：HTTPS中的数字证书包含了服务器的公钥和由CA（证书颁发机构）签发的数字签名。数字签名是通过CA的私钥对服务器的公钥和其他信息进行加密生成的，用于验证证书的真实性。客户端使用CA的公钥解密数字签名，并与证书中的信息进行比较，以验证服务器的身份。

对称加密的应用

  • 在建立加密通信后：HTTPS在客户端和服务器之间建立加密通信后，使用对称加密方式来进行数据的传输。 这是因为对称加密的加密和解密使用相同的密钥，且加密速度快，适合大量数据的加密传输。
  • 会话密钥的生成：客户端根据双方同意的安全等级，生成一个对称加密使用的密钥，称为会话密钥。这个会话密钥用于后续的通信过程中加密和解密数据。

HTTPS的工作流程（简化版）

  1. 客户端发起请求：客户端使用HTTPS的URL访问服务器，要求建立SSL连接。
  2. 服务器响应：服务器收到请求后，将包含公钥的数字证书发送给客户端。
  3. 客户端验证证书：客户端验证证书的真实性，包括验证证书的颁发机构、有效期等。
  4. 生成会话密钥：客户端生成会话密钥，并使用服务器的公钥加密会话密钥后发送给服务器。
  5. 服务器解密会话密钥：服务器使用自己的私钥解密会话密钥。
  6. 加密通信：之后，客户端和服务器都使用会话密钥进行对称加密通信。

通过这个过程，HTTPS实现了比HTTP更高的安全性，保护了用户隐私和数据安全。

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

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

  2. 多路复用（MultiPlexing），即连接共享，即每一个request都是是用作连接共享机制的。一个request对应一个id，这样一个连接上可以有多个request，每个连接的request可以随机的混杂在一起，接收方可以根据request的 id将request再归属到各自不同的服务端请求里面。

  3. header压缩，如上文中所言，对前面提到过HTTP1.x的header带有大量信息，而且每次都要重复发送，HTTP2.0使用encoder来减少需要传输的header大小，通讯双方各自cache一份header fields表，既避免了重复header的传输，又减小了需要传输的大小。

  4. 服务端推送（server push），同SPDY一样，HTTP2.0也具有server push功能。

TCP/UDP

image.png

  • TCP：适用于对数据可靠性要求较高的应用场景，如文件传输、电子邮件和网页浏览等。这些应用需要确保数据的完整性和正确性，因此选择TCP作为传输层协议更为合适。
  • UDP：适用于对数据实时性要求较高的应用场景，如音频和视频流传输、网络游戏和实时通信等。这些应用对数据的实时性要求较高，但对数据的可靠性要求相对较低，因此选择UDP作为传输层协议更为合适。

浏览器输入URL后发生了什么

  • DNS解析
  • TCP连接
  • 发送HTTP请求
  • 服务器处理请求并返回HTTP报文
  • 浏览器解析渲染页面
  • 连接结束

image.png

三次握手

第一次握手： 客户端发送syn包(syn=x)到服务器，并进入SYN_SEND状态，等待服务器确认；

第二次握手： 服务器收到syn包，必须确认客户的SYN（ack=x+1），同时自己也发送一个SYN包（syn=y），即SYN+ACK包，此时服务器进入SYN_RECV状态；

第三次握手： 客户端收到服务器的SYN＋ACK包，向服务器发送确认包ACK(ack=y+1)，此包发送完毕，客户端和服务器进入ESTABLISHED状态，完成三次握手

四次挥手

与建立连接的“三次握手”类似，断开一个TCP连接则需要“四次握手”。

第一次挥手 主动关闭方发送一个FIN，用来关闭主动方到被动关闭方的数据传送，也就是主动关闭方告诉被动关闭方：我已经不 会再给你发数据了(当然，在fin包之前发送出去的数据，如果没有收到对应的ack确认报文，主动关闭方依然会重发这些数据)，但是，此时主动关闭方还可 以接受数据。

第二次挥手 被动关闭方收到FIN包后，发送一个ACK给对方，确认序号为收到序号+1（与SYN相同，一个FIN占用一个序号）。

第三次挥手 被动关闭方发送一个FIN，用来关闭被动关闭方到主动关闭方的数据传送，也就是告诉主动关闭方，我的数据也发送完了，不会再给你发数据了。

第四次挥手 主动关闭方收到FIN后，发送一个ACK给被动关闭方，确认序号为收到序号+1，至此，完成四次挥手。

为什么要进行三次握手，不是二次握手

假设不采用“三次握手”，那么只要server发出确认，新的连接就建立了。 由于现在client并没有发出建立连接的请求，因此不会理睬server的确认，也不会向server发送数据,但server却以为新的运输连接已经建立，并一直等待client发来数据。 这样，server的很多资源就白白浪费掉了。

为什么要四次挥手而不是三次

这是因为服务端在LISTEN状态下，收到客户端发送的断开连接的FIN报文后，可能会有数据未发送完成，需要继续发送，因此不能将确认消息和请求关闭消息同时发送，而是会先关闭接收服务回复确认消息，然后继续发送未完消息到客户端，直到发送结束，再发送请求关闭消息

浏览器输入URL后发生了什么
从输入URL到页面加载发生了什么 说说TCP,UDP和socket,Http之间联系和区别
HTTP1.0、HTTP1.1 和 HTTP2.0 的区别

TCP/IP协议详解

Get与Post区别

（1）Get请求的数据（参数）会显示在地址栏，而Post不会，所以，Post比Get更加安全。

（2）Post请求的参数存放到了请求实体中，而Get没有请求实体，Get是存储在请求行中。

（3）数据传输Post有优势：Get方式请求的数据不能超过2k，而Post 没有上限。

（4）浏览缓存Get有优势：Get具有数据缓存，而Post没有。

从优势角度看，数据传输使用Post，数据浏览查询使用Get。即查询时使用Get，其他时候使用Post。

image.png

前端安全

XSS（Cross Site Scripting）跨站脚本攻击

xss攻击又叫做跨站脚本攻击，主要是用户输入或通过其他方式，向我们的代码中注入了一下其他的js，而我们又没有做任何防范，去执行了这段js。

防范手段:
1.输入检查
2.输出检查
3.使用HttpOnly 通过设置HttpOnly，浏览器可以禁止页面的JavaScript访问带有HttpOnly属性的Cookie。它的目的并非是为了对抗XSS，而是对抗XSS之后的Cookie劫持攻击。

CSRF（Cross Site Request Forgy）跨站请求伪造

CSRF就是利用你所在网站的登录的状态，在我们不知情的情况下，利用我们登陆的账号信息，去模拟我们的行为，去执行一下操作，也就是所谓的钓鱼。比如我们在登陆某个论坛，但这个网站是个钓鱼网站，我们利用邮箱或者qq登陆后，它就可以拿到我们的登陆态，session和cookie信息。然后利用这些信息去模拟一个另外网站的请求，比如转账的请求。

防范手段:1.验证码
2.验证Referer
根据 HTTP 协议，在 HTTP 头中有一个字段叫Referer，它记录了该 HTTP 请求的来源地址。通过验证Referer，可以检查请求是否来自合法的"源"。
3.验证Token 服务端随机生成token，保存在服务端session中，同时保存到客户端中，客户端发送请求时，把token带到HTTP请求头或参数中，服务端接收到请求，验证请求中的token与session中的是否一致。如果请求中没有 token 或者 token 内容不正确，则认为可能是 CSRF 攻击而拒绝该请求。

浅谈前端安全
前端的安全问题
前端安全-常见的攻击以及防御

前端跨域

什么是跨域

跨域是浏览器的一个特性，就是浏览器从一个“域”向另一个“域”的服务器发出请求，来访问另一个“域”上的资源。但是，由于请求的文件可能会存在恶意攻击，浏览器并不允许直接访问另一个“域”上的资源，只能访问同一个“域”上的资源，这个就是“同源策略”。而所谓的“同源”，指的是“协议、域名、端口号”一致 同源策略限制以下几种行为：

1.) Cookie、LocalStorage 和 IndexDB 无法读取
2.) DOM 和 Js对象无法获得
3.) AJAX 请求不能发送

跨域解决方案

1.通过jsonp跨域

原理：动态添加一个script标签，而script标签的src属性是没有跨域的限制的。
缺点：只能发送get一种请求。

2、 跨域资源共享（CORS）

只服务端设置Access-Control-Allow-Origin即可，前端无须设置，若要带cookie请求：前后端都需要设置。 withCredentials: true // 前端设置是否带cookie

3.nodejs中间件代理跨域

vue框架的跨域（1次跨域） 利用node + webpack + webpack-dev-server代理接口跨域。在开发环境下，由于vue渲染服务和接口代理服务都是webpack-dev-server同一个，所以页面与代理接口之间不再跨域，无须设置headers跨域信息了。

1、 通过jsonp跨域
2、 document.domain + iframe跨域
3、 location.hash + iframe
4、 window.name + iframe跨域
5、 postMessage跨域
6、 跨域资源共享（CORS）
7、 nginx代理跨域
8、 nodejs中间件代理跨域
9、 WebSocket协议跨域

  node中间件实现跨域代理，原理大致与nginx相同，都是通过启一个代理服务器，实现数据的转发，也可以通过设置cookieDomainRewrite参数修改响应头中cookie中域名，实现当前域的cookie写入，方便接口登录认证。

前端常见跨域解决方案（全）

JWT----JSON Web Token(跨域认证解决方案)

Json web token (JWT), 是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准（(RFC 7519).该token被设计为紧凑且安全的，特别适用于分布式站点的单点登录（SSO）场景，该token也可直接被用于认证，也可被加密,是目前最流行的跨域认证解决方案!

JSON Web Token由三部分组成，它们之间用圆点(.)连接。这三部分分别是：

  • Header 是一个 JSON 对象，描述 JWT 的元数据,alg属性表示签名的算法（algorithm），默认是 HMAC SHA256（写成 HS256）；typ属性表示这个令牌（token）的类型（type），JWT 令牌统一写为JWT。

  • Payload 是一个 JSON 对象，用来存放实际需要传递的数据,如签发人,过期时间,主题,受众,生效时间,签发时间,编号

  • Signature 对前两部分的签名，防止数据篡改

Token 和 JWT 的区别

相同：

都是访问资源的令牌
都可以记录用户的信息
都是使服务端无状态化
都是只有验证成功后，客户端才能访问服务端上受保护的资源

区别：

Token：服务端验证客户端发送过来的 Token 时，还需要查询数据库获取用户信息，然后验证 Token 是否有效。
JWT：将 Token 和 Payload 加密后存储于客户端，服务端只需要使用密钥解密进行校验（校验也是 JWT 自己实现的）即可，不需要查询或者减少查询数据库，因为 JWT 自包含了用户信息和加密的数据。

基于 session 验证方式的存在的一些弊端：

占用服务器内存资源：由于 session 存储于服务器端，随着越来越多用户的请求登录，服务器端的 session 记录表会越来越大，对服务器内存资源的开销逐渐增大；

扩展性弱：session 机制在负载均衡下，无法很好地进行工作。当服务器资源不足时，无法很好地进行水平扩展；

CORS（跨域资源共享）：当我们需要让数据跨多台移动设备上使用时，跨域资源共享会是一个让人头疼的问题。在使用 Ajax 抓取另一个域的资源时，就会出现禁止请求的情况；

CSRF（跨站请求伪造）：用户在访问银行网站时，他们很容易受到跨站请求伪造的攻击，并且能够被利用其访问其他网站。

JSON Web Token 入门教程
简析 Cookie，Session 和 Token（JWT）

CDN

CDN全称叫做“Content Delivery Network”，中文叫内容分发网络。 CDN系统由分发服务系统，负载均衡系统和运营管理系统组成

  • – 分发服务系统：最基本的工作单元就是Cache设备，cache（边缘cache）负责直接响应最终用户的访问请求，把缓存在本地的内容快速地提供给用 户。同时cache还负责与源站点进行内容同步，把更新的内容以及本地没有的内容从源站点获取并保存在本地。Cache设备的数量、规模、总服务能力是衡 量一个CDN系统服务能力的最基本的指标

  • – 负载均衡系统：主要功能是负责对所有发起服务请求的用户进行访问调度，确定提供给用户的最终实际访问地址。两级调度体系分为全局负载均衡（GSLB）和本 地负载均衡（SLB）。GSLB主要根据用户就近性原则，通过对每个服务节点进行“最优”判断，确定向用户提供服务的cache的物理位置。SLB主要负 责节点内部的设备负载均衡

  • – 运营管理系统：分为运营管理和网络管理子系统，负责处理业务层面的与外界系统交互所必须的收集、整理、交付工作，包含客户管理、产品管理、计费管理、统计分析等功能。

CDN技术详解
CDN是什么CDN的原理和作用什么

vue和react的相同点和区别

image.png vue和react的相同点和区别
前端三大主流框架的区别

什么是防抖和节流？有什么区别？如何实现？

CSS水平居中+垂直居中+水平/垂直居中的方法总结

未知高度和宽度的元素

方案一：使用定位属性

设置父元素为相对定位，给子元素设置绝对定位，left: 50%; top: 50%; transform: translateX(-50%) translateY(-50%);

<style>
    #father {
        width: 500px;
        height: 300px;
        background-color: skyblue;
        position: relative;
}
 
    #son {
        background-color: green;
        position: absolute;
        left: 50%;
        top: 50%;
        transform: translateX(-50%) translateY(-50%);
}
</style>
 
<div id="father">
    <div id="son">我是块级元素</div>
</div>
方案二：使用flex布局实现

设置父元素为flex定位，justify-content: center; align-items: center;

<style>
    #father {
        width: 500px;
        height: 300px;
        background-color: skyblue;
        display: flex;
        justify-content: center;
        align-items: center;
}
 
    #son {
        background-color: green;
}
</style>
 
<div id="father">
    <div id="son">我是块级元素</div>
</div>

D3和Ehart

D3和ECharts在数据可视化领域各有其独特的特点和优势，以下是它们之间的主要区别：

  1. 自由度与定制性：

    • D3：D3是一个被数据驱动的可视化工具库，提供了极高的自由度和定制性。它允许用户将数据绑定到DOM上，并根据所绑定的数据来计算对应DOM的属性值。因此，用户可以使用D3来绘制几乎任何想要的图形，并进行二次开发以定制适合的图表。但是，这种高度的自由度也意味着开发成本可能会稍高。
    • ECharts：ECharts则是一款更为快速配置生成图表的数据可视化库。它提供了大量预设的图表类型，如折线图、柱状图、散点图等，并允许用户通过配置选项来自定义图表的外观和行为。与D3相比，ECharts的定制性相对较低，但更加易于上手和使用。

  2. 交互性：

    • D3：D3的SVG画图支持事件处理器，使得图表具有强大的交互性。用户可以通过D3轻松实现各种复杂的用户交互，如鼠标拖拽、点击、缩放等。
    • ECharts：ECharts也提供了丰富的交互功能，如缩放、拖拽、数据区域选择等。但是，与D3相比，ECharts的交互性可能稍逊一筹。

  3. 性能：

    • D3：由于D3直接操作DOM元素，因此在处理大量数据时可能会面临性能问题。对于频繁的DOM操作，可能会消耗大量性能，导致页面闪烁或卡顿。为了优化性能，可以结合使用Virtual DOM技术或采用D3Canvas来实现。
    • ECharts：ECharts底层依赖矢量图形库ZRender，可以在PC和移动设备上流畅运行，兼容当前绝大部分浏览器。在处理大量数据时，ECharts通常能够保持较好的性能。

  4. 兼容性：

    • D3：D3兼容IE9及以上所有的主流浏览器。
    • ECharts：ECharts兼容到IE6及以上的所有主流浏览器，具有更广泛的浏览器支持。

  5. 文档与示例：

    • D3：D3的英文文档完善，但使用示例只能作为参考。用户需要熟悉SVG、Canvas和D3 API才能有效使用D3。
    • ECharts：ECharts的中文文档完善，使用示例功能完善，更加适合中文用户快速上手。

  6. 使用场景：

    • D3：适用于需要高度定制化和强交互性的数据可视化场景，如复杂的图表绘制、数据可视化工具开发等。
    • ECharts：适用于快速生成常规图表、数据展示和分析等场景，特别是对于大量数据的展示和交互性要求不高的场景。

综上所述，D3和ECharts各有其优势和适用场景。在选择使用哪个库时，需要根据具体需求、项目背景和个人技能来综合考虑。

 hash 与 history 的区别

 hash 原理

hash 是通过监听浏览器 onhashchange 事件变化，查找对应路由应用。通过改变 location.hash 改变页面路由。

history 原理

利用 html5 的history Interface 中新增的 pushState() 和 replaceState() 方法，改变页面路径。

history Interface 是浏览器历史记录栈提供的接口，可通过 back、forward、go 等，可以读取历览器历史记录栈的信息，pushState、repalceState 还可以对浏览器历史记录栈进行修改。

 

hash 与 history 区别对比：

hashhistory
有 # 号没有 # 号
能够兼容到IE8只能兼容到IE10
实际的url之前使用哈希字符，这部分url不会发送到服务器，不需要在服务器层面上进行任何处理没访问一个页面都需要服务器进行路由匹配生成 html 文件再发送响应给浏览器，消耗服务器大量资源
刷新不会存在 404 问题浏览器直接访问嵌套路由时，会报 404 问题。
不需要服务器任何配置需要在服务器配置一个回调路由
avatar
文章
阅读
粉丝