关于vue.js:前端那些事三网络浏览器

浏览器网络相干：

1. OSI 的七层模型、TCP/IP 四层模型

   1. TCP 的三次握手（为什么要三次握手，一次呢？四次挥手是什么？）
   2. 输出 URL 到页面加载实现须要哪几步？
   3. TCP 和 UDP 的区别
2. 报文
3. HTTP 的特点？（疾速灵便，为什么用 http 不必其余的？）
4. HTTP 有哪些办法？罕用有哪些？
5. get 和 post 的区别是什么？
6. options 的作用？
7. HTTP 状态码？
8. http1 和 http2 的区别？
9. 讲出至多五种解决跨域的方法，jsonp（写一个繁难 jsonp），CORS
10. jsonp 的优缺点？
11. http 和 https 的区别
12. http 缓存都有哪些，强缓存和协商缓存有什么区别
13. localStorage 与 sessionStorage 与 cookie 的区别总结
14. 什么是同源策略，为什么呈现跨域问题？申请形式，域名和端口不同
15. 什么是事件委托，事件捕捉
16. DNS 缓存，原理
17. WebSocket 属于什么（简略利用 API），原理

1. OSI 的七层模型、TCP/IP 四层模型

• TCP 的三次握手（为什么是三次握手，一次呢？四次挥手是什么？）
• 输出 URL 到页面加载实现须要哪几步？
• TCP 和 UDP 的区别

1. OSI 的七层模型：物理层、数据链路层、网络层、传输层、会话层、表示层、应用层。
2. TCP/IP：网络接口层 / 链路层、网络互联层、传输层、应用层。

1.1 TCP 三次握手

https://www.jianshu.com/p/f1b3decb07f8

• 客户端向服务器发送 SYN 包，期待服务器确认；
• 服务器收到 SYN 包，须要确认后向客户端发动一个 SYN 包；
• 客户端收到服务器的 SYN+ACK 包后则向服务器发动确认包，实现三次握手。

为什么不能一次或两次？

因为客户端和服务器都要做好发送数据的筹备后，能力建设通信。避免了服务器端的始终期待而浪费资源。

tcp 是一个全双工的协定，意思是客户端和服务端之间的通信能够同时来回流动，为了保障通信的可靠性以及确定对方能收到本人的申请，tcp 采纳半敞开准则，意思是在收到一个申请后必须发送回复申请，只通信一次或者两次无奈确定对方是否收到申请

1. 1.1 四次挥手其性质为终止协定

• TCP 客户端发送一个 FIN，用来敞开客户到服务器的数据传送。
• 服务器收到这个 FIN，它发回一个 ACK，确认序号为收到的序号加 1。和 SYN 一样，一个 FIN 将占用一个序号。
• 服务器敞开客户端的连贯，发送一个 FIN 给客户端。
• 客户端发回 ACK 报文确认，并将确认序号设置为收到序号加 1。

保证数据接管残缺。

1.2 输出 URL 到页面加载实现须要哪几步？

1. 输出网址 URL
2. 是 url 还是字符串 搜索引擎
3. 缓存机制，判断本地是否有缓存，
4. 没有缓存，DNS 解析（解析失去 IP），https 建设 TLS 连贯
5. 解析的时候，服务器负载平衡
6. TCP 连贯（三次握手）
7. 发送 http 申请（申请办法，get、post）
8. 承受响应，判断状态码抉择解决形式（返回 http 状态码）
9. 判断缓存
10. 解码
11. 渲染
12. 连贯完结（四次挥手）
13. 下载 html dom 树，下载 css OM 树，联合 rander 树

参考：https://zhuanlan.zhihu.com/p/34288735

https://mp.weixin.qq.com/s?__…

1.3 TCP 和 UDP 的区别

• TCP：一对一；面向连贯；面向字节流；传输大量数据；速度慢；（web 开发，http）
• 长处：牢靠，通过 TCP 连贯传输的数据无差错、不失落、不反复，并且可能按序达到。
• UDP：一对多；面向非连贯（发送数据前不须要建设连贯）；面向报文；传输大量数据，速度快；（利用：直播，视频，应用程序）
• 毛病：不保障交付牢靠，丢包。

1. 报文

1. 申请报文（发送申请的报文）：

1. 申请头 Request Headers：

