浏览器原理

发表于 2022-12-09 更新于 2023-03-13 分类于前端 Waline：本文字数： 22k 阅读时长 ≈ 20 分钟

浏览器安全

XSS攻击

XSS攻击指的是跨站脚本攻击(Cross-Site Scripting)，是一种代码注入攻击。攻击者通过在网站注入恶意脚本，使之在用户的浏览器上运行，从而盗取用户的信息如 cookie 等。

XSS 的本质是因为网站没有对恶意代码进行过滤，与正常的代码混合在一起了，浏览器没有办法分辨哪些脚本是可信的，从而导致了恶意代码的执行。

攻击者可以通过XSS攻击进行以下操作：

获取页面的数据，如DOM、cookie、localStorage；
DOS攻击，发送合理请求，占用服务器资源，从而使用户无法访问服务器；
破坏页面结构；
流量劫持（将链接指向某网站）

攻击类型

XSS 可以分为存储型、反射型和 DOM 型：

存储型指的是恶意脚本会存储在目标服务器上，当浏览器请求数据时，脚本从服务器传回并执行。
反射型指的是攻击者诱导用户访问一个带有恶意代码的 URL 后，服务器端接收数据后处理，然后把带有恶意代码的数据发送到浏览器端，浏览器端解析这段带有 XSS 代码的数据后当做脚本执行，最终完成 XSS 攻击。
DOM 型指的通过修改页面的 DOM 节点形成的 XSS。

反射型 XSS 跟存储型 XSS 的区别是：存储型 XSS 的恶意代码存在数据库⾥，反射型 XSS 的恶意代码存在 URL ⾥。

反射型 XSS 漏洞常⻅于通过 URL 传递参数的功能，如⽹站搜索、跳转等。由于需要⽤户主动打开恶意的 URL 才能⽣效，攻击者往往会结合多种⼿段诱导⽤户点击。

DOM 型 XSS 跟前两种 XSS 的区别：DOM 型 XSS 攻击中，取出和执⾏恶意代码由浏览器端完成，属于前端JavaScript ⾃身的安全漏洞，⽽其他两种 XSS 都属于服务端的安全漏洞。

如何抵御XSS

抵御XSS攻击的一般方法是对用户输入的数据进行转义或者过滤，防止恶意的脚本代码被执行
使用 CSP ，CSP 的本质是建立一个白名单，告诉浏览器哪些外部资源可以加载和执行，从而防止恶意代码的注入攻击。

CSP 指的是内容安全策略，它的本质是建立一个白名单，告诉浏览器哪些外部资源可以加载和执行。我们只需要配置规则，如何拦截由浏览器自己来实现。

通常有两种方式来开启 CSP，一种是设置 HTTP 首部中的 Content-Security-Policy，一种是设置 meta 标签的方式

对一些敏感信息进行保护，比如 cookie 使用 http-only，使得脚本无法获取。也可以使用验证码，避免脚本伪装成用户执行一些操作。

CSRF攻击

CSRF 攻击指的是跨站请求伪造攻击。

CSRF攻击的过程是，用户在浏览器上登录了网站A，并且网站A返回了Cookie信息给浏览器，用户没有退出网站A；然后用户在同一浏览器上访问了网站B，网站B上有一些隐藏的链接或者表单，指向网站A的一些敏感操作；当用户点击这些链接或者表单时，浏览器会自动带上网站A的Cookie信息，发送请求到网站A，网站A认为这是用户的合法请求，从而执行了攻击者想要的操作

CSRF 攻击的本质是利用 cookie 会在同源请求中携带发送给服务器的特点，以此来实现用户的冒充。

如何抵御CSRF

使用验证码。验证码是一种让用户进行二次身份验证的方式，可以阻止攻击者伪造用户的请求。但是验证码会影响用户的体验，不适合频繁使用。
使用Token。Token是一种服务器生成的随机字符串，可以放在表单的隐藏字段或者URL的参数中，每次用户发送请求时，都要带上Token。服务器会验证Token的有效性，如果Token不匹配或者过期，就拒绝请求。Token可以有效防止CSRF攻击，但是需要服务器保存和管理Token。
使用Referer。Referer是HTTP请求头中的一个字段，表示请求的来源网站。服务器可以检查Referer是否来自合法的网站，如果不是，就拒绝请求。Referer可以简单地防止CSRF攻击，但是也有一些缺点，比如Referer可能被篡改或者禁用。
使用SameSite。SameSite是Cookie的一个属性，表示Cookie是否可以跨站发送1。如果设置为Strict或者Lax，就可以阻止Cookie在跨站请求中被发送，从而防止CSRF攻击。SameSite是一种比较新的防御方式，但是也有一些兼容性和局限性的问题。

有哪些可能引起前端安全

跨站脚本 (Cross-Site Scripting, XSS): ⼀种代码注⼊⽅式, 为了与 CSS 区分所以被称作 XSS。早期常⻅于⽹络论坛, 起因是⽹站没有对⽤户的输⼊进⾏严格的限制, 使得攻击者可以将脚本上传到帖⼦让其他⼈浏览到有恶意脚本的⻚⾯, 其注⼊⽅式很简单包括但不限于 JavaScript / CSS / Flash 等；
iframe的滥⽤: iframe中的内容是由第三⽅来提供的，默认情况下他们不受控制，他们可以在iframe中运⾏JavaScirpt脚本、Flash插件、弹出对话框等等，这可能会破坏前端⽤户体验；
跨站点请求伪造（Cross-Site Request Forgeries，CSRF）: 指攻击者通过设置好的陷阱，强制对已完成认证的⽤户进⾏⾮预期的个⼈信息或设定信息等某些状态更新，属于被动攻击
恶意第三⽅库: ⽆论是后端服务器应⽤还是前端应⽤开发，绝⼤多数时候都是在借助开发框架和各种类库进⾏快速开发，⼀旦第三⽅库被植⼊恶意代码很容易引起安全问题。

网络劫持有哪几种，如何防范？

⽹络劫持分为两种:

（1）DNS劫持: (输⼊京东被强制跳转到淘宝这就属于dns劫持)

DNS强制解析: 通过修改运营商的本地DNS记录，来引导⽤户流量到缓存服务器
302跳转的⽅式: 通过监控⽹络出⼝的流量，分析判断哪些内容是可以进⾏劫持处理的,再对劫持的内存发起302跳转的回复，引导⽤户获取内容

（2）HTTP劫持: (访问⾕歌但是⼀直有贪玩蓝⽉的⼴告),由于http明⽂传输,运营商会修改你的http响应内容(即加⼴告)

DNS劫持由于涉嫌违法，已经被监管起来，现在很少会有DNS劫持，⽽http劫持依然⾮常盛⾏，最有效的办法就是全站HTTPS，将HTTP加密，这使得运营商⽆法获取明⽂，就⽆法劫持你的响应内容。

