浏览器网络相干：

  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