• Accept：申请报文可通过一个“Accept”报文头属性通知服务端 客户端承受什么类型的响应。
• Cookie：客户端的 Cookie 就是通过这个报文头属性传给服务端的哦！
• Referer：示意这个申请是从哪个 URL 过去的
• Cache-Control：对缓存进行管制，如一个申请心愿响应返回的内容在客户端要被缓存一年，或不心愿被缓存就能够通过这个报文头达到目标。

1. 申请行：

• HTTP 办法，get/post 申请
• HTTP 协定

1. 申请体：

2. 响应报文（服务端相应的报文）

状态行，响应首部，内容实体，

1. HTTP 协定的次要特点？（疾速灵便，为什么用 http 不必其余的？）

http 是超文本传输协定，应用层协定的一种，应用层协定：DNS、FTP、SMTP、HTTP、SNMP、Telnet。

特点：简略疾速灵便，属于应用层的面向对象的协定，基于 TCP 的牢靠传输。

http 是不保留状态的协定（无状态协定）

1. HTTP 有哪些办法？罕用有哪些？

2. GET（获取）
3. POST（传输）
4. PUT（更新）
5. DELETE（删除）
6. HEAD（获取报文首部）
7. OPTIONS（询问）
8. CONNECT

9. get 和 post 的区别是什么？

• 数据类型：get 只承受 ASCII 字符，而 post 没有限度，容许二进制。
• 后退 / 后退：get 在浏览器回退 / 刷新时是有害的，而 post 会再次提交申请。
• 申请长度：get 长度取决于浏览器窗口的长度，post 长度不限度
• 缓存：get 能被缓存，post 不能。
• 申请次数：get 申请一次（申请头申请体一起发送），post 申请两次（先发送申请头，等 100 continue，而后再发送申请体，连着发送）。
• 安全性：post 比 get 更平安，因为 GET 参数间接裸露在 URL 上，POST 参数在 HTTP 消 https 息主体中，而且不会被保留在浏览器历史或 web 服务器日志中，。
• 编码格局：post 反对多种编码格局 gbk utf-8
• GET 产生一个 TCP 数据包，浏览器会把 http header 和 data 一并发送
• POST 产生两个 TCP 数据包（除了 FireFox）先发送 header, 浏览器响应 100 continue, 浏览器再发送 data

specification：相干的 RFC，

1. options 的作用？

2. 检测服务器所反对的申请办法
3. CORS 中的预检申请（检测某个接口是否反对跨域）

4. HTTP 状态码，http 响应，信息响应？

• 1 结尾：承受持续解决，（100 continue）
• 2 结尾：示意胜利 (200 胜利并返回 201 已创立 202 接管 203 胜利未受权 204 胜利无内容)
• 3 结尾：重定向（301 永恒重定向，302 长期重定向，304 有缓存不必更新）
• 4 结尾：客户端谬误（400 语法错误，403 禁止被拜访，没有权限，404 资源页面不存在）
• 5 结尾：服务端谬误（500 后端服务器挂了，501 服务器不反对无奈解决，502 网关谬误，后盾建设连贯超时，503 服务器外部谬误，504 后盾未建设连贯超时，505 不反对 http 协定版本）

https://mp.weixin.qq.com/s?__…

1. URI 一个资源文件的不同辨示意办法

• URI：对立资源标识符
• URL：对立资源定位符
• URN：对立资源名称

1. 串行连贯 长久连贯 管道化长久连贯 HTTP2.0 多路复用

• 串行连贯：http1.0 版本，每次发申请都要建设新的 TCP 连贯，每次通信后都要断开 TCP 连贯。
• 长久连贯：http1.1，连段没有提出断开连接，则放弃长久 TCP 连贯。
• 管道化长久连贯: 不必期待响应返回而发送下个申请并按数据返回响应。
• HTTP2.0 多路复用：http2.0
• websocket: HTML5，客户端被动向服务器发申请，建设连贯后。

1. http1 和 http2 的区别？超文本传输协定

影响一个 HTTP 网络申请的因素次要有两个：带宽和提早。

浏览器为每个域名最多同时保护 6 条 TCP 长久连贯。

影响 http1.1 效率的因素是 TCP 启动慢，多条 TCP 竞争带宽，呈现队头阻塞的问题，为了解决这个问题，http2 采纳通过引进二进制分帧层，多路复用，服务器推送，头部压缩。