进程与线程

进程是资源分配的最小单位，线程是CPU调度的最小单位。

进程放在应用上来说就代表了一个程序；线程是进程中的更小单位，描述了执行一段指令所需的时间。

进程和线程之间的关系：

进程中的任意一线程执行出错，都会导致整个进程的崩溃
线程之间共享进程中的数据
当进程关闭，操作系统会回收进程所占用的内存
进程之间的内容相互隔离

浏览器的进程

浏览器进程：主要负责界面显示、用户交互、子进程管理，同时提供存储等功能
渲染进程：核心任务是将 HTML、CSS 和 JavaScript 转换为用户可以与之交互的网页，排版引擎 Blink 和 JavaScript 引擎 V8 都是运行在该进程中，默认情况下，Chrome 会为每个 Tab 标签创建一个渲染进程。出于安全考虑，渲染进程都是运行在沙箱模式下。
GPU 进程：其实， GPU 的使用初衷是为了实现 3D CSS 的效果，只是随后网页、Chrome 的 UI 界面都选择采用 GPU 来绘制，这使得 GPU 成为浏览器普遍的需求。最后，Chrome 在其多进程架构上也引入了 GPU 进程。
网络进程：主要负责页面的网络资源加载，之前是作为一个模块运行在浏览器进程里面的，直至最近才独立出来，成为一个单独的进程。
插件进程：主要是负责插件的运行，因插件易崩溃，所以需要通过插件进程来隔离，以保证插件进程崩溃不会对浏览器和页面造成影响。

打开一个网页，最少需要四个进程：1 个网络进程、1 个浏览器进程、1 个 GPU 进程以及 1 个渲染进程。如果打开的页面有运行插件的话，还需要再加上 1 个插件进程。

虽然多进程模型提升了浏览器的稳定性、流畅性和安全性，但同样不可避免地带来了一些问题：

更高的资源占用：因为每个进程都会包含公共基础结构的副本（如 JavaScript 运行环境），这就意味着浏览器会消耗更多的内存资源。
更复杂的体系架构：浏览器各模块之间耦合性高、扩展性差等问题，会导致现在的架构已经很难适应新的需求了。

渲染进程的线程有哪些

GUI渲染线程，渲染浏览器页面
JS引擎线程，负责处理Javascript脚本程序，一个Tab页中无论什么时候都只有一个JS引擎线程在运行JS程序；
时间触发线程，用来控制事件循环；
定时器触发进程即setInterval与setTimeout所在线程；
异步http请求线程，XMLHttpRequest连接后通过浏览器新开一个线程请求；

检测到状态变更时，如果设置有回调函数，异步线程就产生状态变更事件，将回调函数放入事件队列中，等待JS引擎空闲后执行；

GUI渲染线程和JS引擎线程是互斥的，当JS引擎执行时GUI线程会被挂起，GUI更新会被保存在一个队列中等到JS引擎空闲时立即被执行

进程之间的通信方式

管道通信

管道就是操作系统在内核中开辟的一段缓冲区，进程1可以将需要交互的数据拷贝到这段缓冲区，进程2就可以读取了。

僵尸进程和孤儿进程是什么？

孤儿进程：父进程退出了，而它的一个或多个进程还在运行，那这些子进程都会成为孤儿进程。孤儿进程将被init进程(进程号为1)所收养，并由init进程对它们完成状态收集工作。
僵尸进程：子进程比父进程先结束，而父进程又没有释放子进程占用的资源，那么子进程的进程描述符仍然保存在系统中，这种进程称之为僵死进程。

死锁？如何解决死锁？

所谓死锁，是指多个进程在运行过程中因争夺资源而造成的一种僵局，当进程处于这种僵持状态时，若无外力作用，它们都将无法再向前推进。

系统中的资源可以分为两类：

可剥夺资源，是指某进程在获得这类资源后，该资源可以再被其他进程或系统剥夺，CPU和主存均属于可剥夺性资源；
不可剥夺资源，当系统把这类资源分配给某进程后，再不能强行收回，只能在进程用完后自行释放，如磁带机、打印机等。

浏览器缓存

对浏览器缓存机制的理解

浏览器第一次加载资源，服务器返回200. 浏览器从服务器下载资源文件，并缓存资源文件与 response header，以供下次加载时对比使用；
下一次加载资源时，由于强制缓存优先级较高，先比较当前时间与上一次返回 200 时的时间差，如果没有超过 cache-control 设置的 max-age，则没有过期，并命中强缓存，直接从本地读取资源；
如果资源已过期，则表明强制缓存没有被命中，则开始协商缓存，向服务器发送带有 If-None-Match 和 If-Modified-Since 的请求；
服务器收到请求后，优先根据Etag值判断被请求文件有无做修改，Etag 值一致则没有修改，命中协商缓存，返回 304；如果不一致则有改动，直接返回新的资源文件带上新的 Etag 值并返回 200；
如果服务器收到的请求没有 Etag 值，则将 If-Modified-Since 和被请求文件的最后修改时间做比对，一致则命中协商缓存，返回 304；不一致则返回新的 last-modified 和文件并返回 200；

很多网站的资源后面都加了版本号，这样做的目的是：每次升级了 JS 或 CSS 文件后，为了防止浏览器进行缓存，强制改变版本号，客户端浏览器就会重新下载新的 JS 或 CSS 文件，以保证用户能够及时获得网站的最新更新。

浏览器资源缓存位置

Server Worker

Service Worker 运行在 JavaScript 主线程之外，虽然由于脱离了浏览器窗体无法直接访问 DOM，但是它可以完成离线缓存、消息推送、网络代理等功能。它可以让我们自由控制缓存哪些文件、如何匹配缓存、如何读取缓存，并且缓存是持续性的。当 Service Worker 没有命中缓存的时候，需要去调用 fetch 函数获取数据。也就是说，如果没有在 Service Worker 命中缓存，会根据缓存查找优先级去查找数据。但是不管是从 Memory Cache 中还是从网络请求中获取的数据，浏览器都会显示是从 Service Worker 中获取的内容。

Memory Cache

Memory Cache 就是内存缓存，它的效率最快，但是内存缓存虽然读取高效，可是缓存持续性很短，会随着进程的释放而释放。一旦我们关闭 Tab 页面，内存中的缓存也就被释放了。

内存缓存中有一块重要的缓存资源是preloader相关指令下载的资源，preloader的相关指令已经是页面优化的常见手段之一，它可以一边解析js/css文件，一边网络请求下一个资源。

Disk Cache

Disk Cache 也就是存储在硬盘中的缓存，读取速度慢点，但是什么都能存储到磁盘中，比之 Memory Cache 胜在容量和存储时效性上。在所有浏览器缓存中，Disk Cache 覆盖面基本是最大的。它会根据 HTTP Header 中的字段判断哪些资源需要缓存，哪些资源可以不请求直接使用，哪些资源已经过期需要重新请求。并且即使在跨站点的情况下，相同地址的资源一旦被硬盘缓存下来，就不会再次去请求数据。

绝大部分的缓存都来自 Disk Cache

访问缓存优先级

先在内存中查找,如果有,直接加载。
如果内存中不存在,则在硬盘中查找,如果有直接加载。
如果硬盘中也没有,那么就进行网络请求。
请求获取的资源缓存到硬盘和内存。

协商缓存和强缓存的区别

强缓存

强缓存，如果缓存资源有效，直接使用缓存资源，不必向服务器发起请求。

通过http头信息中expires和cache-control属性

服务器通过在响应头中添加 Expires 属性，来指定资源的过期时间。在过期时间以内，该资源可以被缓存使用，不必再向服务器发送请求。这个时间是一个绝对时间，它是服务器的时间，因此可能存在这样的问题，就是客户端的时间和服务器端的时间不一致，或者用户可以对客户端时间进行修改的情况，这样就可能会影响缓存命中的结果。

Expires 是 http1.0 中的方式，因为它的一些缺点，在 HTTP 1.1 中提出了一个新的头部属性就是 Cache-Control 属性，它提供了对资源的缓存的更精确的控制。

Cache-Control可设置的字段：

public：设置了该字段值的资源表示可以被任何对象（包括：发送请求的客户端、代理服务器等等）缓存。这个字段值不常用，
private：设置了该字段值的资源只能被用户浏览器缓存，不允许任何代理服务器缓存。在实际开发当中，对于一些含有用户信息的HTML，通常都要设置这个字段值，避免代理服务器(CDN)缓存；
no-cache：设置了该字段需要先和服务端确认返回的资源是否发生了变化，如果资源未发生变化，则直接使用缓存好的资源；
no-store：设置了该字段表示禁止任何缓存，每次都会向服务端发起新的请求，拉取最新的资源；
max-age=：设置缓存的最大有效期，单位为秒；
s-maxage=：优先级高于max-age=，仅适用于共享缓存(CDN)，优先级高于max-age或者Expires头；
max-stale[=]：设置了该字段表明客户端愿意接收已经过期的资源，但是不能超过给定的时间限制。

一般来说只需要设置其中一种方式就可以实现强缓存策略，当两种方式一起使用时，Cache-Control 的优先级要高于 Expires。

no-cache和no-store很容易混淆：

no-cache 是指先要和服务器确认是否有资源更新，在进行判断。也就是说没有强缓存，但是会有协商缓存；
no-store 是指不使用任何缓存，每次请求都直接从服务器获取资源。

协商缓存

如果没有命中强制缓存，如果设置了协商缓存，这个时候协商缓存就会发挥作用了。

命中协商缓存的条件有两个：

max-age=xxx 过期了
值为no-store

使用协商缓存策略时，会先向服务器发送一个请求，如果资源没有发生修改，则返回一个 304 状态，让浏览器使用本地的缓存副本。如果资源发生了修改，则返回修改后的资源。

协商缓存也可以通过两种方式来设置，分别是 http 头信息中的 Etag 和 Last-Modified 属性。

（1）服务器通过在响应头中添加 Last-Modified 属性来指出资源最后一次修改的时间，当浏览器下一次发起请求时，会在请求头中添加一个 If-Modified-Since 的属性，属性值为上一次资源返回时的 Last-Modified 的值。当请求发送到服务器后服务器会通过这个属性来和资源的最后一次的修改时间来进行比较，以此来判断资源是否做了修改。如果资源没有修改，那么返回 304 状态，让客户端使用本地的缓存。如果资源已经被修改了，则返回修改后的资源。使用这种方法有一个缺点，就是 Last-Modified 标注的最后修改时间只能精确到秒级，如果某些文件在1秒钟以内，被修改多次的话，那么文件已将改变了但是 Last-Modified 却没有改变，这样会造成缓存命中的不准确。

（2）因为 Last-Modified 的这种可能发生的不准确性，http 中提供了另外一种方式，那就是 Etag 属性。服务器在返回资源的时候，在头信息中添加了 Etag 属性，这个属性是资源生成的唯一标识符，当资源发生改变的时候，这个值也会发生改变。在下一次资源请求时，浏览器会在请求头中添加一个 If-None-Match 属性，这个属性的值就是上次返回的资源的 Etag 的值。服务接收到请求后会根据这个值来和资源当前的 Etag 的值来进行比较，以此来判断资源是否发生改变，是否需要返回资源。通过这种方式，比 Last-Modified 的方式更加精确。

当 Last-Modified 和 Etag 属性同时出现的时候，Etag 的优先级更高。使用协商缓存的时候，服务器需要考虑负载平衡的问题，因此多个服务器上资源的 Last-Modified 应该保持一致，因为每个服务器上 Etag 的值都不一样，因此在考虑负载平衡时，最好不要设置 Etag 属性。

总结：

强缓存策略和协商缓存策略在缓存命中时都会直接使用本地的缓存副本，区别只在于协商缓存会向服务器发送一次请求。它们缓存不命中时，都会向服务器发送请求来获取资源。在实际的缓存机制中，强缓存策略和协商缓存策略是一起合作使用的。浏览器首先会根据请求的信息判断，强缓存是否命中，如果命中则直接使用资源。如果不命中则根据头信息向服务器发起请求，使用协商缓存，如果协商缓存命中的话，则服务器不返回资源，浏览器直接使用本地资源的副本，如果协商缓存不命中，则浏览器返回最新的资源给浏览器。

为什么需要浏览器缓存？

所谓的浏览器缓存指的是浏览器将用户请求过的静态资源，存储到电脑本地磁盘中，当浏览器再次访问时，就可以直接从本地加载，不需要再去服务端请求了。

使用浏览器缓存，有以下优点：

减少了服务器的负担，提高了网站的性能
加快了客户端网页的加载速度
减少了多余网络数据传输

点击刷新按钮或者按 F5、按 Ctrl+F5 （强制刷新）、地址栏回车有什么区别？

点击刷新按钮或者按 F5：浏览器直接对本地的缓存文件过期，但是会带上If-Modifed-Since，If-None-Match，这就意味着服务器会对文件检查新鲜度，返回结果可能是 304，也有可能是 200。
用户按 Ctrl+F5（强制刷新）：浏览器不仅会对本地文件过期，而且不会带上 If-Modifed-Since，If-None-Match，相当于之前从来没有请求过，返回结果是 200。
地址栏回车：浏览器发起请求，按照正常流程，本地检查是否过期，然后服务器检查新鲜度，最后返回内容。

浏览器组成

对浏览器的理解

浏览器可以分为两部分，shell 和内核。其中 shell 的种类相对比较多，内核则比较少。

shell 是指浏览器的外壳：例如菜单，工具栏等。主要是提供给用户界面操作，参数设置等等。它是调用内核来实现各种功能的。
内核是浏览器的核心。内核是基于标记语言显示内容的程序或模块。