1）在 HTTP 1.0 中，客户端的每次申请都要求建设一次独自的连贯，在解决完本次申请后，就主动开释连贯。

2）在 HTTP 1.1 中则能够在一次连贯中解决多个申请，并且多个申请能够重叠进行，不须要期待一个申请完结后再发送下一个申请。采纳了 keep-alive。

1. http1 的次要问题：

2. 第一个起因，TCP 的慢启动，因为三次握手。
3. 第二个起因，同时开启了多条 TCP 连贯，那么这些连贯会相互竞争固定的带宽。
4. 第三个起因，HTTP/1.1 队头阻塞的问题，只有一个 TCP 管道。

5. http1.1:

减少了长久连贯；

浏览器每个域名同时保护 6 个 TCP 长久连贯。

毛病：对带宽的利用率不强，(每秒最大发送接管的字节数)

1. http2：

2. 解决方案：要解决一个域名只应用一个 TCP 长连贯和打消队头阻塞问题。
3. 长处：能够设置申请的优先级，反对服务器推送，大幅度的晋升了 web 性能。
4. 问题：队头阻塞无奈解决，丢包率减少（）

5. 区别：http2 采纳通过引入二进制分帧层，

• 多路复用机制（MultiPlexing）：在 TLS 层，减少一个二进制分帧层，

TLS 协定是会话层的平安传输协定，

即连贯共享，即每一个 request 都是是用作连贯共享机制的。一个 request 对应一个 id，这样一个连贯上能够有多个 request，每个连贯的 request 能够随机的混淆在一起，接管方能够依据 request 的 id 将 request 再归属到各自不同的服务端申请外面。

• 新的二进制格局（Binary Format），将申请分帧传输，能够进行二进制分帧层，HTTP1.x 的解析是基于文本。基于文本协定的格局解析存在人造缺点，文本的表现形式有多样性，要做到健壮性思考的场景必然很多，二进制则不同，只认 0 和 1 的组合。基于这种思考 HTTP2.0 的协定解析决定采纳二进制格局，实现不便且强壮。

二进制分帧层：分段带 ID 传输。

• 头部压缩，对申请头和响应头进行压缩，减小体积。
• 服务器推送（server push），同 SPDY 一样，HTTP2.0 也具备 server push 性能。
• 设置申请的优先级：

1. HTTP2 的长久连贯和管线化：

2. http3：

HTTP3：基于 UDP 协定推出一个 QUIC 协定，

在 UDP 根底上新增多路复用，0-RTT，应用 TLS1.3 加密，流量管制，有序交付，重传等。

• 防止包阻塞：
• 疾速重启会话：

1. 什么是浏览器同源策略？为什么会呈现跨域问题？（申请形式，域名和端口不同）

• 一种安全策略，爱护本地数据，为了避免 XSS、CSFR 等攻打。
• 同源的定义：协定（申请形式）、域名、端口雷同。因为存在浏览器同源策略，所以才会有跨域问题。
• 同源策略分为两种：

DOM 同源策略：禁止对不同源页面 DOM 进行操作。这里次要场景是 iframe 跨域的状况，不同域名的 iframe 是限度相互拜访的。

XMLHttpRequest 同源策略：禁止应用 XHR 对象向不同源的服务器地址发动 HTTP 申请。

浏览器同源策略：https://www.cnblogs.com/laixiangran/p/9064769.html

理解预检申请嘛？

• 跨域是指一个域下的文档或脚本试图去申请另一个域下的资源
• 避免 XSS、CSFR 等攻打, 协定 + 域名 + 端口不同
• jsonp; 跨域资源共享（CORS）(Access control); 服务器正向代理等

预检申请: 需预检的申请要求必须首先应用 OPTIONS 办法发动一个预检申请到服务器，以获知服务器是否容许该理论申请。” 预检申请“的应用，能够防止跨域申请对服务器的用户数据产生未预期的影响

1. 代理服务器

代理服务器：客户端和服务端之间的中间商，能够作为缓存服务器。

• 正向代理：
• 反向代理：
• 反向代理解决跨域问题：两个服务器之间通信。

本地服务器在浏览器向本地服务发动申请》本地代理转发》指标服务器》响应数据后通过代理伪装成本地服务器申请的返回值》浏览器接管到指标服务器的数据

• vue 的 proxyTable 的作用，解决跨域问题。怎么实现。