对浏览器内核的理解

浏览器内核主要分成两部分：

渲染引擎就是渲染，即在浏览器窗口中显示所请求的内容。默认情况下，渲染引擎可以显示 html、xml 文档及图片，它也可以借助插件显示其他类型数据，例如PDF 格式。
JS 引擎：解析和执行 javascript 来实现网页的动态效果。

最开始渲染引擎和 JS 引擎并没有区分的很明确，后来 JS 引擎越来越独立，内核就倾向于只指渲染引擎。

常见浏览器内核

5大主流浏览器	内核
IE	trident
chrome	webkit -> blink
safari	webkit
firefox	gocko
opera	presto -> blink

浏览器的主要组成部分

⽤户界⾯ - 包括地址栏、前进/后退按钮、书签菜单等。除了浏览器主窗⼝显示的您请求的⻚⾯外，其他显示的各个部分都属于⽤户界⾯。
浏览器引擎 - 在⽤户界⾯和呈现引擎之间传送指令。
渲染引擎 - 负责显示请求的内容。如果请求的内容是 HTML，它就负责解析 HTML 和 CSS 内容，并将解析后的内容显示在屏幕上。
⽹络 - ⽤于⽹络调⽤，⽐如 HTTP 请求。其接⼝与平台⽆关，并为所有平台提供底层实现。
JavaScript 解释器。⽤于解析和执⾏ JavaScript 代码。
数据存储 - 这是持久层。浏览器需要在硬盘上保存各种数据，例如 Cookie。新的 HTML 规范 (HTML5) 定义了“⽹络数据库”，这是⼀个完整（但是轻便）的浏览器内数据库。

浏览器的每个标签⻚都分别对应⼀个呈现引擎实例。每个标签⻚都是⼀个独⽴的进程

浏览器渲染机制

DOM tree

解析是根据收到的HTML文件生成DOM树；加载是加载内部资源，比如img等；

解析和加载异步完成，解析完毕并不说明页面加载完毕

加载，当前节点若解析完成（并不是页面解析完成），就开始加载资源

解析过程中：

解析过程是将节点挂载到DOM树上，遵循深度优先解析原则
遇到link的外部css，遇到css的代码会进行css的加载，并行操作
遇见script标签时，会先执行js代码，然后继续构建DOM树，这就是在底部加入JavaScript代码的原因。

CSSom

CSSom类似于DOM tree的生成过程。

渲染树

render tree = DOM tree + CSS tree，渲染树构建完毕后，浏览器的渲染引擎根据它绘制页面。

渲染树不包含隐藏节点，display:none head类等不需要绘制的节点；visibility: hidden 绘制了只是看不见
渲染树的每个节点都有自己的样式，被当成一个盒子box，具有内容填充、边距、边框、位置、大小等其他样式

回流与重绘

当浏览器渲染引擎对页面的节点操作时，就会产生回流或者重绘。回流一定重绘，重绘不一定回流

回流reflow

当浏览器生成渲染树以后，就会根据渲染树来进行布局。这一阶段浏览器要弄清楚各个节点在页面中的确切位置和大小，所有相对测量值都将转换为屏幕上的绝对像素。这一过程被称为回流，也被称为“自动重排”。

当元素属性发生改变且影响布局时（宽度、高度、内外边距等），产生回流，相当于刷新页面。

回流是相当消耗性能的，开发中应该减少回流次数
回流会引起渲染树中的一部分或全部重新构建
引起回流的因素：
- 页面初始化，即（至少有一次回流）
- DOM节点增加删除、位置变化
- 元素的尺寸、边距、填充、边框、显示(display:none block)改变
- 浏览器窗口尺寸变化，resize
- 向浏览器请求某些样式信息 offset client scroll width

重绘repaint

当元素属性发生改变且不影响布局时（背景颜色、透明度、字体样式等），产生重绘，相当于不刷新页面，动态更新内容。

若发生回流，浏览器根据新的渲染树重新绘制，这个过程称为重绘

优化策略

浏览器队列处理机制
增添样式放在 class中，批量处理，减少回流次数或者 this.style.cssText 做动态值变化
使用 visibility 替换 display: none ，因为前者只会引起重绘，后者会引发回流
documentFragment
动画一定要做绝对定位，相对定位每次变化都会引起父级的回流重绘
……

浏览器的渲染队列机制：浏览器会将所有的回流、重绘的操作放在一个队列中，当队列中的操作到了一定的数量或者到了一定的时间间隔，浏览器就会对队列进行批处理。这样就会让多次的回流、重绘变成一次回流重绘。

渲染过程中遇到JS文件如何处理

JavaScript文件的加载、解析与执行会阻塞DOM的构建，JS文件也会导致CSSOM阻塞DOM的构建

async、defer和window.onload的区别

async属性的script脚本：HTML解析与script加载并行发生，但在script执行时，HTML解析被阻塞，script执行结束后，继续HTML解析。多个带async属性的标签，不能保证加载的顺序

defer属性的script脚本：HTML解析与script加载并行发生，但script的执行要等到所有的HTML解析完成后才会发生。多个带defer属性的标签，按照顺序执行

1.defer和async在网络加载过程是一致的，都是异步执行的；

2.两者的区别在于脚本加载完成之后何时执行

window.onload() 方法用于在网页加载完毕后立刻执行的操作，即当 HTML 文档加载完毕后，立刻执行某个方法。

CSS如何阻塞文档解析

理论上，样式表不改变DOM树，也就没有必要停下文档解析等待它们。但是，JavaScript脚本执行时可能会请求样式信息，如果样式还没有加载解析，脚本会得到错误的值。

为了避免这种错误，浏览器会先下载和构建 CSSOM，然后再执行 JavaScript，最后再继续文档的解析。至此，CSS可以阻塞文档解析

浏览器渲染优化

针对JavaScript：

（1）尽量将JavaScript文件放在body的最后，用async和defer属性来异步引入

（2） body中间尽量不要写<script>标签

针对CSS：

（1）在开发过程中，导入外部样式使用link，而不用@import。

（2）如果css少，尽可能采用内嵌样式，直接写在style标签中

使用CSS有三种方式：使用link、@import、内联样式，其中link和@import都是导入外部样式。区别：

link：浏览器会派发一个新线程(HTTP线程)去加载资源文件，与此同时GUI渲染线程会继续向下渲染代码
@import：GUI渲染线程会暂时停止渲染，去服务器加载资源文件，资源文件没有返回之前不会继续渲染(阻碍浏览器渲染)
style：GUI直接渲染

外部样式如果长时间没有加载完毕，浏览器为了用户体验，会使用浏览器会默认样式，确保首次渲染的速度。所以CSS一般写在head中，让浏览器尽快发送请求去获取css样式。

针对DOM树、CSSOM树

（1）HTML代码层级尽量不要太深，减少CSSD代码的层级

（2）使用语义化的标签，避免不标准语义化的特殊处理

减少回流与重绘

如何优化关键渲染路径？

关键渲染路径是浏览器将 HTML，CSS 和 JavaScript 转换为屏幕上的像素所经历的步骤序列。

通过异步、延迟加载或者消除非关键资源来减少关键资源的请求数量
优化必须的请求数量和每个请求的文件体积
通过区分关键资源的优先级来优化被加载关键资源的顺序，来缩短关键路径长度。

一定要掌握的时间线

在浏览器加载页面开始到页面加载完成，按顺序发生的每一件事情

生成document对象，以供DOM操作
解析文档，构建DOM树

document.readyState = ‘loading’
遇到link开始异步加载css外部文件的新线程，遇到style开始异步构建CSSOM的新线程
没有设置异步加载的script，阻塞文档解析，等到JS脚本加载并执行完成后，继续解析文档
异步加载script，异步加载JS脚本，不阻塞解析文档（不能使用documen.write)
解析文档遇到img，先解析节点。创建加载线程，异步加载图片资源，不阻塞解析文档
文档解析完成，document.readyState = ‘interactive’
defer script，JS脚本按照顺序执行
DOMContentLoaded事件，
async script加载并执行完毕，img等资源加载完毕，window对象中的onload事件才开始触发，document.readyState = ‘complete’

window.onload 和 DOMContentLoaded的区别：window.onload是页面全部加载完毕才触发，DOMContentLoaded是文档解析完成和异步脚本加载完成后就触发

浏览器本地存储

浏览器本地存储方式主要5种，点击随便一个网页，F12，应用程序下的存储就可以看到了。

下面的学习对应着一个真实的网页会快很多

Cookie是最早被提出来的本地存储方式，在此之前，服务端是无法判断网络中的两个请求是否是同一用户发起的，为解决这个问题，Cookie就出现了。Cookie的大小只有4kb，它是一种纯文本文件，每次发起HTTP请求都会携带Cookie

Cookie的特性：

Cookie一旦创建成功，名称就无法修改
Cookie是无法跨域名的
每个Cookie的大小不能超过4kb
Cookie在请求一个新的页面的时候都会被发送过去

如果需要域名之间跨域共享Cookie，有两种方法：

使用Nginx反向代理
在一个站点登陆之后，往其他网站写Cookie。服务端的Session存储到一个节点，Cookie存储sessionId

Cookie的使用场景：

最常见的使用场景就是Cookie和session结合使用，我们将sessionId存储到Cookie中，每次发请求都会携带这个sessionId，这样服务端就知道是谁发起的请求，从而响应相应的信息。
可以用来统计页面的点击次数

Cookie字段组成：

Name：cookie的名称
Value：cookie的值，对于认证cookie，value值包括web服务器所提供的访问令牌；
Size： cookie的大小
Domain：可以访问该cookie的域名，Cookie 机制并未遵循严格的同源策略，允许一个子域可以设置或获取其父域的 Cookie。

当需要实现单点登录方案时，Cookie 的上述特性非常有用，然而也增加了 Cookie受攻击的危险，比如攻击者可以借此发动会话定置攻击。因而，浏览器禁止在 Domain 属性中设置.org、.com 等通用顶级域名、以及在国家及地区顶级域下注册的二级域名，以减小攻击发生的范围。
Path：可以访问此cookie的页面路径。比如domain是ychch.com，path是/about，那么只有/about路径下的页面可以读取此cookie
Secure：指定是否使用HTTPS安全协议发送Cookie。使用HTTPS安全协议，可以保护Cookie在浏览器和Web服务器间的传输过程中不被窃取和篡改。该方法也可用于Web站点的身份鉴别，即在HTTPS的连接建立阶段，浏览器会检查Web网站的SSL证书的有效性。

但是基于兼容性的原因（比如有些网站使用自签署的证书）在检测到SSL证书无效时，浏览器并不会立即终止用户的连接请求，而是显示安全风险信息，用户仍可以选择继续访问该站点。
HTTP：该字段包含HTTPOnly 属性，该属性用来设置cookie能否通过脚本来访问，默认为空，即可以通过脚本访问。在客户端是不能通过js代码去设置一个httpOnly类型的cookie的，这种类型的cookie只能通过服务端来设置。该属性用于防止客户端脚本通过document.cookie属性访问Cookie，有助于保护Cookie不被跨站脚本攻击窃取或篡改。但是，HTTPOnly的应用仍存在局限性，一些浏览器可以阻止客户端脚本对Cookie的读操作，但允许写操作；此外大多数浏览器仍允许通过XMLHTTP对象读取HTTP响应中的Set-Cookie头。
Expires/Max-size ：此cookie的超时时间。若设置其值为一个时间，那么当到达此时间后，此cookie失效。不设置的话默认值是Session，意思是cookie会和session一起失效。当浏览器关闭(不是浏览器标签页，而是整个浏览器) 后，此cookie失效。

LocalStorage

LocalStorage是HTML5新引入的特性。

LocalStorage的优点：

在大小方面，LocalStorage的大小一般为5MB，有时候我们存储的信息较大，Cookie就不能满足我们的需求，LocalStorage可以储存更多的信息
LocalStorage是持久储存，并不会随着页面的关闭而消失，除非主动清理，不然会永久存在
仅储存在本地，不像Cookie那样每次HTTP请求都会被携带

LocalStorage的缺点：

浏览器兼容问题，IE8以下不支持
隐私模式，无法读取LocalStorage
LocalStorage受到同源策略的限制，即端口、协议、主机地址有任何一个不相同，都不会访问

LocalStorage的常用API：

// 保存数据到 localStorage
localStorage.setItem('key', 'value');

// 从 localStorage 获取数据
let data = localStorage.getItem('key');

// 从 localStorage 删除保存的数据
localStorage.removeItem('key');

// 从 localStorage 删除所有保存的数据
localStorage.clear();

// 获取某个索引的Key
localStorage.key(index)

LocalStorage的使用场景：

有些网站有换肤的功能，这时候就可以将换肤的信息存储在本地的LocalStorage中，当需要换肤的时候，直接操作LocalStorage即可
在网站中的用户浏览信息和一些不常变动的个人信息等可以存储在本地的LocalStorage中

SessionStorage

SessionStorage和LocalStorage都是在HTML5才提出来的存储方案，SessionStorage 主要用于临时保存同一窗口(或标签页)的数据，刷新页面时不会删除，关闭窗口或标签页之后将会删除这些数据。

SessionStorage与LocalStorage对比：

都在本地进行数据存储；
都不能被爬虫爬取；
SessionStorage也有同源策略的限制，但是更严格，SessionStorage只有在同一浏览器的同一窗口下才能够共享；

SessionStorage的使用场景