与服务器联调的时候 vue.config.js，proxy 设置申请反向代理

缓存服务器：频繁拜访网络内容。进步访问速度。浏览器和原服务器之间的两头服务器。

1. 解决跨域的方法，罕用：

2. jsonp 跨域：

jsonp 跨域通过 script 的 src 获取 callback 申请资源进行文件的传输，而后返回一个函数调用；

1. 长处：兼容性好（兼容 IE）
2. 毛病：只反对 get 一种申请，不是官网 API，容易受到 xss 攻打。
3. 原理：script 的 src 属性默认反对跨域

4. 跨域资源共享（CORS）：批改响应头

• 跨域资源共享（CORS）容许浏览器跨源服务器，须要浏览器和服务器同时反对，须要在服务器上配置 Access-Control-Allow-Origon。

* 不能带 cookie

• 简略申请：申请形式：get、post、head
• 非简略申请：先发一次预检申请（options）：put、delete

options 是预检申请，在真正的申请发送进来之前，浏览器会先发送一个 options 申请向服务询问此接口是否容许我拜访

浏览器在以后实在申请是非简略申请且跨域的状况下会发动 options 预检申请

与 JSONP 相比：

• JSONP 只反对 get 申请，cors 反对所有申请（get、post）；
• JSONP 支持性好，兼容老版本浏览器。

参考：http://www.ruanyifeng.com/blog/2016/04/cors.html

1. hash：window.location

hash：location.hash + iframe；

1. postMessage：

postMessage() 办法容许来自不同源的脚本采纳异步形式进行无限的通信，能够实现跨文本档、多窗口、跨域消息传递。

Awindow.postMessage(data,origin)