由于SessionStorage具有时效性，可以用来存储游客登录的信息和临时的浏览记录。当关闭网站之后，这些信息也就随之消除了。

IndexedDB

cookies、localStorage、sessionStorage都是存储少量数据的存储方式，当需要在本地存储大量数据时，使用浏览器的 indexDB 。

这是浏览器提供的一种本地的数据库存储机制。它不是关系型数据库，更接近 NoSQL 数据库。它内部⽤键值对进⾏存储数据，可以进⾏快速读取操作，⾮常适合web场景，同时⽤JavaScript进⾏操作会⾮常方便。

IndexedDB 具有以下特点

键值对储存：IndexedDB 内部采用对象仓库（object store）存放数据，所有类型的数据都可以直接存入。

对象仓库中，数据以”键值对”的形式保存，每一个数据记录都有对应的主键，主键是独一无二的，不能有重复，否则会抛出一个错误。
异步：IndexedDB 操作时不会锁死浏览器，用户依然可以进行其他操作，这与 LocalStorage 形成对比，后者的操作是同步的。

异步设计是为了防止大量数据的读写，拖慢网页的表现。
支持事务：IndexedDB 支持事务（transaction），系列操作中，只要有一步失败，整个事务就都取消，数据库回滚到事务发生之前的状态，不存在只改写一部分数据的情况。
同源限制：IndexedDB 受到同源限制，每一个数据库对应创建它的域名。网页只能访问自身域名下的数据库，而不能访问跨域的数据库。
储存空间大：IndexedDB 的储存空间比 LocalStorage 大得多，一般来说不少于 250MB，甚至没有上限。
支持二进制储存：IndexedDB 不仅可以储存字符串，还可以储存二进制数据（ArrayBuffer 对象和 Blob 对象）。

浏览器同源策略

同源策略

同源策略（Same origin policy）是一种约定，它是浏览器最核心也最基本的安全功能，如果缺少了同源策略，则浏览器的正常功能可能都会受到影响。可以说 Web 是构建在同源策略基础之上的，浏览器只是针对同源策略的一种实现。

它认为自任何站点装载的信赖内容是不安全的。当被浏览器半信半疑的脚本运行在沙箱时，它们应该只被允许访问来自同一站点的资源，而不是那些来自其它站点可能怀有恶意的资源。

同源指的是：protocol协议、domain域名、port端口号必须一致。

同源政策主要限制了三个方面：

当前域下的 js 脚本不能够访问其他域下的 cookie、localStorage 和 indexDB。
当前域下的 js 脚本不能够操作访问操作其他域下的 DOM。
当前域下 ajax 无法发送跨域请求。

如何解决跨域问题

有了跨域限制，才使我们能安全的上网。但是在实际中，有时候我们需要突破这样的限制，下面将介绍几种跨域的解决方法。

CORS

CORS是一种W3C标准，它允许服务器通过一些自定义的头部来限制哪些源可以访问它自身的资源。CORS需要浏览器和服务器同时支持。

整个CORS通信过程，都是浏览器自动完成，不需要用户参与。对于开发者来说，CORS通信与同源的AJAX通信没有差别，代码完全一样。浏览器一旦发现AJAX请求跨源，就会自动添加一些附加的头信息，有时还会多出一次附加的请求，但用户不会有感觉。

实现CORS通信的关键是服务器。只要服务器实现了CORS接口，就可以跨源通信。

根据是否需要预检请求，CORS可以分为简单请求和复杂请求

简单请求

满足以下两大条件，就属于简单请求

（1) 请求方法是以下三种方法之一：
HEAD
GET
POST
（2）HTTP的头信息不超出以下几种字段：
Accept
Accept-Language
Content-Language
Last-Event-ID
Content-Type：只限于三个值application/x-www-form-urlencoded、multipart/form-data、text/plain

对于简单请求，浏览器直接发出CORS请求。浏览器在头信息之中，自动增加一个Origin字段。Origin字段用来说明，本次请求来自哪个源（协议 + 域名 + 端口）。服务器根据这个值，决定是否同意这次请求。

如果Origin指定的源，不在许可范围内，服务器会返回一个正常的HTTP回应。这种错误无法通过状态码识别，因为HTTP回应的状态码有可能是200。

如果Origin指定的域名在许可范围内，响应报文会多出几个头信息字段。

//要么是请求时Origin字段的值，要么是一个*
Access-Control-Allow-Origin: http://api.bob.com
//布尔值，表示是否允许发送Cookie
Access-Control-Allow-Credentials: true
//如果想拿到其他字段，就必须在Access-Control-Expose-Headers里面指定。
Access-Control-Expose-Headers: FooBar

withCredentials

CORS请求默认不发送Cookie和HTTP认证信息，如果要把Cookie发到服务器，一方面服务器同意，指定Access-Control-Allow-Credentials = true 字段；另一方面，请求中打开withCredentials属性

需要注意的是，如果要发送Cookie，Access-Control-Allow-Origin就不能设为星号，必须指定明确的、与请求网页一致的域名。

非简单请求

对服务器有特殊要求的请求，比如请求方法是PUT或DELETE，或者Content-Type字段的类型是application/json

浏览器先询问服务器，当前网页所在的域名是否在服务器的许可名单之中，以及可以使用哪些HTTP动词和头信息字段。只有得到肯定答复，浏览器才会发出正式的XMLHttpRequest请求，否则就报错。

“预检”请求用的请求方法是OPTIONS，表示这个请求是用来询问的。除了Origin字段，”预检”请求的头信息包括两个特殊字段。

Access-Control-Request-Method

该字段是必须的，用来列出浏览器的CORS请求会用到哪些HTTP方法，上例是PUT

Access-Control-Request-Headers

一个逗号分隔的字符串，指定浏览器CORS请求会额外发送的头信息字段，上例是X-Custom-Header

JSONP

利用<script>标签没有跨域限制，通过<script>标签src属性，发送带有callback参数的GET请求，服务端将接口返回数据拼凑到callback函数中，返回给浏览器，浏览器解析执行，从而前端拿到callback函数返回的数据。

// 原生JavaScript实现
<script>
    var script = document.createElement('script');
    script.type = 'text/javascript';
    // 传参一个回调函数名给后端，方便后端返回时执行这个在前端定义的回调函数
    script.src = 'http://www.domain2.com:8080/login?user=admin&callback=handleCallback';
    document.head.appendChild(script);
    // 回调执行函数
    function handleCallback(res) {
        alert(JSON.stringify(res));
    }
 </script>

JSONP的缺点：

具有局限性，仅支持get方法
不安全，可能会遭受XSS攻击

postMessage跨域

postMessage是HTML5 XMLHttpRequest Level 2中的API，且是为数不多可以跨域操作的window属性之一。

window.postMessage() 方法允许来自一个文档的脚本可以传递文本消息到另一个文档里的脚本，可以用这种消息传递技术来实现安全的通信，称为“跨文档消息传递”。

发送消息

postMessage(data,origin)方法接受两个参数：

data： html5规范支持任意基本类型或可复制的对象，但部分浏览器只支持字符串，所以传参时最好用JSON.stringify()序列化。
origin：协议+主机+端口号，也可以设置为”*”，表示可以传递给任意窗口，如果要指定和当前窗口同源的话设置为”/“。

接收消息

如果指定的源匹配的话，那么当调用 postMessage() 方法的时候，在目标窗口的Window对象上就会触发一个 message 事件。

nginx代理跨域

Nginx跨域的原理是利用Nginx的代理功能，让浏览器认为它访问的是同源的服务器，而实际上是访问了其他的服务器。这样就避免了浏览器的跨域限制。

nodejs中间件代理跨域

node中间件实现跨域代理，原理大致与nginx相同，是一种解决前后端交互时跨域问题的方法。它利用Nodejs作为中间层，转发前端的请求到后端服务器，从而绕过浏览器的同源策略。

document.domain + iframe跨域

此方案仅限主域相同，子域不同的跨域应用场景。父窗口：(domain.com/a.html)，子窗口：(child.domain.com/a.html)。两个页面都通过js强制设置document.domain为基础主域domain.com，就实现了同域。

WebSocket协议跨域

WebSocket协议是一种在浏览器和服务器之间进行全双工通信的技术。WebSocket协议不受同源策略的限制，因此可以跨域请求。

利用webSocket的API，可以直接new一个socket实例，然后通过open方法内send要传输到后台的值，也可以利用message方法接收后台传来的数据。

正向代理和反向代理

正向代理：隐藏客户端

客户端想获得一个服务器的数据，但是因为种种原因无法直接获取。于是客户端设置了一个代理服务器，并且指定目标服务器，之后代理服务器向目标服务器转交请求并将获得的内容发送给客户端。这样本质上起到了对真实服务器隐藏真实客户端的目的。实现正向代理需要修改客户端，比如修改浏览器配置。

反向代理：隐藏服务器

服务器为了能够将工作负载分不到多个服务器来提高网站性能 (负载均衡)等目的，当其受到请求后，会首先根据转发规则来确定请求应该被转发到哪个服务器上，然后将请求转发到对应的真实服务器上。这样本质上起到了对客户端隐藏真实服务器的作用。

一般使用反向代理后，需要通过修改 DNS 让域名解析到代理服务器 IP，这时浏览器无法察觉到真正服务器的存在，当然也就不需要修改配置了。

两者异同

正向代理和反向代理的结构是一样的，都是 client-proxy-server 的结构，它们主要的区别就在于中间这个 proxy 是哪一方设置的。在正向代理中，proxy 是 client 设置的，用来隐藏 client；而在反向代理中，proxy 是 server 设置的，用来隐藏 server。

正向代理和反向代理

Nginx的概念及其工作原理

Nginx 是一款轻量级的 Web 服务器，也可以用于反向代理、负载平衡和 HTTP 缓存等。Nginx 使用异步事件驱动的方法来处理请求，是一款面向性能设计的 HTTP 服务器。

传统的 Web 服务器如 Apache 是 process-based 模型的，而 Nginx 是基于event-driven模型的。正是这个主要的区别带给了 Nginx 在性能上的优势。

Nginx 架构的最顶层是一个 master process，这个 master process 用于产生其他的 worker process，这一点和Apache 非常像，但是 Nginx 的 worker process 可以同时处理大量的HTTP请求，而每个 Apache process 只能处理一个。

浏览器事件机制

事件是什么

事件是用户操作网页时发生的交互动作，比如 click/move，事件除了用户触发的动作外，还可以是文档加载，窗口滚动和大小调整。事件被封装成一个 event 对象，包含了该事件发生时的所有相关信息（ event 的属性）以及可以对事件进行的操作（ event 的方法）

事件是用户操作网页时发生的交互动作或者网页本身的一些操作，现代浏览器一共有三种事件模型：

DOM0 级事件模型，这种模型不会传播，所以没有事件流的概念，但是现在有的浏览器支持以冒泡的方式实现，它可以在网页中直接定义监听函数，也可以通过 js 属性来指定监听函数。所有浏览器都兼容这种方式。直接在dom对象上注册事件名称，就是DOM0写法。
IE 事件模型，在该事件模型中，一次事件共有两个过程，事件处理阶段和事件冒泡阶段。事件处理阶段会首先执行目标元素绑定的监听事件。然后是事件冒泡阶段，冒泡指的是事件从目标元素冒泡到 document，依次检查经过的节点是否绑定了事件监听函数，如果有则执行。这种模型通过attachEvent 来添加监听函数，可以添加多个监听函数，会按顺序依次执行。
DOM2 级事件模型，在该事件模型中，一次事件共有三个过程，第一个过程是事件捕获阶段。捕获指的是事件从 document 一直向下传播到目标元素，依次检查经过的节点是否绑定了事件监听函数，如果有则执行。后面两个阶段和 IE 事件模型的两个阶段相同。这种事件模型，事件绑定的函数是addEventListener，其中第三个参数可以指定事件是否在捕获阶段执行。

如何阻止事件冒泡

普通浏览器使用：event.stopPropagation()
IE浏览器使用：event.cancelBubble = true;

事件委托

事件委托是利用浏览器事件冒泡的机制，将子节点的监听函数定义在父节点上，由父节点的监听函数统一处理多个子元素的事件，这种方式称为事件委托。

使用事件委托可以不必要为每一个子元素都绑定一个监听事件，减少内存消耗。并且还可以实现事件动态绑定，比如说新增了一个子节点，并不需要单独地为它添加一个监听事件，它绑定的事件会交给父元素中的监听函数来处理。

事件委托不是只有优点，它也是有缺点的：

比如 focus、blur 之类的事件没有事件冒泡机制，所以无法实现事件委托；mousemove、mouseout 这样的事件，虽然有事件冒泡，但是只能不断通过位置去计算定位，对性能消耗高，因此也是不适合于事件委托的。

浏览器垃圾回收机制

GC就是Garbage Collection 也就是我们常说的垃圾回收机制，它工作在引擎的内部，对于前端来说是相对无感的。

一般的高级语言里面会自带 GC，比如 Java、Python、JavaScript 等，也有无 GC 的语言，比如 C、C++ 等，那这种就需要我们程序员手动管理内存了，相对比较麻烦。

V8的垃圾回收机制

V8 的垃圾回收策略主要基于分代式垃圾回收机制，V8 中将堆内存分为新生代和老生代两区域，采用不同的垃圾回收器。

新生代的对象为存活时间较短的对象，简单来说就是新产生的对象，通常只支持1～8M的容量，而老生代的对象为存活时间较长或常驻内存的对象，简单来说就是经历过新生代垃圾回收后还存活下来的对象，容量通常比较大。

新生代垃圾回收器