A 窗口向 B 窗口发送申请：Awindow.postMessage(‘data’,’http://B.com’)

1. WebSocket 协定跨域：

WebSocket 协定跨域：HTML5 一种新的长久化协定，用于 H5 聊天，即时线上跨域。

实时聊天，基于 TCP 协定，短轮询，节约带宽，

长轮询，

http 单向数据流，websocket 链接客户端和服务器，在 ws 里

scoket.io

WebSocket 心跳检测

不罕用：

1. nginx 反向代理接口跨域：

同源策略是浏览器的安全策略，不是 HTTP 协定的一部分。服务器端调用 HTTP 接口只是应用 HTTP 协定，不会执行 JS 脚本，不须要同源策略，也就不存在逾越问题

1. document.domain + iframe 跨域：

两个页面都通过 js 强制设置 document.domain 为根底主域，就实现了同域. 然而仅限主域雷同，子域不同的跨域利用场景

1. http 和 https 的区别

http：因为 http 是无状态，明文传输的，容易造成中间人攻打，所以在 http 协定中退出平安层，退出 SSL/TLS 平安层，减少加密 / 解密的形式，相比 http 协定更平安。

SSL/TLS 平安层：对发动 HTTP 申请的数据进行加密操作和对接管到 HTTP 的内容进行解密操作。

TLS/SSL 的性能实现次要依赖于三类根本算法：散列函数、对称加密和非对称加密散列函数，散列算法，MD5

RSA 算法

https：平安，申请工夫长，加载慢，花钱，证书

https 安全性:

1. 对称加密：加密和解密应用的密钥是雷同的

• 传输方式：

浏览器：发送加密套件列表和一个随机数 client-random，

服务器：从加密套件列表中选取一个加密套件，还会生成一个随机数 service-random，并将 service-random 和加密套件列表返回给浏览器。最初浏览器和服务器别离返回确认音讯。

• 毛病：容易被破解

1. 非对称加密：A、B 两把密钥，公钥，私钥

毛病：效率低，影响速度，无奈保障服务器到浏览器的平安

1. 对称加密 + 非对称加密：用非对称加密的形式 传输 对称加密里的密钥，

非对称加密应用时，生成 pre-master（两个随机数计算）。

长处：速度快 + 平安。

1. 增加数字证书（生产）：向 CA 证书机构申请数字证书，蕴含数字签名，非对称加密的公钥和个人信息。

证书的作用：一个是通过数字证书向浏览器证实服务器的身份，另一个是数字证书外面蕴含了服务器公钥。

证书也有公钥和私钥。证书加密一次，

CA 证书用公钥，hash 值，。

加密套件列表：客户端反对的加密和非对称加密的形式

1. 浏览器如何验证数字证书

• 有了 CA 签名过的数字证书，当浏览器向服务器发出请求时，服务器会返回数字证书给浏览器。浏览器接管到数字证书之后，会对数字证书进行验证。
• 首先浏览器读取证书中相干的明文信息，采纳 CA 签名时雷同的 Hash 函数来计算并失去信息摘要 A；而后再利用对应 CA 的公钥解密签名数据，失去信息摘要 B；比照信息摘要 A 和信息摘要 B，如果统一，则能够确认证书是非法的，
• 即证实了这个服务器是极客工夫的；同时浏览器还会验证证书相干的域名信息、无效工夫等信息。

1. 区别：

• HTTP 的 URL 以 http:// 结尾，而 HTTPS 的 URL 以 https:// 结尾
• HTTP 是不平安的，而 HTTPS 是平安的
• HTTP 规范端口是 80，而 HTTPS 的规范端口是 443
• 在 OSI 网络模型中，HTTP 工作于应用层，而 HTTPS 的平安传输机制工作在传输层
• HTTP 无奈加密，而 HTTPS 对传输的数据进行加密
• HTTP 无需证书，而 HTTPS 须要 CA 机构 wosign 的颁发的 SSL 证书

1. https 是如何加密的？

2. 密钥传输的过程，服务器做了什么事？浏览器做了什么事？密钥怎么传的？对称加密要怎么传？数字证书怎么校验？

3. 常见加密算法有哪些？

4. 浏览器缓存，强缓存和协商缓存有什么区别

https://mp.weixin.qq.com/s/Wvc0lkLpgyEW_u7bbMdvpQ

1. 缓存地位：

   1. service worker：浏览器背地的独立线程，个别缓存
   2. memory chache：内存中的缓存，计算机内存
   3. Disk Cache：硬盘中的内存，速度慢
   4. Push Cache：推送缓存，http2，只在 session 中存在
2. 缓存过程：

1. 缓存机制：
2. 缓存机制分为：强缓存和协商缓存
3. 区别：是否发送申请，强缓存不发送申请，协商缓存至多发送一次申请。

• 优先级：Cache-Control > expires > Etag > Last-Modified

• 强缓存（本地缓存）：不必跟服务器进行通信

  • 缓存字段：Expires 和 Cache-Control
  • Expires：相对工夫，资源生效的工夫，
  • Cache-Control：绝对工夫，资源缓存的最大无效工夫
  • Cache-Control 的 max-age 优先级高于 Expires

• 协商缓存：由服务器来决定是否应用缓存，至多和服务器有一次通信

  • 缓存字段：Last-Modified 和 ETag 发送到服务器，确认资源是否更新。
  • Last-Modified 示意本地文件最初批改日期
  • ETag 是个标识，修没批改
  • 判断是否过期，先走 etags（http1 生成的），再走 Last-Modified。ETag 优先级比 Last-Modified 高。

页面怎么进行强缓存和协商缓存？

如果缓存过期了，咱们就能够应用协商缓存来解决问题。协商缓存须要申请，如果缓存无效会返回 304。

协商缓存须要客户端和服务端独特实现，和强缓存一样，也有两种实现形式。

Last-Modified 和 If-Modified-Since

If-Modified-Since 会将 Last-Modified 的值发送给服务器，询问服务器在该日期后资源是否有更新，有更新的话就会将新的资源发送回来。

参考：https://zhuanlan.zhihu.com/p/64635421

如果浏览器命中强缓存，则不须要给服务器发申请；而协商缓存最终由服务器来决定是否应用缓存，即客户端与服务器之间存在一次通信。

在 chrome 中强缓存（尽管没有收回实在的 http 申请）的申请状态码返回是 200 (from cache)；而协商缓存如果命中走缓存的话，申请的状态码是 304 (not modified)。不同浏览器的策略不同，在 Fire Fox 中，from cache 状态码是 304.

浏览器会获取该缓存资源的 header 中的信息，依据 response header 中的 expires 和 cache-control 来判断是否命中强缓存，如果命中则间接从缓存中获取资源。

如果没有命中强缓存，浏览器就会发送申请到服务器，这次申请会带上 IF-Modified-Since 或者 IF-None-Match, 它们的值别离是第一次申请返回 Last-Modified 或者 Etag，由服务器来比照这一对字段来判断是否命中。IF-None-Match 是 false 时，则服务器返回 304 状态码，

IF-None-Match 是 true 时，走 200

并且不会返回资源内容，浏览器会间接从缓存获取；否则服务器最终会返回资源的理论内容，并更新 header 中的相干缓存字段。

1. keep-alive：HTTP 长连贯

• 是客户端和服务端的一个约定，如果开启 keep-alive，则服务端在返回 response 后不敞开 TCP 连贯；同样的，在接管完响应报文后，客户端也不敞开连贯，发送下一个 HTTP 申请时会重用该连贯。
• http1.0 默认敞开的，须要在 http 头退出 ”Connection: Keep-Alive”，能力启用 Keep-Alive
• http1.0 默认开启 keep-alive。
• 浏览器默认开启 keep-alive，

1. http 缓存都有哪些，

https://juejin.im/post/68449036824551096[](https://juejin.im/post/684490…

#heading-38

1. http 缓存、websql、indexDB、cookie、localstorage、sessionstorage、application cache、cacheStorage、flash 缓存

2. localStorage 与 sessionStorage 与 cookie 补充：

https://mp.weixin.qq.com/s?__…

https://zhuanlan.zhihu.com/p/159268611

cookie

localStorage

sessionStorage

存储大小

个别不超过 4K

个别为 5M

个别为 5M

数据有效期

可设置生效工夫，默认敞开浏览器生效

永恒无效，除了手动革除

敞开页面失效

作用域

所有同源窗口共享

所有同源窗口共享

只在同浏览器共享

易用性

须要本人封装，原生的 cookie 接口不敌对

原生接口能够承受，能够封装来对 Object 和 Array 有更好的反对

与服务端通信

每次会随 http 协定头带过来，cookie 保留太多数据会带来性能问题

在申请时应用数据，不参加服务器通信

贮存类型 string

（补充：cookie 通过 http 协定头带过来的）

indexDB 存储大小无下限 贮存类型键值对，不能跨域 时效性

1. CSRF 攻打 跨站申请伪造

https://mp.weixin.qq.com/s?__…

跨站伪造申请

• 概念：攻击者盗用你的身份，以你的名义发送歹意申请，比方：通过生疏连贯，诱导用户点击。

• CSRF 如何产生的？

  • 用户信息存在 cookie 中，黑客通过贮存 token
• 如何避免 CSRF 攻打？

1. 在服务端做解决，尽量应用 post 申请，退出验证码，验证 Referer
2. 应用 Cookie 的 SameSite 属性：strict、lax（绝对宽松）、none
3. 验证起源地址：origin(不蕴含门路信息) 和 refer
4. 退出 CSRF token：
5. 判断申请的起源：检测 Referer(并不平安，Referer 能够被更改)

• CSRF 主动进攻策略：同源检测（Origin 和 Referer 验证）。
• CSRF 主动防御措施：Token 验证 或者 双重 Cookie 验证 以及配合 Samesite Cookie。
• 保障页面的幂等性，后端接口不要在 GET 页面中做用户操作。

判断 origin，没有再判断验证 refer 字段，申请。

Origin Header

Referer Header

然而 Origin 在以下两种状况下并不存在：

IE11 同源策略：302 重定向：

1. XSS 攻打 跨站脚本攻打

XSS(Cross-Site Scripting，跨站脚本攻打) 是一种代码注入攻打。攻击者在指标网站上注入恶意代码，当被攻击者登陆网站时就会执行这些恶意代码，这些脚本能够读取 cookie，session tokens，或者其它敏感的网站信息，对用户进行钓鱼欺诈，甚至发动蠕虫攻打等。

XSS 的实质是：恶意代码未经过滤，与网站失常的代码混在一起；浏览器无奈分辨哪些脚本是可信的，导致歹意脚本被执行。因为间接在用户的终端执行，恶意代码可能间接获取用户的信息，利用这些信息假冒用户向网站发动攻击者定义的申请。

类型：

• 反射型 XSS：通过 URL 传递参数，当用户点击一个歹意链接，或者提交一个表单，或者进入一个歹意网站时，注入脚本进入被攻击者的网站。Web 服务器将注入脚本，比方一个错误信息，搜寻后果等，未进行过滤间接返回到用户的浏览器上。
• 如何进攻：本义对 url 的查问参数进行本义后再输入到页面。
• DOM 型 XSS：html，前端代码不标准。
• 如何进攻：本义图片链接。
• 存储型 XSS：数据库，将恶意代码提交到指标网站的数据库中。
• 如何进攻：服务器接管到数据，在存储到数据库之前，进行本义 / 过滤、
• SQL 注入：

如何让预防 xss 攻打？

1. 服务端过滤做验证，在服务端应用 HTTP 的 Content-Security-Policy 头部来指定策略，或者在前端设置 meta 标签；
2. 服务端设置 CSP：开启白名单
3. 后端设置 HttpOnly：HttpOnly 解决的是 XSS 后的 Cookie 劫持攻打，只能升高受损范畴
4. 对输出的内容和长度做限度：只能减少 XSS 攻打的难度。

jsonp 过滤同域的代码有破绽

1. 点击劫持

点击劫持：攻击者将须要攻打的网站通过 iframe 嵌入本人的网页中，诱导用户点击，暗藏了一个通明的 iframe，用外层假页面诱导用户点击。

进攻方法：

1. deny
2. frame busting
3. 应用 X -Frame-Options 协定头：微软提供，用来进攻利用 iframe 嵌套的点击劫持攻打
4. same origin：同源下的 iframe
5. allow-from-origin：

6. 中间人攻打

https 对称加密，非对称加密，混合加密，证书最为无效避免中间人攻打。

https://blog.csdn.net/oZhuZhiYuan/article/details/106650944

1. cookie session token，为什么能通过 cookie 攻打，不能通过 token 攻打

https://mp.weixin.qq.com/s/diaE6WkB_UJxjuhLS9E20Q

• cookie 存在浏览器 session 存在服务器 token 明文传输，没有固定寄存的中央
• cookie 不是很平安，session 更平安。cookie 容易被攻打。
• 设置 cookie 工夫过期，应用 session-destory 销毁对话。
• 发送申请时会带 cookie，不会主动带 token
• token 存储在 cookie 中，token 能够进攻 csrf 攻打
• xss 攻打

• token 如何进行加密？

1. 垃圾回收

V8 实现了精确式 GC，GC 算法采纳了分代式垃圾回收机制。因而，V8 将内存（堆）分为新生代和老生代两局部。

1. 新生代：

   1. 存活工夫短，应用 Scavenge GC 算法
   2. 内存空间：from 空间和 to 空间。
   3. 三次折叠持续应用的放在老生代里
   4. 清理的过程：对象区域和闲暇区域进行翻转。
   5. 新申明放在对象区，应用频率比拟低的放在闲暇区

2. 老生代：

   1. 存活工夫长且数量多，应用：标记革除算法和标记压缩算法。
   2. to 空间（占比大小超过 25%），标记整顿算法。
   3. 对象树形构造，依据援用指向 被调用的对象 没有被标记的会被革除。
   4. 空间不间断的会整合。

3. 怎么解决全进展？

   1. 垃圾清理走的主线程，清理垃圾会造成卡顿，为了避免卡顿，会将垃圾分为很多份清理。逐步插在主线程内。

为了升高老生代的垃圾回收而造成的卡顿，V8 将标记过程分为一个个的子标记过程，同时

让垃圾回收标记和 JavaScript 应用逻辑交替进行，直到标记阶段实现，咱们把这个算法称

为增量标记（Incremental Marking）算法。

1. 跨标签页通信

1. 内存透露

1. 全局变量引起

2. 闭包

3.dom 清空，事件没有革除

4. 子元素存在援用

子元素还存在援用时，先把子元素开释再开释父元素，否则父元素无奈开释。

被忘记的计时器

如何防止内存透露

1.ESLint 检测代码查看非冀望的全局变量。

2. 应用闭包的时候，得晓得闭包了什么对象，还有援用闭包的对象何时革除闭包。最好能够防止写出简单的闭包，因为简单的闭包引起的内存透露，如果没有打印内存快照的话，是很难看进去的。

3. 绑定事件的时候，肯定得在失当的时候革除事件。在编写一个类的时候，举荐应用 init 函数对类的事件监听进行绑定和资源申请，而后 destroy 函数对事件和占用资源进行开释。

全局变量 没有被申明

无奈被回收 属于内存透露

没有开释的内存

1. 事件冒泡、事件捕捉、事件委托：https://www.jianshu.com/p/9c279d7330c6