新生代对象是通过一个名为 Scavenge 的算法进行垃圾回收，主要采用了一种复制式的方法即 Cheney 算法：

Cheney 算法 中将堆内存一分为二，一个是处于使用状态的空间我们暂且称之为 使用区，一个是处于闲置状态的空间我们称之为 空闲区：

当开始进行垃圾回收时，新生代垃圾回收器会对使用区中的活动对象做标记，标记完成之后将使用区的活动对象复制进空闲区并进行排序，随后进入垃圾清理阶段，即将非活动对象占用的空间清理掉。最后进行角色互换，把原来的使用区变成空闲区，把原来的空闲区变成使用区。

老生代垃圾回收

先来说下什么情况下对象会出现在老生代空间中：

新生代中的对象是否已经经历过一次 Scavenge 算法，如果经历过的话，会将对象从新生代空间移到老生代空间中。
To 空间的对象占比大小超过 25 %。在这种情况下，为了不影响到内存分配，会将对象从新生代空间移到老生代空间中。

对于大多数占用空间大、存活时间长的对象会被分配到老生代里，因为老生代中的对象通常比较大，如果再如新生代一般分区然后复制来复制去就会非常耗时，从而导致回收执行效率不高，所以老生代垃圾回收器来管理其垃圾回收执行，它的整个流程就采用的就是标记清除了。

标记阶段，从一组根元素开始，递归遍历这组根元素，遍历过程中能到达的元素称为活动对象，没有到达的元素就可以判断为非活动对象。

清除阶段，直接将非活动对象，也就是数据清理掉。

分代式机制把一些新、小、存活时间短的对象作为新生代，采用一小块内存频率较高的快速清理，而一些大、老、存活时间长的对象作为老生代，使其很少接受检查，新老生代的回收机制及频率是不同的，可以说此机制的出现很大程度提高了垃圾回收机制的效率。

并行回收

JavaScript 是一门单线程的语言，它是运行在主线程上的，那在进行垃圾回收时就会阻塞 JavaScript 脚本的执行，需等待垃圾回收完毕后再恢复脚本执行，我们把这种行为叫做 全停顿。

假如一次 GC 的时间过长，对用户来说就可能造成页面卡顿等问题。这里引入多个辅助线程来同时处理，以此加速垃圾回收的执行速度

在执行垃圾回收的过程中，会启动了多个线程来负责新生代中的垃圾清理操作，这些线程同时将对象空间中的数据移动到空闲区域，这个过程中由于数据地址会发生改变，所以还需要同步更新引用这些对象的指针，这就是并行回收。

增量标记

并行回收 可以提高回收效率，对于新生代垃圾回收器能够有很好的优化，但是它还是一种全停顿式的垃圾回收方式；

对于老生代来说，它的内部存放的都是一些比较大的对象，对于这些大的对象 GC 时哪怕我们使用并行策略依然可能会消耗大量时间

在 2011 年，V8 对老生代的标记进行了优化，从 全停顿标记切换到增量标记

如果采用非黑即白的标记策略，那在垃圾回收器执行了一段增量回收后，暂停后启用主线程去执行了应用程序中的一段JavaScript 代码，随后当垃圾回收器再次被启动，这时候内存中黑白色都有，我们无法得知下一步走到哪里了

为了解决这个问题，V8 团队采用了一种特殊方式： 三色标记法

惰性清理

增量标记其实只是对活动对象和非活动对象进行标记，对于真正的清理释放内存 V8 采用的是惰性清理

当增量标记完成后，假如当前的可用内存足以让我们快速的执行代码，其实我们是没必要立即清理内存的，可以将清理过程稍微延迟一下，让 JavaScript 脚本代码先执行，也无需一次性清理完所有非活动对象内存，可以按需逐一进行清理直到所有的非活动对象内存都清理完毕，后面再接着执行增量标记。

并发回收

并行回收依然会阻塞主线程，增量标记同样有增加了总暂停时间、降低应用程序吞吐量两个缺点，那么怎么才能在不阻塞主线程的情况下执行垃圾回收并且与增量相比更高效呢？

并发回收了，它指的是主线程在执行 JavaScript 的过程中，辅助线程能够在后台完成执行垃圾回收的操作，辅助线程在执行垃圾回收的时候，主线程也可以自由执行而不会被挂起：

辅助线程在执行垃圾回收的时候，主线程也可以自由执行而不会被挂起，这是并发的优点，但同样也是并发回收实现的难点，因为它需要考虑主线程在执行 JavaScript 时，堆中的对象引用关系随时都有可能发生变化，这时辅助线程之前做的一些标记或者正在进行的标记就会要有所改变，所以它需要额外实现一些读写锁机制来控制这一点。

总结

新生代主要使用分为了使用区和空闲区，使用相关的算法进行垃圾回收机制;
老生代使用标记清除算法，还是使用了并行回收、增量标记、惰性清理来辅提高回收效率，增量标记中使用三色标记法来达到暂停和恢复的作用;
还是使用并发回收使回收更高效;

浏览器安全

XSS攻击

攻击类型

如何抵御XSS

CSRF攻击

如何抵御CSRF

有哪些可能引起前端安全

网络劫持有哪几种，如何防范？

进程与线程

浏览器的进程

渲染进程的线程有哪些

进程之间的通信方式

僵尸进程和孤儿进程是什么？

死锁？ 如何解决死锁？

浏览器缓存

对浏览器缓存机制的理解

浏览器资源缓存位置

Server Worker

Memory Cache

Disk Cache

访问缓存优先级

协商缓存和强缓存的区别

强缓存

协商缓存

为什么需要浏览器缓存？

点击刷新按钮或者按 F5、按 Ctrl+F5 （强制刷新）、地址栏回车有什么区别？

浏览器组成

对浏览器的理解

对浏览器内核的理解

常见浏览器内核

浏览器的主要组成部分

浏览器渲染机制

DOM tree

CSSom

渲染树

回流与重绘

回流reflow

重绘repaint

优化策略

渲染过程中遇到JS文件如何处理

async、defer和window.onload的区别

CSS如何阻塞文档解析

浏览器渲染优化

如何优化关键渲染路径？

一定要掌握的时间线

浏览器本地存储

Cookie

LocalStorage

SessionStorage

IndexedDB

浏览器同源策略

同源策略

如何解决跨域问题

CORS

简单请求

withCredentials

非简单请求

JSONP

postMessage跨域

nginx代理跨域

nodejs中间件代理跨域

document.domain + iframe跨域

WebSocket协议跨域

正向代理和反向代理

Nginx的概念及其工作原理

浏览器事件机制

事件是什么

如何阻止事件冒泡

事件委托

浏览器垃圾回收机制

V8的垃圾回收机制

新生代垃圾回收器

老生代垃圾回收

并行回收

增量标记

惰性清理

并发回收

总结

死锁？如何解决死锁？