浏览器原理面试题58题

1.什么是 XSS 攻击？

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

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

攻击者可以通过这种攻击方式可以进行以下操作：

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

XSS的攻击类型可以分为存储型、反射型和 DOM 型：

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

1）存储型XSS的攻击步骤：

攻击者将恶意代码提交到⽬标⽹站的数据库中。
⽤户打开⽬标⽹站时，⽹站服务端将恶意代码从数据库取出，拼接在 HTML 中返回给浏览器。
⽤户浏览器接收到响应后解析执⾏，混在其中的恶意代码也被执⾏。
恶意代码窃取⽤户数据并发送到攻击者的⽹站，或者冒充⽤户的⾏为，调⽤⽬标⽹站接⼝执⾏攻击者指定的操作。

这种攻击常⻅于带有⽤户保存数据的⽹站功能，如论坛发帖、商品评论、⽤户私信等。

2）反射型XSS的攻击步骤：

攻击者构造出特殊的 URL，其中包含恶意代码。
⽤户打开带有恶意代码的 URL 时，⽹站服务端将恶意代码从 URL 中取出，拼接在 HTML 中返回给浏览器。
⽤户浏览器接收到响应后解析执⾏，混在其中的恶意代码也被执⾏。
恶意代码窃取⽤户数据并发送到攻击者的⽹站，或者冒充⽤户的⾏为，调⽤⽬标⽹站接⼝执⾏攻击者指定的操作。

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

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

3）DOM型XSS****的攻击步骤：

攻击者构造出特殊的 URL，其中包含恶意代码。
⽤户打开带有恶意代码的 URL。
⽤户浏览器接收到响应后解析执⾏，前端 JavaScript 取出 URL 中的恶意代码并执⾏。
恶意代码窃取⽤户数据并发送到攻击者的⽹站，或者冒充⽤户的⾏为，调⽤⽬标⽹站接⼝执⾏攻击者指定的操作。

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

2.如何防御 XSS 攻击？

可以看到XSS危害如此之大，那么在开发网站时就要做好防御措施，具体措施如下：

可以从浏览器的执行来进行预防，一种是使用纯前端的方式，不用服务器端拼接后返回（不使用服务端渲染）。另一种是对需要插入到 HTML 中的代码做好充分的转义。对于 DOM 型的攻击，主要是前端脚本的不可靠而造成的，对于数据获取渲染和字符串拼接的时候应该对可能出现的恶意代码情况进行判断。
使用 CSP ，CSP 的本质是建立一个白名单，告诉浏览器哪些外部资源可以加载和执行，从而防止恶意代码的注入攻击。

CSP 指的是内容安全策略，它的本质是建立一个白名单，告诉浏览器哪些外部资源可以加载和执行。我们只需要配置规则，如何拦截由浏览器自己来实现。
通常有两种方式来开启 CSP，一种是设置 HTTP 首部中的 Content-Security-Policy，一种是设置 meta 标签的方式 <meta http-equiv="Content-Security-Policy">

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

3.什么是 CSRF 攻击？

CSRF 攻击指的是跨站请求伪造攻击，攻击者诱导用户进入一个第三方网站，然后该网站向被攻击网站发送跨站请求。如果用户在被攻击网站中保存了登录状态，那么攻击者就可以利用这个登录状态，绕过后台的用户验证，冒充用户向服务器执行一些操作。

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

常见的 CSRF 攻击类型有三种：

GET 类型的 CSRF 攻击，比如在网站中的一个 img 标签里构建一个请求，当用户打开这个网站的时候就会自动发起提交。
POST 类型的 CSRF 攻击，比如构建一个表单，然后隐藏它，当用户进入页面时，自动提交这个表单。
链接类型的 CSRF 攻击，比如在 a 标签的 href 属性里构建一个请求，然后诱导用户去点击。

4.如何防御 CSRF 攻击？

CSRF 攻击可以使用以下方法来防护：

进行同源检测，服务器根据 http 请求头中 origin 或者 referer 信息来判断请求是否为允许访问的站点，从而对请求进行过滤。当 origin 或者 referer 信息都不存在的时候，直接阻止请求。这种方式的缺点是有些情况下 referer 可以被伪造，同时还会把搜索引擎的链接也给屏蔽了。所以一般网站会允许搜索引擎的页面请求，但是相应的页面请求这种请求方式也可能被攻击者给利用。（Referer 字段会告诉服务器该网页是从哪个页面链接过来的）
使用 CSRF Token 进行验证，服务器向用户返回一个随机数 Token ，当网站再次发起请求时，在请求参数中加入服务器端返回的 token ，然后服务器对这个 token 进行验证。这种方法解决了使用 cookie 单一验证方式时，可能会被冒用的问题，但是这种方法存在一个缺点就是，我们需要给网站中的所有请求都添加上这个 token，操作比较繁琐。还有一个问题是一般不会只有一台网站服务器，如果请求经过负载平衡转移到了其他的服务器，但是这个服务器的 session 中没有保留这个 token 的话，就没有办法验证了。这种情况可以通过改变 token 的构建方式来解决。
对Cookie 进行双重验证，服务器在用户访问网站页面时，向请求域名注入一个Cookie，内容为随机字符串，然后当用户再次向服务器发送请求的时候，从 cookie 中取出这个字符串，添加到 URL 参数中，然后服务器通过对 cookie 中的数据和参数中的数据进行比较，来进行验证。使用这种方式是利用了攻击者只能利用 cookie，但是不能访问获取 cookie 的特点。并且这种方法比 CSRF Token 的方法更加方便，并且不涉及到分布式访问的问题。这种方法的缺点是如果网站存在 XSS 漏洞的，那么这种方式会失效。同时这种方式不能做到子域名的隔离。
在设置 cookie 属性的时候设置 Samesite ，限制 cookie 不能作为被第三方使用，从而可以避免被攻击者利用。Samesite 一共有两种模式，一种是严格模式，在严格模式下 cookie 在任何情况下都不可能作为第三方 Cookie 使用，在宽松模式下，cookie 可以被请求是 GET 请求，且会发生页面跳转的请求所使用。

5.什么是中间人攻击？如何防范中间人攻击？

中间⼈ (Man-in-the-middle attack, MITM) 是指攻击者与通讯的两端分别创建独⽴的联系, 并交换其所收到的数据, 使通讯的两端认为他们正在通过⼀个私密的连接与对⽅直接对话, 但事实上整个会话都被攻击者完全控制。在中间⼈攻击中，攻击者可以拦截通讯双⽅的通话并插⼊新的内容。

攻击过程如下:

客户端发送请求到服务端，请求被中间⼈截获
服务器向客户端发送公钥
中间⼈截获公钥，保留在⾃⼰⼿上。然后⾃⼰⽣成⼀个伪造的公钥，发给客户端
客户端收到伪造的公钥后，⽣成加密hash值发给服务器
中间⼈获得加密hash值，⽤⾃⼰的私钥解密获得真秘钥,同时⽣成假的加密hash值，发给服务器
服务器⽤私钥解密获得假密钥,然后加密数据传输给客户端

中间人的攻击很难防御。攻击者有很多选择，这意味着防范MITM攻击是多管齐下的。

使用HTTPS：确保你访问的每个网站都使用HTTPS。我们已经讨论过SSLStrip和MITM恶意软件，但是确保HTTPS是最好的防御选择之一。为了获得额外的保护层，可以考虑下载并安装电子前沿基金会的HTTPS Everywhere浏览器扩展，这是谷歌Chrome最好的隐私扩展之一。
不要忽略警告：如果你的浏览器告诉你正在访问的网站有问题，相信它。安全证书警告可能是将凭据授予攻击者和保持安全之间的区别。
不要使用公共Wi-Fi：如果你能帮上忙，就不要使用公共Wi-Fi。有时，使用公共Wi-Fi是不可避免的。如果您必须使用公共Wi-Fi连接，则应下载并安装VPN，为您的连接添加一些安全性。此外，在使用公共Wi-Fi连接时，请注意浏览器安全警告。如果浏览器警告的数量突然增加，则可能表明存在MITM攻击或漏洞。
运行并更新防病毒软件：确保您的防病毒软件是最新的。

中间人攻击取决于你的通讯是否受到影响。如果你知道该期待什么，知道该寻找什么，你就有更大的机会避免MITM的攻击。反过来，您的数据将保持安全并牢牢掌握在您的手中。

6. 有哪些可能引起前端安全的问题?

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

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

⽹络劫持分为两种:

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

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

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

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

8. 进程与线程的概念

从本质上说，进程和线程都是 CPU 工作时间片的一个描述：

进程描述了 CPU 在运行指令及加载和保存上下文所需的时间，放在应用上来说就代表了一个程序。
线程是进程中的更小单位，描述了执行一段指令所需的时间。

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

一个进程就是一个程序的运行实例。详细解释就是，启动一个程序的时候，操作系统会为该程序创建一块内存，用来存放代码、运行中的数据和一个执行任务的主线程，我们把这样的一个运行环境叫进程。进程是运行在虚拟内存上的，虚拟内存是用来解决用户对硬件资源的无限需求和有限的硬件资源之间的矛盾的。从操作系统角度来看，虚拟内存即交换文件；从处理器角度看，虚拟内存即虚拟地址空间。

如果程序很多时，内存可能会不够，操作系统为每个进程提供一套独立的虚拟地址空间，从而使得同一块物理内存在不同的进程中可以对应到不同或相同的虚拟地址，变相的增加了程序可以使用的内存。

进程和线程之间的关系有以下四个特点：

（1）进程中的任意一线程执行出错，都会导致整个进程的崩溃。

（2）线程之间共享进程中的数据。

（3）当一个进程关闭之后，操作系统会回收进程所占用的内存，**当一个进程退出时，操作系统会回收该进程所申请的所有资源；即使其中任意线程因为操作不当导致内存泄漏，当进程退出时，这些内存也会被正确回收。

（4）进程之间的内容相互隔离。**进程隔离就是为了使操作系统中的进程互不干扰，每一个进程只能访问自己占有的数据，也就避免出现进程 A 写入数据到进程 B 的情况。正是因为进程之间的数据是严格隔离的，所以一个进程如果崩溃了，或者挂起了，是不会影响到其他进程的。如果进程之间需要进行数据的通信，这时候，就需要使用用于进程间通信的机制了。

Chrome浏览器的架构图：

从图中可以看出，最新的 Chrome 浏览器包括：

1 个浏览器主进程
1 个 GPU 进程
1 个网络进程
多个渲染进程
多个插件进程

这些进程的功能：

浏览器进程：主要负责界面显示、用户交互、子进程管理，同时提供存储等功能。
渲染进程：核心任务是将 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 运行环境），这就意味着浏览器会消耗更多的内存资源。
更复杂的体系架构：浏览器各模块之间耦合性高、扩展性差等问题，会导致现在的架构已经很难适应新的需求了。

9. 进程和线程的区别

进程可以看做独立应用，线程不能
资源：进程是cpu资源分配的最小单位（是能拥有资源和独立运行的最小单位）；线程是cpu调度的最小单位（线程是建立在进程的基础上的一次程序运行单位，一个进程中可以有多个线程）。
通信方面：线程间可以通过直接共享同一进程中的资源，而进程通信需要借助进程间通信。
调度：进程切换比线程切换的开销要大。线程是CPU调度的基本单位，线程的切换不会引起进程切换，但某个进程中的线程切换到另一个进程中的线程时，会引起进程切换。
系统开销：由于创建或撤销进程时，系统都要为之分配或回收资源，如内存、I/O 等，其开销远大于创建或撤销线程时的开销。同理，在进行进程切换时，涉及当前执行进程 CPU 环境还有各种各样状态的保存及新调度进程状态的设置，而线程切换时只需保存和设置少量寄存器内容，开销较小。

10. 浏览器渲染进程的线程有哪些

浏览器的渲染进程的线程总共有五种：

（1）GUI渲染线程

负责渲染浏览器页面，解析HTML、CSS，构建DOM树、构建CSSOM树、构建渲染树和绘制页面；当界面需要重绘或由于某种操作引发回流时，该线程就会执行。

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

（2）JS引擎线程

JS引擎线程也称为JS内核，负责处理Javascript脚本程序，解析Javascript脚本，运行代码；JS引擎线程一直等待着任务队列中任务的到来，然后加以处理，一个Tab页中无论什么时候都只有一个JS引擎线程在运行JS程序；

注意：GUI渲染线程与JS引擎线程的互斥关系，所以如果JS执行的时间过长，会造成页面的渲染不连贯，导致页面渲染加载阻塞。

（3）事件触发线程

事件触发线程属于浏览器而不是JS引擎，用来控制事件循环；当JS引擎执行代码块如setTimeOut时（也可是来自浏览器内核的其他线程,如鼠标点击、AJAX异步请求等），会将对应任务添加到事件触发线程中；当对应的事件符合触发条件被触发时，该线程会把事件添加到待处理队列的队尾，等待JS引擎的处理；

注意：由于JS的单线程关系，所以这些待处理队列中的事件都得排队等待JS引擎处理（当JS引擎空闲时才会去执行）；

（4）定时器触发进程

定时器触发进程即setInterval与setTimeout所在线程；浏览器定时计数器并不是由JS引擎计数的，因为JS引擎是单线程的，如果处于阻塞线程状态就会影响记计时的准确性；因此使用单独线程来计时并触发定时器，计时完毕后，添加到事件队列中，等待JS引擎空闲后执行，所以定时器中的任务在设定的时间点不一定能够准时执行，定时器只是在指定时间点将任务添加到事件队列中；

注意：W3C在HTML标准中规定，定时器的定时时间不能小于4ms，如果是小于4ms，则默认为4ms。

（5）异步http请求线程

XMLHttpRequest连接后通过浏览器新开一个线程请求；
检测到状态变更时，如果设置有回调函数，异步线程就产生状态变更事件，将回调函数放入事件队列中，等待JS引擎空闲后执行；

11. 进程之间的通信方式

（1）管道通信

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

管道的特点：

只能单向通信
只能血缘关系的进程进行通信
依赖于文件系统
生命周期随进程
面向字节流的服务
管道内部提供了同步机制

（2）消息队列通信

消息队列就是一个消息的列表。用户可以在消息队列中添加消息、读取消息等。消息队列提供了一种从一个进程向另一个进程发送一个数据块的方法。每个数据块都被认为含有一个类型，接收进程可以独立地接收含有不同类型的数据结构。可以通过发送消息来避免命名管道的同步和阻塞问题。但是消息队列与命名管道一样，每个数据块都有一个最大长度的限制。

使用消息队列进行进程间通信，可能会收到数据块最大长度的限制约束等，这也是这种通信方式的缺点。如果频繁的发生进程间的通信行为，那么进程需要频繁地读取队列中的数据到内存，相当于间接地从一个进程拷贝到另一个进程，这需要花费时间。

（3）信号量通信

共享内存最大的问题就是多进程竞争内存的问题，就像类似于线程安全问题。我们可以使用信号量来解决这个问题。信号量的本质就是一个计数器，用来实现进程之间的互斥与同步。例如信号量的初始值是 1，然后 a 进程来访问内存1的时候，我们就把信号量的值设为 0，然后进程b 也要来访问内存1的时候，看到信号量的值为 0 就知道已经有进程在访问内存1了，这个时候进程 b 就会访问不了内存1。所以说，信号量也是进程之间的一种通信方式。

（4）信号通信

信号（Signals ）是Unix系统中使用的最古老的进程间通信的方法之一。操作系统通过信号来通知进程系统中发生了某种预先规定好的事件（一组事件中的一个），它也是用户进程之间通信和同步的一种原始机制。

（5）共享内存通信

共享内存就是映射一段能被其他进程所访问的内存，这段共享内存由一个进程创建，但多个进程都可以访问（使多个进程可以访问同一块内存空间）。共享内存是最快的 IPC 方式，它是针对其他进程间通信方式运行效率低而专门设计的。它往往与其他通信机制，如信号量，配合使用，来实现进程间的同步和通信。

（6）套接字通信

上面我们说的共享内存、管道、信号量、消息队列，他们都是多个进程在一台主机之间的通信，那两个相隔几千里的进程能够进行通信吗？答是必须的，这个时候 Socket 这家伙就派上用场了，例如我们平时通过浏览器发起一个 http 请求，然后服务器给你返回对应的数据，这种就是采用 Socket 的通信方式了。

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

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

13. 死锁产生的原因？如果解决死锁的问题？

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

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

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

产生死锁的原因：

（1）竞争资源

产生死锁中的竞争资源之一指的是竞争不可剥夺资源（例如：系统中只有一台打印机，可供进程P1使用，假定P1已占用了打印机，若P2继续要求打印机打印将阻塞）
产生死锁中的竞争资源另外一种资源指的是竞争临时资源（临时资源包括硬件中断、信号、消息、缓冲区内的消息等），通常消息通信顺序进行不当，则会产生死锁

（2）进程间推进顺序非法

若P1保持了资源R1，P2保持了资源R2，系统处于不安全状态，因为这两个进程再向前推进，便可能发生死锁。例如，当P1运行到P1：Request（R2）时，将因R2已被P2占用而阻塞；当P2运行到P2：Request（R1）时，也将因R1已被P1占用而阻塞，于是发生进程死锁

产生死锁的必要条件：

互斥条件：进程要求对所分配的资源进行排它性控制，即在一段时间内某资源仅为一进程所占用。
请求和保持条件：当进程因请求资源而阻塞时，对已获得的资源保持不放。
不可剥夺条件：进程已获得的资源在未使用完之前，不能剥夺，只能在使用完时由自己释放。
环路等待条件：在发生死锁时，必然存在一个进程——资源的环形链。

预防死锁的方法：

资源一次性分配：一次性分配所有资源，这样就不会再有请求了（破坏请求条件）
只要有一个资源得不到分配，也不给这个进程分配其他的资源（破坏请保持条件）
可剥夺资源：即当某进程获得了部分资源，但得不到其它资源，则释放已占有的资源（破坏不可剥夺条件）
资源有序分配法：系统给每类资源赋予一个编号，每一个进程按编号递增的顺序请求资源，释放则相反（破坏环路等待条件）

14. 如何实现浏览器内多个标签页之间的通信?

实现多个标签页之间的通信，本质上都是通过中介者模式来实现的。因为标签页之间没有办法直接通信，因此我们可以找一个中介者，让标签页和中介者进行通信，然后让这个中介者来进行消息的转发。通信方法如下：

使用 websocket 协议，因为 websocket 协议可以实现服务器推送，所以服务器就可以用来当做这个中介者。标签页通过向服务器发送数据，然后由服务器向其他标签页推送转发。
使用 ShareWorker 的方式，shareWorker 会在页面存在的生命周期内创建一个唯一的线程，并且开启多个页面也只会使用同一个线程。这个时候共享线程就可以充当中介者的角色。标签页间通过共享一个线程，然后通过这个共享的线程来实现数据的交换。
使用 localStorage 的方式，我们可以在一个标签页对 localStorage 的变化事件进行监听，然后当另一个标签页修改数据的时候，我们就可以通过这个监听事件来获取到数据。这个时候 localStorage 对象就是充当的中介者的角色。
使用 postMessage 方法，如果我们能够获得对应标签页的引用，就可以使用postMessage 方法，进行通信。

15. 对Service Worker的理解

Service Worker 是运行在浏览器背后的独立线程，一般可以用来实现缓存功能。使用 Service Worker的话，传输协议必须为 HTTPS。因为 Service Worker 中涉及到请求拦截，所以必须使用 HTTPS 协议来保障安全。

Service Worker 实现缓存功能一般分为三个步骤：首先需要先注册 Service Worker，然后监听到 install 事件以后就可以缓存需要的文件，那么在下次用户访问的时候就可以通过拦截请求的方式查询是否存在缓存，存在缓存的话就可以直接读取缓存文件，否则就去请求数据。以下是这个步骤的实现：

// index.js
if (navigator.serviceWorker) {
  navigator.serviceWorker
    .register('sw.js')
    .then(function(registration) {
      console.log('service worker 注册成功')
    })
    .catch(function(err) {
      console.log('servcie worker 注册失败')
    })
}
// sw.js
// 监听 `install` 事件，回调中缓存所需文件
self.addEventListener('install', e => {
  e.waitUntil(
    caches.open('my-cache').then(function(cache) {
      return cache.addAll(['./index.html', './index.js'])
    })
  )
})
// 拦截所有请求事件
// 如果缓存中已经有请求的数据就直接用缓存，否则去请求数据
self.addEventListener('fetch', e => {
  e.respondWith(
    caches.match(e.request).then(function(response) {
      if (response) {
        return response
      }
      console.log('fetch source')
    })
  )
})

打开页面，可以在开发者工具中的 Application 看到 Service Worker 已经启动了：

在 Cache 中也可以发现所需的文件已被缓存：

16. 对浏览器的缓存机制的理解

浏览器HTTP缓存策略分为两种：强缓存和协商缓存，都是通过设置 HTTP Header 来实现的。

强缓存：不会向服务器发送请求，直接从缓存中读取资源，强缓存可以通过设置两种 HTTP Header 实现：Expires 和 Cache-Control对比：Cache-Control优先级高于Expires
Expires：缓存过期时间，用来指定资源到期的时间，是服务器端具体的时间点 Expires 是 HTTP/1 的产物，受限于本地时间，如果修改了本地时间，可能会造成缓存失效
Cache-Control: HTTP/1.1 的产物，比如当设置Cache-Control:max-age=300，单位是s，代表5分钟内再次请求就会走强缓存
协商缓存：协商缓存就是强制缓存失效后，浏览器携带缓存标识向服务器发起请求，由服务器根据缓存标识决定是否使用缓存的过程协商缓存可以通过设置两种 HTTP Header 实现：Last-Modified 和 ETag对比：ETag更精确，性能上Last-Modified好点
Last-Modified: http1.0 原理：浏览器第一次访问资源时，服务器会在response头里添加Last-Modified时间点，这个时间点是服务器最后修改文件的时间点，然后浏览器第二次访问资源时，检测到缓存文件里有Last-Modified，就会在请求头里加If-Modified-Since，值为Last-Modified的值，服务器收到头里有If-Modified-Since，就会拿这个值和请求文件的最后修改时间作对比，如果没有变化，就返回304，如果小于了最后修改时间，说明文件有更新，就会返回新的资源，状态码为200
ETag: http1.1 原理：与Last-Modified类似，只是Last-Modified返回的是最后修改的时间点，而ETag是每次访问服务器都会返回一个新的token，第二次请求时，该值埋在请求头里的If-None-Match发送给服务器，服务器在比较新旧的token是否一致，一致则返回304通知浏览器使用本地缓存，不一致则返回新的资源，新的ETag，状态码为200
如果什么缓存策略都不设置：这种情况，浏览器会采用一个启发式的算法，通常会取响应头中的 Date 减去 Last-Modified 值的 10% 作为缓存时间

17. 浏览器资源缓存的位置有哪些？

Service Worker：Service Worker 运行在 JavaScript 主线程之外，虽然由于脱离了浏览器窗体无法直接访问 DOM，但是它可以完成离线缓存、消息推送、网络代理等功能。它可以让我们自由控制缓存哪些文件、如何匹配缓存、如何读取缓存，并且缓存是持续性的。当 Service Worker 没有命中缓存的时候，需要去调用 fetch 函数获取数据。也就是说，如果没有在 Service Worker 命中缓存，会根据缓存查找优先级去查找数据。但是不管是从 Memory Cache 中还是从网络请求中获取的数据，浏览器都会显示是从 Service Worker 中获取的内容。
Memory Cache：Memory Cache 就是内存缓存，它的效率最快，但是内存缓存虽然读取高效，可是缓存持续性很短，会随着进程的释放而释放。一旦我们关闭 Tab 页面，内存中的缓存也就被释放了。
Disk Cache：Disk Cache 也就是存储在硬盘中的缓存，读取速度慢点，但是什么都能存储到磁盘中，比之 Memory Cache 胜在容量和存储时效性上。在所有浏览器缓存中，Disk Cache 覆盖面基本是最大的。它会根据 HTTP Herder 中的字段判断哪些资源需要缓存，哪些资源可以不请求直接使用，哪些资源已经过期需要重新请求。并且即使在跨站点的情况下，相同地址的资源一旦被硬盘缓存下来，就不会再次去请求数据。

Disk Cache：Push Cache 是 HTTP/2 中的内容，当以上三种缓存都没有命中时，它才会被使用。并且缓存时间也很短暂，只在会话（Session）中存在，一旦会话结束就被释放。其具有以下特点：

所有的资源都能被推送，但是 Edge 和 Safari 浏览器兼容性不怎么好
可以推送 no-cache 和 no-store 的资源
一旦连接被关闭，Push Cache 就被释放
多个页面可以使用相同的 HTTP/2 连接，也就是说能使用同样的缓存
Push Cache 中的缓存只能被使用一次
浏览器可以拒绝接受已经存在的资源推送
可以给其他域名推送资源

18. 协商缓存和强缓存的区别

（1）强缓存

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

强缓存策略可以通过两种方式来设置，分别是 http 头信息中的 Expires 属性和 Cache-Control 属性。

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

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

Cache-Control可设置的字段：

public：设置了该字段值的资源表示可以被任何对象（包括：发送请求的客户端、代理服务器等等）缓存。这个字段值不常用，一般还是使用max-age=来精确控制；
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 是指不使用任何缓存，每次请求都直接从服务器获取资源。

（2）协商缓存

如果命中强制缓存，我们无需发起新的请求，直接使用缓存内容，如果没有命中强制缓存，如果设置了协商缓存，这个时候协商缓存就会发挥作用了。

上面已经说到了，命中协商缓存的条件有两个：

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

使用协商缓存策略时，会先向服务器发送一个请求，如果资源没有发生修改，则返回一个 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 属性。

总结：

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

19. 为什么需要浏览器缓存？

对于浏览器的缓存，主要针对的是前端的静态资源，最好的效果就是，在发起请求之后，拉取相应的静态资源，并保存在本地。如果服务器的静态资源没有更新，那么在下次请求的时候，就直接从本地读取即可，如果服务器的静态资源已经更新，那么我们再次请求的时候，就到服务器拉取新的资源，并保存在本地。这样就大大的减少了请求的次数，提高了网站的性能。这就要用到浏览器的缓存策略了。

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

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

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

20. 对浏览器内核的理解

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

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

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

21. 常见的浏览器内核比较

Trident：这种浏览器内核是 IE 浏览器用的内核，因为在早期 IE 占有大量的市场份额，所以这种内核比较流行，以前有很多网页也是根据这个内核的标准来编写的，但是实际上这个内核对真正的网页标准支持不是很好。但是由于 IE 的高市场占有率，微软也很长时间没有更新 Trident 内核，就导致了 Trident 内核和 W3C 标准脱节。还有就是 Trident 内核的大量 Bug 等安全问题没有得到解决，加上一些专家学者公开自己认为 IE 浏览器不安全的观点，使很多用户开始转向其他浏览器。
Gecko：这是 Firefox 和 Flock 所采用的内核，这个内核的优点就是功能强大、丰富，可以支持很多复杂网页效果和浏览器扩展接口，但是代价是也显而易见就是要消耗很多的资源，比如内存。
Presto：Opera 曾经采用的就是 Presto 内核，Presto 内核被称为公认的浏览网页速度最快的内核，这得益于它在开发时的天生优势，在处理 JS 脚本等脚本语言时，会比其他的内核快3倍左右，缺点就是为了达到很快的速度而丢掉了一部分网页兼容性。
Webkit：Webkit 是 Safari 采用的内核，它的优点就是网页浏览速度较快，虽然不及 Presto 但是也胜于 Gecko 和 Trident，缺点是对于网页代码的容错性不高，也就是说对网页代码的兼容性较低，会使一些编写不标准的网页无法正确显示。WebKit 前身是 KDE 小组的 KHTML 引擎，可以说 WebKit 是 KHTML 的一个开源的分支。
Blink：谷歌在 Chromium Blog 上发表博客，称将与苹果的开源浏览器核心 Webkit 分道扬镳，在 Chromium 项目中研发 Blink 渲染引擎（即浏览器核心），内置于 Chrome 浏览器之中。其实 Blink 引擎就是 Webkit 的一个分支，就像 webkit 是KHTML 的分支一样。Blink 引擎现在是谷歌公司与 Opera Software 共同研发，上面提到过的，Opera 弃用了自己的 Presto 内核，加入 Google 阵营，跟随谷歌一起研发 Blink。

22. 常见浏览器所用内核

（1） IE 浏览器内核：Trident 内核，也是俗称的 IE 内核；

（2） Chrome 浏览器内核：统称为 Chromium 内核或 Chrome 内核，以前是 Webkit 内核，现在是 Blink内核；

（3） Firefox 浏览器内核：Gecko 内核，俗称 Firefox 内核；

（4） Safari 浏览器内核：Webkit 内核；

（5） Opera 浏览器内核：最初是自己的 Presto 内核，后来加入谷歌大军，从 Webkit 又到了 Blink 内核；

（6） 360浏览器、猎豹浏览器内核：IE + Chrome 双内核；

（7）搜狗、遨游、QQ 浏览器内核：Trident（兼容模式）+ Webkit（高速模式）；

（8）百度浏览器、世界之窗内核：IE 内核；

（9） 2345浏览器内核：好像以前是 IE 内核，现在也是 IE + Chrome 双内核了；

（10）UC 浏览器内核：这个众口不一，UC 说是他们自己研发的 U3 内核，但好像还是基于 Webkit 和 Trident ，还有说是基于火狐内核。

23. 浏览器的主要组成部分

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

值得注意的是，和⼤多数浏览器不同，Chrome 浏览器的每个标签⻚都分别对应⼀个呈现引擎实例。每个标签⻚都是⼀个独⽴的进程。

24. 浏览器的渲染过程

浏览器渲染主要有以下步骤：

首先解析收到的文档，根据文档定义构建一棵 DOM 树，DOM 树是由 DOM 元素及属性节点组成的。
然后对 CSS 进行解析，生成 CSSOM 规则树。
根据 DOM 树和 CSSOM 规则树构建渲染树。渲染树的节点被称为渲染对象，渲染对象是一个包含有颜色和大小等属性的矩形，渲染对象和 DOM 元素相对应，但这种对应关系不是一对一的，不可见的 DOM 元素不会被插入渲染树。还有一些 DOM元素对应几个可见对象，它们一般是一些具有复杂结构的元素，无法用一个矩形来描述。
当渲染对象被创建并添加到树中，它们并没有位置和大小，所以当浏览器生成渲染树以后，就会根据渲染树来进行布局（也可以叫做回流）。这一阶段浏览器要做的事情是要弄清楚各个节点在页面中的确切位置和大小。通常这一行为也被称为“自动重排”。
布局阶段结束后是绘制阶段，遍历渲染树并调用渲染对象的 paint 方法将它们的内容显示在屏幕上，绘制使用 UI 基础组件。

大致过程如图所示：

注意：这个过程是逐步完成的，为了更好的用户体验，渲染引擎将会尽可能早的将内容呈现到屏幕上，并不会等到所有的html 都解析完成之后再去构建和布局 render 树。它是解析完一部分内容就显示一部分内容，同时，可能还在通过网络下载其余内容。

25. 浏览器渲染优化

（1）针对JavaScript：JavaScript既会阻塞HTML的解析，也会阻塞CSS的解析。因此我们可以对JavaScript的加载方式进行改变，来进行优化：

（1）尽量将JavaScript文件放在body的最后

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

（3）<script>标签的引入资源方式有三种，有一种就是我们常用的直接引入，还有两种就是使用 async 属性和 defer 属性来异步引入，两者都是去异步加载外部的JS文件，不会阻塞DOM的解析（尽量使用异步加载）。三者的区别如下：

script 立即停止页面渲染去加载资源文件，当资源加载完毕后立即执行js代码，js代码执行完毕后继续渲染页面；
async 是在下载完成之后，立即异步加载，加载好后立即执行，多个带async属性的标签，不能保证加载的顺序；
defer 是在下载完成之后，立即异步加载。加载好后，如果 DOM 树还没构建好，则先等 DOM 树解析好再执行；如果DOM树已经准备好，则立即执行。多个带defer属性的标签，按照顺序执行。

（2）针对CSS：*使用CSS有三种方式：使用*link、@import、内联样式，其中link和@import都是导入外部样式。它们之间的区别：

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

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

所以，在开发过程中，导入外部样式使用link，而不用@import。如果css少，尽可能采用内嵌样式，直接写在style标签中。

（3）针对DOM树、CSSOM树：

可以通过以下几种方式来减少渲染的时间：

HTML文件的代码层级尽量不要太深
使用语义化的标签，来避免不标准语义化的特殊处理
减少CSSD代码的层级，因为选择器是从右向左进行解析的

（4）减少回流与重绘：

操作DOM时，尽量在低层级的DOM节点进行操作
不要使用 table布局，一个小的改动可能会使整个 table进行重新布局
使用CSS的表达式
不要频繁操作元素的样式，对于静态页面，可以修改类名，而不是样式。
使用absolute或者fixed，使元素脱离文档流，这样他们发生变化就不会影响其他元素
避免频繁操作DOM，可以创建一个文档片段 documentFragment，在它上面应用所有DOM操作，最后再把它添加到文档中
将元素先设置 display: none，操作结束后再把它显示出来。因为在display属性为none的元素上进行的DOM操作不会引发回流和重绘。
将DOM的多个读操作（或者写操作）放在一起，而不是读写操作穿插着写。这得益于浏览器的渲染队列机制。

浏览器针对页面的回流与重绘，进行了自身的优化——渲染队列

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

将多个读操作（或者写操作）放在一起，就会等所有的读操作进入队列之后执行，这样，原本应该是触发多次回流，变成了只触发一次回流。

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

JavaScript 的加载、解析与执行会阻塞文档的解析，也就是说，在构建 DOM 时，HTML 解析器若遇到了 JavaScript，那么它会暂停文档的解析，将控制权移交给 JavaScript 引擎，等 JavaScript 引擎运行完毕，浏览器再从中断的地方恢复继续解析文档。也就是说，如果想要首屏渲染的越快，就越不应该在首屏就加载 JS 文件，这也是都建议将 script 标签放在 body 标签底部的原因。当然在当下，并不是说 script 标签必须放在底部，因为你可以给 script 标签添加 defer 或者 async 属性。

27. CSS 如何阻塞文档解析？

理论上，既然样式表不改变 DOM 树，也就没有必要停下文档的解析等待它们。然而，存在一个问题，JavaScript 脚本执行时可能在文档的解析过程中请求样式信息，如果样式还没有加载和解析，脚本将得到错误的值，显然这将会导致很多问题。所以如果浏览器尚未完成 CSSOM 的下载和构建，而我们却想在此时运行脚本，那么浏览器将延迟 JavaScript 脚本执行和文档的解析，直至其完成 CSSOM 的下载和构建。也就是说，在这种情况下，浏览器会先下载和构建 CSSOM，然后再执行 JavaScript，最后再继续文档的解析。

28.什么情况会阻塞渲染？

首先渲染的前提是生成渲染树，所以 HTML 和 CSS 肯定会阻塞渲染。如果你想渲染的越快，你越应该降低一开始需要渲染的文件大小，并且扁平层级，优化选择器。然后当浏览器在解析到 script 标签时，会暂停构建 DOM，完成后才会从暂停的地方重新开始。也就是说，如果你想首屏渲染的越快，就越不应该在首屏就加载 JS 文件，这也是都建议将 script 标签放在 body 标签底部的原因。

当然在当下，并不是说 script 标签必须放在底部，因为你可以给 script 标签添加 defer 或者 async 属性。当 script 标签加上 defer 属性以后，表示该 JS 文件会并行下载，但是会放到 HTML 解析完成后顺序执行，所以对于这种情况你可以把 script 标签放在任意位置。对于没有任何依赖的 JS 文件可以加上 async 属性，表示 JS 文件下载和解析不会阻塞渲染。

29. 浏览器本地存储方式及使用场景

（1）Cookie

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

Cookie的特性：

Cookie一旦创建成功，名称就无法修改
Cookie是无法跨域名的，也就是说a域名和b域名下的cookie是无法共享的，这也是由Cookie的隐私安全性决定的，这样就能够阻止非法获取其他网站的Cookie
每个域名下Cookie的数量不能超过20个，每个Cookie的大小不能超过4kb
有安全问题，如果Cookie被拦截了，那就可获得session的所有信息，即使加密也于事无补，无需知道cookie的意义，只要转发cookie就能达到目的
Cookie在请求一个新的页面的时候都会被发送过去

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

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

Cookie的使用场景：

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

（2）LocalStorage

LocalStorage是HTML5新引入的特性，由于有的时候我们存储的信息较大，Cookie就不能满足我们的需求，这时候LocalStorage就派上用场了。

LocalStorage的优点：

在大小方面，LocalStorage的大小一般为5MB，可以储存更多的信息
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中，还有网站的一些不常变动的个人信息等也可以存储在本地的LocalStorage中

（3）SessionStorage

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

SessionStorage与LocalStorage对比：

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

SessionStorage的常用API：

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

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

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

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

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

SessionStorage的使用场景

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

30. Cookie、LocalStorage、SessionStorage区别

浏览器端常用的存储技术是 cookie 、localStorage 和 sessionStorage。

cookie：其实最开始是服务器端用于记录用户状态的一种方式，由服务器设置，在客户端存储，然后每次发起同源请求时，发送给服务器端。cookie 最多能存储 4 k 数据，它的生存时间由 expires 属性指定，并且 cookie 只能被同源的页面访问共享。
sessionStorage：html5 提供的一种浏览器本地存储的方法，它借鉴了服务器端 session 的概念，代表的是一次会话中所保存的数据。它一般能够存储 5M 或者更大的数据，它在当前窗口关闭后就失效了，并且 sessionStorage 只能被同一个窗口的同源页面所访问共享。
localStorage：html5 提供的一种浏览器本地存储的方法，它一般也能够存储 5M 或者更大的数据。它和 sessionStorage 不同的是，除非手动删除它，否则它不会失效，并且 localStorage 也只能被同源页面所访问共享。

上面几种方式都是存储少量数据的时候的存储方式，当需要在本地存储大量数据的时候，我们可以使用浏览器的 indexDB 这是浏览器提供的一种本地的数据库存储机制。它不是关系型数据库，它内部采用对象仓库的形式存储数据，它更接近 NoSQL 数据库。

31. 前端储存的⽅式有哪些？

cookies：在HTML5标准前本地储存的主要⽅式，优点是兼容性好，请求头⾃带cookie⽅便，缺点是⼤⼩只有4k，⾃动请求头加⼊cookie浪费流量，每个domain限制20个cookie，使⽤起来麻烦，需要⾃⾏封装；
localStorage：HTML5加⼊的以键值对(Key-Value)为标准的⽅式，优点是操作⽅便，永久性储存（除⾮⼿动删除），⼤⼩为5M，兼容IE8+ ；
sessionStorage：与localStorage基本类似，区别是sessionStorage当⻚⾯关闭后会被清理，⽽且与cookie、localStorage不同，他不能在所有同源窗⼝中共享，是会话级别的储存⽅式；
Web SQL：2010年被W3C废弃的本地数据库数据存储⽅案，但是主流浏览器（⽕狐除外）都已经有了相关的实现，web sql类似于SQLite，是真正意义上的关系型数据库，⽤sql进⾏操作，当我们⽤JavaScript时要进⾏转换，较为繁琐；
IndexedDB：是被正式纳⼊HTML5标准的数据库储存⽅案，它是NoSQL数据库，⽤键值对进⾏储存，可以进⾏快速读取操作，⾮常适合web场景，同时⽤JavaScript进⾏操作会⾮常便。

32. IndexedDB有哪些特点？

IndexedDB 具有以下特点：

键值对储存：IndexedDB 内部采用对象仓库（object store）存放数据。所有类型的数据都可以直接存入，包括 JavaScript 对象。对象仓库中，数据以"键值对"的形式保存，每一个数据记录都有对应的主键，主键是独一无二的，不能有重复，否则会抛出一个错误。
异步：IndexedDB 操作时不会锁死浏览器，用户依然可以进行其他操作，这与 LocalStorage 形成对比，后者的操作是同步的。异步设计是为了防止大量数据的读写，拖慢网页的表现。
支持事务：IndexedDB 支持事务（transaction），这意味着一系列操作步骤之中，只要有一步失败，整个事务就都取消，数据库回滚到事务发生之前的状态，不存在只改写一部分数据的情况。
同源限制：IndexedDB 受到同源限制，每一个数据库对应创建它的域名。网页只能访问自身域名下的数据库，而不能访问跨域的数据库。
储存空间大：IndexedDB 的储存空间比 LocalStorage 大得多，一般来说不少于 250MB，甚至没有上限。
支持二进制储存：IndexedDB 不仅可以储存字符串，还可以储存二进制数据（ArrayBuffer 对象和 Blob 对象）。

33.什么是同源策略

跨域问题其实就是浏览器的同源策略造成的。

同源策略限制了从同一个源加载的文档或脚本如何与另一个源的资源进行交互。这是浏览器的一个用于隔离潜在恶意文件的重要的安全机制。同源指的是：协议、端口号、域名必须一致。

下表给出了与 URL http://store.company.com/dir/page.html 的源进行对比的示例:

URL	是否跨域	原因
http://store.company.com/dir/page.html	同源	完全相同
http://store.company.com/dir/inner/another.html	同源	只有路径不同
https://store.company.com/secure.html	跨域	协议不同
http://store.company.com:81/dir/etc.html	跨域	端口不同 ( http:// 默认端口是80)
http://news.company.com/dir/other.html	跨域	主机不同

同源策略：protocol（协议）、domain（域名）、port（端口）三者必须一致。

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

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

同源政策的目的主要是为了保证用户的信息安全，它只是对 js 脚本的一种限制，并不是对浏览器的限制，对于一般的 img、或者script 脚本请求都不会有跨域的限制，这是因为这些操作都不会通过响应结果来进行可能出现安全问题的操作。

34.如何解决跨越问题

（1）CORS

下面是MDN对于CORS的定义：

跨域资源共享(CORS) 是一种机制，它使用额外的 HTTP 头来告诉浏览器让运行在一个 origin (domain)上的Web应用被准许访问来自不同源服务器上的指定的资源。当一个资源从与该资源本身所在的服务器不同的域、协议或端口请求一个资源时，资源会发起一个跨域HTTP 请求。

CORS需要浏览器和服务器同时支持，整个CORS过程都是浏览器完成的，无需用户参与。因此实现CORS的关键就是服务器，只要服务器实现了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

若不满足以上条件，就属于非简单请求了。

（1）简单请求过程：

对于简单请求，浏览器会直接发出CORS请求，它会在请求的头信息中增加一个Orign字段，该字段用来说明本次请求来自哪个源（协议+端口+域名），服务器会根据这个值来决定是否同意这次请求。如果Orign指定的域名在许可范围之内，服务器返回的响应就会多出以下信息头：

Access-Control-Allow-Origin: http://api.bob.com  // 和Orign一直
Access-Control-Allow-Credentials: true   // 表示是否允许发送Cookie
Access-Control-Expose-Headers: FooBar   // 指定返回其他字段的值
Content-Type: text/html; charset=utf-8   // 表示文档类型

如果Orign指定的域名不在许可范围之内，服务器会返回一个正常的HTTP回应，浏览器发现没有上面的Access-Control-Allow-Origin头部信息，就知道出错了。这个错误无法通过状态码识别，因为返回的状态码可能是200。

在简单请求中，在服务器内，至少需要设置字段：Access-Control-Allow-Origin

（2）非简单请求过程

非简单请求是对服务器有特殊要求的请求，比如请求方法为DELETE或者PUT等。非简单请求的CORS请求会在正式通信之前进行一次HTTP查询请求，称为预检请求。

浏览器会询问服务器，当前所在的网页是否在服务器允许访问的范围内，以及可以使用哪些HTTP请求方式和头信息字段，只有得到肯定的回复，才会进行正式的HTTP请求，否则就会报错。

预检请求使用的请求方法是OPTIONS，表示这个请求是来询问的。他的头信息中的关键字段是Orign，表示请求来自哪个源。除此之外，头信息中还包括两个字段：

Access-Control-Request-Method：该字段是必须的，用来列出浏览器的CORS请求会用到哪些HTTP方法。
Access-Control-Request-Headers：该字段是一个逗号分隔的字符串，指定浏览器CORS请求会额外发送的头信息字段。

服务器在收到浏览器的预检请求之后，会根据头信息的三个字段来进行判断，如果返回的头信息在中有Access-Control-Allow-Origin这个字段就是允许跨域请求，如果没有，就是不同意这个预检请求，就会报错。

服务器回应的CORS的字段如下：

Access-Control-Allow-Origin: http://api.bob.com  // 允许跨域的源地址
Access-Control-Allow-Methods: GET, POST, PUT // 服务器支持的所有跨域请求的方法
Access-Control-Allow-Headers: X-Custom-Header  // 服务器支持的所有头信息字段
Access-Control-Allow-Credentials: true   // 表示是否允许发送Cookie
Access-Control-Max-Age: 1728000  // 用来指定本次预检请求的有效期，单位为秒

只要服务器通过了预检请求，在以后每次的CORS请求都会自带一个Origin头信息字段。服务器的回应，也都会有一个Access-Control-Allow-Origin头信息字段。

在非简单请求中，至少需要设置以下字段：

'Access-Control-Allow-Origin'  
'Access-Control-Allow-Methods'
'Access-Control-Allow-Headers'

减少OPTIONS请求次数：

OPTIONS请求次数过多就会损耗页面加载的性能，降低用户体验度。所以尽量要减少OPTIONS请求次数，可以后端在请求的返回头部添加：Access-Control-Max-Age：number。它表示预检请求的返回结果可以被缓存多久，单位是秒。该字段只对完全一样的URL的缓存设置生效，所以设置了缓存时间，在这个时间范围内，再次发送请求就不需要进行预检请求了。

CORS中Cookie相关问题：

在CORS请求中，如果想要传递Cookie，就要满足以下三个条件：

在请求中设置withCredentials

默认情况下在跨域请求，浏览器是不带 cookie 的。但是我们可以通过设置 withCredentials 来进行传递 cookie.

// 原生 xml 的设置方式
var xhr = new XMLHttpRequest();
xhr.withCredentials = true;
// axios 设置方式
axios.defaults.withCredentials = true;

Access-Control-Allow-Credentials 设置为 true
Access-Control-Allow-Origin 设置为 false

（2）JSONP

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

1）原生JS实现：

<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>

服务端返回如下（返回时即执行全局函数）：

handleCallback({"success": true, "user": "admin"})

2）Vue axios实现：

this.$http = axios;
this.$http.jsonp('http://www.domain2.com:8080/login', {
    params: {},
    jsonp: 'handleCallback'
}).then((res) => {
    console.log(res); 
})

后端node.js代码：

var querystring = require('querystring');
var http = require('http');
var server = http.createServer();
server.on('request', function(req, res) {
    var params = querystring.parse(req.url.split('?')[1]);
    var fn = params.callback;
    // jsonp返回设置
    res.writeHead(200, { 'Content-Type': 'text/javascript' });
    res.write(fn + '(' + JSON.stringify(params) + ')');
    res.end();
});
server.listen('8080');
console.log('Server is running at port 8080...');

JSONP的缺点：

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

（3）postMessage 跨域

postMessage是HTML5 XMLHttpRequest Level 2中的API，且是为数不多可以跨域操作的window属性之一，它可用于解决以下方面的问题：

页面和其打开的新窗口的数据传递
多窗口之间消息传递
页面与嵌套的iframe消息传递
上面三个场景的跨域数据传递

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

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

1）a.html：(domain1.com/a.html)

<iframe id="iframe" src="http://www.domain2.com/b.html" rel="external nofollow"  rel="external nofollow"  style={{display:'none'}}></iframe>
<script>     
    var iframe = document.getElementById('iframe');
    iframe.onload = function() {
        var data = {
            name: 'aym'
        };
        // 向domain2传送跨域数据
        iframe.contentWindow.postMessage(JSON.stringify(data), 'http://www.domain2.com');
    };
    // 接受domain2返回数据
    window.addEventListener('message', function(e) {
        alert('data from domain2 ---> ' + e.data);
    }, false);
</script>

2）b.html：(domain2.com/b.html)

<script>
    // 接收domain1的数据
    window.addEventListener('message', function(e) {
        alert('data from domain1 ---> ' + e.data);
        var data = JSON.parse(e.data);
        if (data) {
            data.number = 16;
            // 处理后再发回domain1
            window.parent.postMessage(JSON.stringify(data), 'http://www.domain1.com');
        }
    }, false);
</script>

（4）nginx代理跨域

nginx代理跨域，实质和CORS跨域原理一样，通过配置文件设置请求响应头Access-Control-Allow-Origin…等字段。

1）nginx配置解决iconfont跨域

浏览器跨域访问js、css、img等常规静态资源被同源策略许可，但iconfont字体文件(eot|otf|ttf|woff|svg)例外，此时可在nginx的静态资源服务器中加入以下配置。

location / {
  add_header Access-Control-Allow-Origin *;
}

2）nginx反向代理接口跨域

跨域问题：同源策略仅是针对浏览器的安全策略。服务器端调用HTTP接口只是使用HTTP协议，不需要同源策略，也就不存在跨域问题。

实现思路：通过Nginx配置一个代理服务器域名与domain1相同，端口不同）做跳板机，反向代理访问domain2接口，并且可以顺便修改cookie中domain信息，方便当前域cookie写入，实现跨域访问。

nginx具体配置：

#proxy服务器
server {
    listen       81;
    server_name  www.domain1.com;
    location / {
        proxy_pass   http://www.domain2.com:8080;  #反向代理
        proxy_cookie_domain www.domain2.com www.domain1.com; #修改cookie里域名
        index  index.html index.htm;
        # 当用webpack-dev-server等中间件代理接口访问nignx时，此时无浏览器参与，故没有同源限制，下面的跨域配置可不启用
        add_header Access-Control-Allow-Origin http://www.domain1.com;  #当前端只跨域不带cookie时，可为*
        add_header Access-Control-Allow-Credentials true;
    }
}

（5）nodejs 中间件代理跨域

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

1）非vue框架的跨域

使用node + express + http-proxy-middleware搭建一个proxy服务器。

前端代码：

var xhr = new XMLHttpRequest();
// 前端开关：浏览器是否读写cookie
xhr.withCredentials = true;
// 访问http-proxy-middleware代理服务器
xhr.open('get', 'http://www.domain1.com:3000/login?user=admin', true);
xhr.send();

中间件服务器代码：

var express = require('express');
var proxy = require('http-proxy-middleware');
var app = express();
app.use('/', proxy({
    // 代理跨域目标接口
    target: 'http://www.domain2.com:8080',
    changeOrigin: true,
    // 修改响应头信息，实现跨域并允许带cookie
    onProxyRes: function(proxyRes, req, res) {
        res.header('Access-Control-Allow-Origin', 'http://www.domain1.com');
        res.header('Access-Control-Allow-Credentials', 'true');
    },
    // 修改响应信息中的cookie域名
    cookieDomainRewrite: 'www.domain1.com'  // 可以为false，表示不修改
}));
app.listen(3000);
console.log('Proxy server is listen at port 3000...');

2）vue框架的跨域

node + vue + webpack + webpack-dev-server搭建的项目，跨域请求接口，直接修改webpack.config.js配置。开发环境下，vue渲染服务和接口代理服务都是webpack-dev-server同一个，所以页面与代理接口之间不再跨域。

webpack.config.js部分配置：

module.exports = {
    entry: {},
    module: {},
    ...
    devServer: {
        historyApiFallback: true,
        proxy: [{
            context: '/login',
            target: 'http://www.domain2.com:8080',  // 代理跨域目标接口
            changeOrigin: true,
            secure: false,  // 当代理某些https服务报错时用
            cookieDomainRewrite: 'www.domain1.com'  // 可以为false，表示不修改
        }],
        noInfo: true
    }
}

（6）document.domain + iframe跨域

此方案仅限主域相同，子域不同的跨域应用场景。实现原理：两个页面都通过js强制设置document.domain为基础主域，就实现了同域。

1）父窗口：(domain.com/a.html)

<iframe id="iframe" src="http://child.domain.com/b.html" rel="external nofollow" ></iframe>
<script>
    document.domain = 'domain.com';
    var user = 'admin';
</script>

2）子窗口：(child.domain.com/a.html)

<script>
    document.domain = 'domain.com';
    // 获取父窗口中变量
    console.log('get js data from parent ---> ' + window.parent.user);
</script>

（7）location.hash + iframe跨域

实现原理：a欲与b跨域相互通信，通过中间页c来实现。三个页面，不同域之间利用iframe的location.hash传值，相同域之间直接js访问来通信。

具体实现：A域：a.html -> B域：b.html -> A域：c.html，a与b不同域只能通过hash值单向通信，b与c也不同域也只能单向通信，但c与a同域，所以c可通过parent.parent访问a页面所有对象。

1）a.html：(domain1.com/a.html)

<iframe id="iframe" src="http://www.domain2.com/b.html" rel="external nofollow"  rel="external nofollow"  style={{display:'none'}}></iframe>
<script>
    var iframe = document.getElementById('iframe');
    // 向b.html传hash值
    setTimeout(function() {
        iframe.src = iframe.src + '#user=admin';
    }, 1000);
  
    // 开放给同域c.html的回调方法
    function onCallback(res) {
        alert('data from c.html ---> ' + res);
    }
</script>

2）b.html：(.domain2.com/b.html)

<iframe id="iframe" src="http://www.domain1.com/c.html" rel="external nofollow"  style={{display:'none'}}></iframe>
<script>
    var iframe = document.getElementById('iframe');
    // 监听a.html传来的hash值，再传给c.html
    window.onhashchange = function () {
        iframe.src = iframe.src + location.hash;
    };
</script>

3）c.html：(http://www.domain1.com/c.html)

<script>
    // 监听b.html传来的hash值
    window.onhashchange = function () {
        // 再通过操作同域a.html的js回调，将结果传回
        window.parent.parent.onCallback('hello: ' + location.hash.replace('#user=', ''));
    };
</script>

（8）window.name + iframe跨域

window.name属性的独特之处：name值在不同的页面（甚至不同域名）加载后依旧存在，并且可以支持非常长的 name 值（2MB）。

1）a.html：(domain1.com/a.html)

var proxy = function(url, callback) {
    var state = 0;
    var iframe = document.createElement('iframe');
    // 加载跨域页面
    iframe.src = url;
    // onload事件会触发2次，第1次加载跨域页，并留存数据于window.name
    iframe.onload = function() {
        if (state === 1) {
            // 第2次onload(同域proxy页)成功后，读取同域window.name中数据
            callback(iframe.contentWindow.name);
            destoryFrame();
        } else if (state === 0) {
            // 第1次onload(跨域页)成功后，切换到同域代理页面
            iframe.contentWindow.location = 'http://www.domain1.com/proxy.html';
            state = 1;
        }
    };
    document.body.appendChild(iframe);
    // 获取数据以后销毁这个iframe，释放内存；这也保证了安全（不被其他域frame js访问）
    function destoryFrame() {
        iframe.contentWindow.document.write('');
        iframe.contentWindow.close();
        document.body.removeChild(iframe);
    }
};
// 请求跨域b页面数据
proxy('http://www.domain2.com/b.html', function(data){
    alert(data);
});

2）proxy.html：(domain1.com/proxy.html)

中间代理页，与a.html同域，内容为空即可。

3）b.html：(domain2.com/b.html)

<script>
    window.name = 'This is domain2 data!';
</script>

通过iframe的src属性由外域转向本地域，跨域数据即由iframe的window.name从外域传递到本地域。这个就巧妙地绕过了浏览器的跨域访问限制，但同时它又是安全操作。

（9）WebSocket协议跨域

WebSocket protocol是HTML5一种新的协议。它实现了浏览器与服务器全双工通信，同时允许跨域通讯，是server push技术的一种很好的实现。

原生WebSocket API使用起来不太方便，我们使用Socket.io，它很好地封装了webSocket接口，提供了更简单、灵活的接口，也对不支持webSocket的浏览器提供了向下兼容。

1）前端代码：

<div>user input：<input type="text"></div>
<script src="https://cdn.bootcss.com/socket.io/2.2.0/socket.io.js" rel="external nofollow" ></script>
<script>
var socket = io('http://www.domain2.com:8080');
// 连接成功处理
socket.on('connect', function() {
    // 监听服务端消息
    socket.on('message', function(msg) {
        console.log('data from server: ---> ' + msg); 
    });
    // 监听服务端关闭
    socket.on('disconnect', function() { 
        console.log('Server socket has closed.'); 
    });
});
document.getElementsByTagName('input')[0].onblur = function() {
    socket.send(this.value);
};
</script>

2）Nodejs socket后台：

var http = require('http');
var socket = require('socket.io');
// 启http服务
var server = http.createServer(function(req, res) {
    res.writeHead(200, {
        'Content-type': 'text/html'
    });
    res.end();
});
server.listen('8080');
console.log('Server is running at port 8080...');
// 监听socket连接
socket.listen(server).on('connection', function(client) {
    // 接收信息
    client.on('message', function(msg) {
        client.send('hello：' + msg);
        console.log('data from client: ---> ' + msg);
    });
    // 断开处理
    client.on('disconnect', function() {
        console.log('Client socket has closed.'); 
    });
});

35.正向代理和反向代理的区别

正向代理和反向代理是两种不同类型的代理服务器，它们在网络通信中扮演不同的角色。

正向代理（Forward Proxy）：
- 正向代理作为客户端的代理，代表客户端向其他服务器发送请求。客户端需要通过正向代理来访问其他服务器，因为直接访问会受到限制或阻止。
- 举个例子，当你在公司内部网络中访问互联网时，你可能需要通过公司的正向代理服务器来访问外部网站，因为公司的网络设置了防火墙或者其他安全限制。
反向代理（Reverse Proxy）：
- 反向代理作为服务器的代理，代表服务器接收客户端的请求并将请求转发到内部的服务器。客户端不知道自己实际正在与哪个服务器通信，因为所有的请求都是发送到反向代理服务器。
- 举个例子，当你访问一个网站时，你实际上在与反向代理服务器通信，它会将你的请求转发到后端的多个服务器上，然后将结果返回给你。

总的来说，正向代理是代表客户端发出请求，而反向代理是代表服务器接收请求。它们的主要区别在于代理的角色不同，以及它们在网络通信中的位置和功能不同。

36.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 只能处理一个。

37.事件是什么？事件模型？

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

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

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

38. 如何阻止事件冒泡

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

39.对事件委托的理解

（1）事件委托的概念

事件委托本质上是利用了浏览器事件冒泡的机制。因为事件在冒泡过程中会上传到父节点，父节点可以通过事件对象获取到目标节点，因此可以把子节点的监听函数定义在父节点上，由父节点的监听函数统一处理多个子元素的事件，这种方式称为事件委托（事件代理）。

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

（2）事件委托的特点

减少内存消耗

如果有一个列表，列表之中有大量的列表项，需要在点击列表项的时候响应一个事件：

<ul id="list">
  <li>item 1</li>
  <li>item 2</li>
  <li>item 3</li>
  ......
  <li>item n</li>
</ul>

如果给每个列表项一一都绑定一个函数，那对于内存消耗是非常大的，效率上需要消耗很多性能。因此，比较好的方法就是把这个点击事件绑定到他的父层，也就是 ul 上，然后在执行事件时再去匹配判断目标元素，所以事件委托可以减少大量的内存消耗，节约效率。

动态绑定事件

给上述的例子中每个列表项都绑定事件，在很多时候，需要通过 AJAX 或者用户操作动态的增加或者去除列表项元素，那么在每一次改变的时候都需要重新给新增的元素绑定事件，给即将删去的元素解绑事件；如果用了事件委托就没有这种麻烦了，因为事件是绑定在父层的，和目标元素的增减是没有关系的，执行到目标元素是在真正响应执行事件函数的过程中去匹配的，所以使用事件在动态绑定事件的情况下是可以减少很多重复工作的。

// 来实现把 #list 下的 li 元素的事件代理委托到它的父层元素也就是 #list 上：
// 给父层元素绑定事件
document.getElementById('list').addEventListener('click', function (e) {
  // 兼容性处理
  var event = e || window.event;
  var target = event.target || event.srcElement;
  // 判断是否匹配目标元素
  if (target.nodeName.toLocaleLowerCase === 'li') {
    console.log('the content is: ', target.innerHTML);
  }
});

在上述代码中， target 元素则是在 #list 元素之下具体被点击的元素，然后通过判断 target 的一些属性（比如：nodeName，id 等等）可以更精确地匹配到某一类 #list li 元素之上；

（3）局限性

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

当然事件委托不是只有优点，它也是有缺点的，事件委托会影响页面性能，主要影响因素有：

元素中，绑定事件委托的次数；
点击的最底层元素，到绑定事件元素之间的 DOM层数；

在必须使用事件委托的地方，可以进行如下的处理：

只在必须的地方，使用事件委托，比如：ajax的局部刷新区域
尽量的减少绑定的层级，不在 body元素上，进行绑定
减少绑定的次数，如果可以，那么把多个事件的绑定，合并到一次事件委托中去，由这个事件委托的回调，来进行分发。

40.事件委托的使用场景

场景：给页面的所有的a标签添加click事件，代码如下：

document.addEventListener("click", function(e) {
    if (e.target.nodeName == "A")
        console.log("a");
}, false);

但是这些a标签可能包含一些像span、img等元素，如果点击到了这些a标签中的元素，就不会触发click事件，因为事件绑定上在a标签元素上，而触发这些内部的元素时，e.target指向的是触发click事件的元素（span、img等其他元素）。

这种情况下就可以使用事件委托来处理，将事件绑定在a标签的内部元素上，当点击它的时候，就会逐级向上查找，知道找到a标签为止，代码如下：

document.addEventListener("click", function(e) {
    var node = e.target;
    while (node.parentNode.nodeName != "BODY") {
        if (node.nodeName == "A") {
            console.log("a");
            break;
        }
        node = node.parentNode;
    }
}, false);

41.对事件循环的理解

首先，浏览器的所有任务都是在一条线程上处理，即单线程

这样的坏处是，当执行一条任务时，这条任务执行的时间很长或者无响应，就会阻塞后面的任务，所以浏览器给出了一个方案，就是分为同步任务和异步任务，

异步任务是包括宏任务和微任务

其中常见的宏任务有全局的Script、settimeout、setInterval、IO操作、UI交互操作、以及nodejs中的setimmediate

常见的微任务有：Promise.then、async,await promise的语法糖、Process.nexTick、mutaionObserver

浏览器的EventLoop：

首先浏览器在执行代码的时候有两个概念，一个是执行栈，一个是任务队列

栈是先进后出，也就是函数的执行的时候，是后进去的先执行，pop（）

任务队列是先进先出，也就是当有宏任务或者微任务的时候，都会放进各自的任务队列里去等待执行，shift（）

总结：

在浏览器执行代码的过程中，首先执行全局的同步的代码，执行的过程中，如果发现有宏任务或者微任务，就会放进各自的任务队列去等待完成，随着同步的任务执行完成，先会去查看微任务队列是否存在任务，如果不存在就会开始将宏任务中的第一个任务取出，去执行；如果存在那就回优先执行微任务队列的任务；当执行宏任务的时候，如果宏任务中也包含微任务的话，那就会继续把微任务放进微任务队列，然后依次去执行微任务队列，直到所有的宏任务和微任务都执行完成，浏览器的一次事件循环就结束了

说一下node环境中的事件循环

首先node中也含有像浏览器中的一些异步操作，例如：IO操作：readFIleAsyc、process.nextTick、setImmdeiate

还有就是node中其实是利用libuv去执行js脚本，以及node，他们是怎么操作的呢？

首先v8引擎会去处理js脚本，node处理node的一些api，而libuv库就是负责调度这些任务到不同的线程中执行，形成一个eventloop，最后以异步的形式去返回结果给v8引擎

一共六个阶段

timer阶段：处理定时器等，回调是在poll阶段执行

io操作阶段：处理io事件，回调也是在poll阶段执行

idle，prepare阶段：处理系统事件，可以忽略

poll阶段:处理timer的回调和io的回调

check阶段：处理setlmmdeiate的回调

close阶段：处理close的回调

其中poll阶段比较复杂，分为几种情况：

如果没有设定timer时间（timer时间为下一次触发时间减去当前时间），

则poll队列是否为空，如果不为空的话，就会遍历去执行所有的回调，直到回调完成或者达到系统限制（这里的系统限制指的是系统的递归深度，默认为1000）；

如果为空的话，则会判断setlmmdeiate是否有回调需要执行，如果有则会进去check阶段去执行回调；如果没有回调要切执行，它就会等待回调被加入到队列中，这个等待时间是有限制的，不会无限的等待下去。

如果有设定timer时间且poll队列为空的话，则会判断是否有timer超时，如果有的就会回到timer阶段执行回调，如果队列不为空，则执行回调

42.宏任务和微任务分别有哪些

微任务包括： promise 的回调、node 中的 process.nextTick 、对 Dom 变化监听的 MutationObserver。
宏任务包括： script 脚本的执行、setTimeout ，setInterval ，setImmediate 一类的定时事件，还有如 I/O 操作、UI 渲染等。

43.什么是执行栈

可以把执行栈认为是一个存储函数调用的栈结构，遵循先进后出的原则。

当开始执行 JS 代码时，根据先进后出的原则，后执行的函数会先弹出栈，可以看到，foo 函数后执行，当执行完毕后就从栈中弹出了。

平时在开发中，可以在报错中找到执行栈的痕迹：

function foo() {
  throw new Error('error')
}
function bar() {
  foo()
}
bar()

可以看到报错在 foo 函数，foo 函数又是在 bar 函数中调用的。当使用递归时，因为栈可存放的函数是有限制的，一旦存放了过多的函数且没有得到释放的话，就会出现爆栈的问题

function bar() {
  bar()
}
bar()

44.Node 中的 Event Loop 和浏览器中的有什么区别？process.nextTick 执行顺序？

Node 中的 Event Loop 和浏览器中的是完全不相同的东西。

Node 的 Event Loop 分为 6 个阶段，它们会按照顺序反复运行。每当进入某一个阶段的时候，都会从对应的回调队列中取出函数去执行。当队列为空或者执行的回调函数数量到达系统设定的阈值，就会进入下一阶段。

（1）Timers（计时器阶段）：初次进入事件循环，会从计时器阶段开始。此阶段会判断是否存在过期的计时器回调（包含 setTimeout 和 setInterval），如果存在则会执行所有过期的计时器回调，执行完毕后，如果回调中触发了相应的微任务，会接着执行所有微任务，执行完微任务后再进入 Pending callbacks 阶段。

（2）Pending callbacks：执行推迟到下一个循环迭代的I / O回调（系统调用相关的回调）。

（3）Idle/Prepare：仅供内部使用。

（4）Poll（轮询阶段）：

当回调队列不为空时：会执行回调，若回调中触发了相应的微任务，这里的微任务执行时机和其他地方有所不同，不会等到所有回调执行完毕后才执行，而是针对每一个回调执行完毕后，就执行相应微任务。执行完所有的回调后，变为下面的情况。
当回调队列为空时（没有回调或所有回调执行完毕）：但如果存在有计时器（setTimeout、setInterval和setImmediate）没有执行，会结束轮询阶段，进入 Check 阶段。否则会阻塞并等待任何正在执行的I/O操作完成，并马上执行相应的回调，直到所有回调执行完毕。

（5）Check（查询阶段）：会检查是否存在 setImmediate 相关的回调，如果存在则执行所有回调，执行完毕后，如果回调中触发了相应的微任务，会接着执行所有微任务，执行完微任务后再进入 Close callbacks 阶段。

（6）Close callbacks：执行一些关闭回调，比如socket.on('close', ...)等。

下面来看一个例子，首先在有些情况下，定时器的执行顺序其实是随机的

setTimeout(() => {
    console.log('setTimeout')
}, 0)
setImmediate(() => {
    console.log('setImmediate')
})

对于以上代码来说，setTimeout 可能执行在前，也可能执行在后

首先 setTimeout(fn, 0) === setTimeout(fn, 1)，这是由源码决定的
进入事件循环也是需要成本的，如果在准备时候花费了大于 1ms 的时间，那么在 timer 阶段就会直接执行 setTimeout 回调
那么如果准备时间花费小于 1ms，那么就是 setImmediate 回调先执行了

当然在某些情况下，他们的执行顺序一定是固定的，比如以下代码：

const fs = require('fs')
fs.readFile(__filename, () => {
    setTimeout(() => {
        console.log('timeout');
    }, 0)
    setImmediate(() => {
        console.log('immediate')
    })
})

在上述代码中，setImmediate 永远先执行。因为两个代码写在 IO 回调中，IO 回调是在 poll 阶段执行，当回调执行完毕后队列为空，发现存在 setImmediate 回调，所以就直接跳转到 check 阶段去执行回调了。

上面都是 macrotask 的执行情况，对于 microtask 来说，它会在以上每个阶段完成前清空 microtask 队列，下图中的 Tick 就代表了 microtask

setTimeout(() => {
  console.log('timer21')
}, 0)
Promise.resolve().then(function() {
  console.log('promise1')
})

对于以上代码来说，其实和浏览器中的输出是一样的，microtask 永远执行在 macrotask 前面。

最后来看 Node 中的 process.nextTick，这个函数其实是独立于 Event Loop 之外的，它有一个自己的队列，当每个阶段完成后，如果存在 nextTick 队列，就会清空队列中的所有回调函数，并且优先于其他 microtask 执行。

setTimeout(() => {
 console.log('timer1')
 Promise.resolve().then(function() {
   console.log('promise1')
 })
}, 0)
process.nextTick(() => {
 console.log('nextTick')
 process.nextTick(() => {
   console.log('nextTick')
   process.nextTick(() => {
     console.log('nextTick')
     process.nextTick(() => {
       console.log('nextTick')
     })
   })
 })
})

对于以上代码，永远都是先把 nextTick 全部打印出来。

顺序

//macro-task:script(全部的代码) setInterval setTimeout setImmediate I/O
//micro-task:process.nextTick  Promise

45.事件触发的过程是怎样的

事件触发有三个阶段：

window 往事件触发处传播，遇到注册的捕获事件会触发
传播到事件触发处时触发注册的事件
从事件触发处往 window 传播，遇到注册的冒泡事件会触发

事件触发一般来说会按照上面的顺序进行，但是也有特例，如果给一个 body 中的子节点同时注册冒泡和捕获事件，事件触发会按照注册的顺序执行。

// 以下会先打印冒泡然后是捕获
node.addEventListener(
  'click',
  event => {
    console.log('冒泡')
  },
  false
)
node.addEventListener(
  'click',
  event => {
    console.log('捕获 ')
  },
  true
)

通常使用 addEventListener 注册事件，该函数的第三个参数可以是布尔值，也可以是对象。对于布尔值 useCapture 参数来说，该参数默认值为 false ，useCapture 决定了注册的事件是捕获事件还是冒泡事件。对于对象参数来说，可以使用以下几个属性：

capture：布尔值，和 useCapture 作用一样
once：布尔值，值为 true 表示该回调只会调用一次，调用后会移除监听
passive：布尔值，表示永远不会调用 preventDefault

一般来说，如果只希望事件只触发在目标上，这时候可以使用 stopPropagation 来阻止事件的进一步传播。通常认为 stopPropagation 是用来阻止事件冒泡的，其实该函数也可以阻止捕获事件。

stopImmediatePropagation 同样也能实现阻止事件，但是还能阻止该事件目标执行别的注册事件。

node.addEventListener(
  'click',
  event => {
    event.stopImmediatePropagation()
    console.log('冒泡')
  },
  false
)
// 点击 node 只会执行上面的函数，该函数不会执行
node.addEventListener(
  'click',
  event => {
    console.log('捕获 ')
  },
  true
)

46.V8的垃圾回收机制是怎样的

关键词：垃圾回收的过程、如何实现垃圾回收、新生代和老生代、全停顿

1、垃圾回收的过程：

通过GC ROOT 标记空间中的活动对象和非活动对象：目前V8采用的是可访问性算法来判断堆中的对象是否是活动对象。这个算法是将一些GC ROOT 作为初始存活的对象的集合，从GC Roots对象出发，遍历GC Root中所有的对象
通过GC Root遍历的对象是可访问的，会在内存中保留下来，也叫活动对象
通过GC Roots遍历的对象是不可访问的，也叫非活动对象，这些对象就可能会被回收
回收非活动对象所占据的内存：标记完对象之后，统一清理内存中所有被标记为可回收的对象
内存整理：意思就是再释放掉大量内存之后，内存会存在大量不连续空间，这些内存空间称为内存碎片。当内存中出现大量内存碎片后，如果再次需要分配较大的连续内存时，就有可能出现内存不足的情况，所以最后一步就是整理这些内存碎片。这一步是可选的，因为有的垃圾回收不会产生内存碎片

2、V8的两个垃圾回收器：主垃圾回收器和副垃圾回收器

新生代：存放时间较短的对象；

老生代：存放时间较长的对象

副垃圾回收器（新生代）：负责新生代的垃圾回收。大多数的对象最开始的时候就存放在新生代中，该存储空间较小，但分为两个空间：form空间（对象区）和to空间（休闲区）。
新加入的对象会被放在对象区，当对象区被放满时，就需要执行一次垃圾清理操作：首先将对对象区的垃圾做标记，标记完，执行清理操作。然后副垃圾回收器会把这些存活的对象放在休闲区，同时有序的排列。这个操作就相当于完成了内存整理，排列后的空闲区就不会有内存碎片了。
完成复制后，对象区和休闲区将会进行角色翻转，也就是将原来的对象区变成休闲区，原来的休闲区变成对象区，这种算法叫做Scavenge算法，这样就完成了垃圾对象的回收操作，同时这种翻转的操作可以让新生代的这两块区域无限重复使用下去
不过，副垃圾回收器每次执行清理操作的时候，都需要将存活的对象从对象区复制到空闲区，复制操作需要时间成本，如果新生区空间设置的太大，那么每次清理的时间就会过久，所以为了执行效率，一般新生区的空间都会被设置的很小。也正是因为新生区空间设置的小，所以很容易被活动的对象给装满，所以需要副垃圾回收器区中垃圾回收；并且副垃圾回收器针对经过了两次翻转还保留下来的对象，将会被晋升到老生代中
主垃圾回收器（老生代）：负责老生代的垃圾回收。除了新生代晋升的对象外，还有一些大的对象会直接被分配到老生代理；因此老生代有两个特点：
对象占用空间大
对象存活时间久
因为老生代的对象比较大，所以不使用Scavenge算法进行垃圾回收。因为复制这些大的对象需要很长时间，影响执行效率。所以老生代采用的算法是标记清除算法进行垃圾回收。这个算法分为两个阶段：标记和清除
标记阶段：从一组根元素开始，递归的遍历这组根元素，在遍历过程中，能到达的元素被称为活动对象，没有到达的元素被判断为垃圾数据
清除阶段：主垃圾回收器会直接将被标记为垃圾的数据清理掉
然后因为主垃圾回收器清理掉的数据会产生内存碎片，而较大的连续的内存碎片会导致大数据对象无法分配到连续内存中；所以有引入了另一个算法----标记整理算法
这个算法和标记清除算法一样，只是在标记完可回收对象后，将所有活动的对象向一端移动，然后直接清理掉这一端之外的内存
全停顿
概念：因为JavaScript是单线程语言，运行在主线程上。一旦执行垃圾回收算法，都需要将正在执行的JavaScript脚本暂停下来，待垃圾回收完成后再切执行JavaScript脚本，这种行为就叫做全停顿
新生代因为空间较小，所以执行垃圾回收的时候影响不大；但是老生代在执行垃圾回收的时候，会执行很长时间，会阻塞主线程的执行，导致页面的卡顿现象。
所以为了减少这种卡顿的现象，V8将标记过程分为了一个个子标记过程，同时让垃圾回收标记和JavaScript任务中间交替去执行，直到标记完成。这种算法叫做增量标记算法。
增量标记算法就会将一个完整的垃圾回收过程分为一个个很小的任务，穿插到JavaScript任务中区，这样就不会让用户觉得在执行垃圾回收的过程会有卡顿的现象了
虽然浏览器可以进行垃圾回收，但是当代码比较复杂的时候，垃圾回收付出的代价很大，所以尽量减少垃圾回收。
对数组进行优化：设置数组的length为0而不是等于【】
对object进行优化：对象尽可能的复用，对于不再使用的对象，设置为null
对函数进行优化：在循环的函数表达式立，如果可以复用，尽量写在函数外面

扩展：引用计数算法：

对于值被引用的话，这该值的引用次数为1，相反，如果包含对这个值引用的变量又取得了另外一个值，则这个值的引用次数就减1。当这个引用次数变为0时，说明这个变量已经没有价值，

这种方法会引起循环引用的问题：例如： obj1和 obj2通过属性进行相互引用，两个对象的引用次数都是2。当使用循环计数时，由于函数执行完后，两个对象都离开作用域，函数执行结束，obj1和 obj2还将会继续存在，因此它们的引用次数永远不会是0，就会引起循环引用。需要手动清理设置为null

47.哪些操作会造成内存泄漏？

第一种情况是由于使用未声明的变量，而意外的创建了一个全局变量，而使这个变量一直留在内存中无法被回收。
第二种情况是设置了 setInterval 定时器，而忘记取消它，如果循环函数有对外部变量的引用的话，那么这个变量会被一直留在内存中，而无法被回收。
第三种情况是获取一个 DOM 元素的引用，而后面这个元素被删除，由于我们一直保留了对这个元素的引用，所以它也无法被回收。
第四种情况是不合理的使用闭包，从而导致某些变量一直被留在内存当中。

48.渲染合成层是什么？

基础

浏览器渲染时会将 dom、cssom 合并成 renderObject 树，之后按特定规则将 renderObject 树拆分为多个 render layer —— 渲染层，实现分层渲染(每一层都是 renderObject 树的一部分)
特殊：translatez、opacity、canvas、video 等
分层渲染能大大优化渲染性能：
不会因为局部小量更新导致全局重绘；
部分特性可以只在渲染层执行重绘，例如 transform、opacity，不需要重排、重绘
分层后，每一个 Render Layer 会生成一个独立渲染位图，浏览器需要按正确的顺序将其合并成一张图，绘制到屏幕上

浏览器渲染流程

渲染过程大致可分为：Network => Parse => Render(style, layout, paint, 有时候还有合成 compositing) 阶段：

Parse
html => dom tree
css => Style Rules(CSSOM)
Render
style：计算节点样式属性，生成 render Tree
DOM + CSSOM => RenderObject => Render Tree
Render Tree 中只包含需要渲染 or 布局的元素，如 display: none 或 script、head 等标签不会出现；但 visibility: hidden 会出现
Layout：根据屏幕 viewport 与 render Object 的盒子属性，计算每一个 Render Object 节点的位置、宽高
注意：如果遇到无法计算宽高的节点(如图片)，会补充一个占位区域
Paint：根据 layout 计算出的逻辑布局以及 render tree 的样式信息，计算各个节点的位图效果；这里为了提升渲染效率，会选择将渲染任务拆解成多个，形成 render Layer分层节点
每一个触发分层的节点，以及该节点的子孙节点都划分为一个 render Layer；render Layer本身也会形成一颗树壮结构；

触发分层(简单理解)：
document
video、canvas 标签
will-change、translateZ、opacity
index 比 renderlayer 层大的元素，会触发隐式合成层
chrome96 后对分层规则做了很多复杂的优化，不过大致上还是遵守上述逻辑
为什么要切割：
有利于改善频繁变更元素的渲染效果：video、canvas
单层频繁变更不会影响其它层，能够减少全局重新布局、重绘的次数
开启硬件加速后，可以以 render layer 为单位将部分计算任务发送到 GPU，实现硬件加速
部分样式效果可以直接在 render layer 实现，不会触发重排、重绘，如：transform、opacity
副作用：巨大的内存消耗，特别在过去有一种隐式合成层带来的所谓的“层爆炸”问题
Composition：调用合成器线程(compositor)，将 render layer 按正确顺序合并成最终渲染效果
render layer 传递到 compositor 后，某些特殊的渲染层会被创建为合成层（Compositing Layers），这部分 layer 会被传递到 GPU 处理；只有下述情况下会创建独立 compositing layer
compositing layer 包含 3D 或 perspective transform CSS 属性；
包含启动了加速解码功能的 video
包含 3d 或 2d 加速 context 的canvas
包含 transform 或 opacity 动画
包含 css 滤镜
父级 compositing layer
接下来需要将多个 Compositing layer 合并成 GraphicsLayer
由于 GraphicsLayer 占用一套完整的上下文接口和数据，占用内存较大，所以浏览器会尽量控制 GraphicsLayer 的数量
GraphicsLayer 之间也形成了树壮结构
GraphicsLayer 负责将合成层的位图合并在一起，并最终显示到界面上
○总结一下，有4种树状结构：
DOM
RenderObject tree：与 dom 树的可视元素一一对应；树节点 render object 包含内容与样式规则，以及渲染指令
RenderLayer tree：由 RenderLayer 组成的树；RenderObject 树在遇到特定规则时会将某节点提升为单独的 RenderLayer 对象，所以 renderLayer 对应到 RenderObject 子树；在合成阶段，RenderLayer 传递到 compositor 后会被表达为 Compositing Layer
GraphicsLayer tree：mapping GraphicsLayers one-to-many RenderLayers.

性能优化

49.iframe如何理解？有什么特点？一般应用在什么场景？？

核心点：

理解 iframe 是什么？理解什么是可替换元素
理解 iframe 常见使用场景及一些特殊使用场景
了解常见的微前端方案，理解 iframe 在现代微前端中扮演的角色

iframe 是什么？

iframe它提供了一种将整个 web 页嵌入到另一个网页的方法，看起来就像那个 web 页是另一个网页的一个 img 或其他元素一样。

iframe 属于可替换元素，与之类似的还有 Canvas、IMG、Video 元素。

一个内容不受 CSS 渲染控制，CSS 渲染模型并不考虑对此内容的渲染，且元素本身一般拥有固有尺寸例如宽度、高度、宽高比等的元素，被称之为替换元素。对于可替换元素，浏览器会根据元素的标签和属性，来决定元素的具体显示内容。
可替换元素的内容不受当前文档的样式的影响，CSS 可以影响可替换元素的位置，但不会影响到可替换元素自身的内容。对于某些可替换元素，例如<iframe>元素，可能具有自己的样式表，但它们不会继承父文档的样式。

iframe元素旨在允许你将其他 Web 文档嵌入到当前文档中。这很适合将第三方内容嵌入你的网站，你可能无法直接控制，也不希望实现自己的版本——例如来自在线视频提供商的视频，Disqus 等评论系统，在线地图提供商，广告横幅等。

iframe 的安全隐患

iframe 元素在网页开发中可以用来嵌入其他网页或者外部资源。然而，由于 iframe 的特性，它可能存在一些安全隐患，包括以下几个方面：

跨域脚本攻击（Cross-Site Scripting, XSS）：如果在嵌入的网页中存在恶意脚本，这些脚本可以窃取用户数据、操纵页面内容或进行其他恶意操作。
点击劫持（Clickjacking）：攻击者可以利用 iframe 来创建一个看不见的透明层，覆盖在诱使用户点击的可见元素上，以达到欺骗和劫持用户点击的目的。
CSRF 攻击（Cross-Site Request Forgery）：在某些情况下，iframe 可以被用来诱使用户执行未经用户授权的操作，例如在用户登录了一个网站后，该网站又通过 iframe 嵌套了其他网站，并在该 iframe 页面中自动触发一些操作。

为了减轻 iframe 带来的安全风险，有几个常见的安全措施可以采取：

使用 sandbox 属性：该属性可以限制 iframe 内容的权限，防止恶意脚本的执行。可以根据具体需求设置不同的值，如 sandbox="allow-scripts" 只允许脚本执行，而禁止其他权限。
设置 X-Frame-Options HTTP 头：该头部可以阻止页面被嵌入到 iframe 中，提供一定的点击劫持保护。可以设置为 X-Frame-Options: DENY 来完全阻止页面被嵌入到 iframe 中。
使用 Content Security Policy（CSP）：CSP 可以限制页面中允许加载的资源，包括嵌入的 iframe。通过配置 CSP，可以阻止恶意加载和执行外部资源。
验证和过滤嵌入内容：在使用 iframe 嵌入第三方网页时，应该谨慎验证和过滤嵌入内容，确保只嵌入可信任的来源，并避免嵌入恶意或不受信任的内容。

iframe 的应用场景

iframe 的常见使用场景包括：

嵌入其他网页：最常见的使用方式是嵌入一个外部网页，让用户能够在当前页面中直接查看其他网站的内容。这可以在博客、新闻网站或电子商务网站中应用。
集成第三方服务和组件：通过将第三方服务或组件嵌入到 iframe 中，可以实现功能的扩展和增强。例如，嵌入地图服务、支付系统或社交媒体的分享按钮等。
广告展示：某些广告网络使用 iframe 来提供广告内容，以实现更好的隔离和可控性。这样可以确保广告不会影响到主页面的布局和性能。
加载网页片段：有时候我们只需要加载并展示网页中的某个特定部分，而不是整个页面。通过使用 iframe 可以选择性地加载和渲染指定的网页片段。

iframe 的一些有意思的特殊用法：

单页应用（Single-Page Application, SPA）：在某些 SPA 实现中，可以使用 iframe 来加载并展示不同的页面，以实现对页面的动态加载和切换。
安全隔离：在一些安全敏感的环境中，可以使用 iframe 来实现对来自外部源的内容进行隔离和限制。通过将外部内容嵌入到iframe中，可以确保它们无法直接访问主页面的 DOM 或执行恶意操作。
文档预览：一些在线文档编辑器或云存储服务使用 iframe 来实现文档的预览功能。用户可以通过 iframe 在当前页面中查看文档的内容，而无需离开编辑器或云存储界面。
使用 iframe 进行跨域：使用 iframe 进行跨域请求的方式主要有两种：
1. 通过设置 document.domain
2. 使用 HTML5 的跨域消息传递机制。

iframe 在现代微前端中扮演的角色

首先，什么是微前端？微前端：微前端是一种软件架构模式，旨在将大型前端应用程序拆分成更小、更可管理的部分。它的核心思想是将前端应用程序划分为多个独立的功能模块，每个模块负责自己的开发、部署和生命周期管理，同时可以独立地进行更新和扩展。传统的单体前端应用程序往往随着规模的增长变得复杂和难以维护。微前端通过将应用程序划分为独立的功能模块，使团队能够更好地分工合作、提高开发效率，并且能够更加灵活地进行部署和升级。现在，业界比较常见的微前端方案有：

Single-SPA：Single-SPA 是一个流行的开源微前端框架，支持多个技术栈和框架之间的集成。它采用路由来协调各个子应用之间的跳转和通信，可以方便地进行懒加载和模块化管理。
qiankun：qiankun 是一个基于 Single-SPA 的微前端框架，也是一个开源项目。它支持 Vue、React 和 Angular 等框架，并提供了更加简单、易用、灵活的 API 和插件机制。
Module Federation：基于 webpack 的 MF 微前端架构是一种通过 webpack 模块化管理和打包应用程序的微前端方案。核心思想是使用 webpack 的模块化功能来隔离和打包应用程序的不同部分，同时利用 webpack 的插件和 loader 来支持动态加载和代码分割。这样可以实现懒加载和增量更新，提高应用程序的性能和可维护性。

50.为什么浏览器要限制并发连接数？

What

浏览器的请求并发限制是指浏览器在向服务器发送请求时，限制同时进行的请求数量的机制。这个限制是为了控制资源的使用和网络性能的平衡。具体来说，浏览器的请求并发限制可以包括以下方面：

域名级别的并发连接数限制：浏览器通常对同一域名下的并发连接数进行限制，即针对同一域名的资源请求只能同时进行一定数量的连接。
单个页面的并发连接数限制：浏览器可能对单个页面中的并发连接数量进行限制，即同一个页面内的资源请求只能同时进行一定数量的连接。
连接类型的并发连接数限制：浏览器可能对不同类型的连接（如普通请求、长轮询、WebSocket等）分别设置并发连接数限制。
浏览器的网络策略：浏览器还可能根据网络状态和负载情况动态调整并发连接数限制，以维护网络性能和资源合理使用。
拿 Chrome 浏览器来说，同域名下资源加载的最大并发连接数为 6，当资源文件大于 6 时，多于 6 个的文件就会进入待定，等第一批加载完才会加载第二批的6个图片资源，这样就增加了等待时间。无形中就增加用户加载网页等待的时间。

Why

浏览器限制并发连接数是为了有利于网络资源的利用和用户体验。下面是一些原因：

提高性能：浏览器在同一时间内发送多个并发请求有助于提高页面加载速度。但是，如果同时发送过多的请求，会对网络传输和服务器产生过大的负载，可能导致延迟和拥塞。通过限制并发连接数，可以避免过多的请求同时发送，从而提高整体性能和响应速度。
控制带宽消耗：每个并发连接都需要占用一定的带宽资源。如果浏览器不进行限制，用户访问网页时可能出现大量并发连接，造成网络带宽耗尽。通过限制并发连接数，可以合理分配带宽资源，避免过度消耗，确保用户和其他应用程序的正常网络使用。
http1.x 天然有队首阻塞的缺陷，当页面资源内容较多，需要发起大量 http 请求时，同一时间内只能有 x 个请求在连接中，其它都得排队，导致页面整体性能较差
计算机资源有限，且线程切换成本很高，不可能无限制创建 tcp 连接
1. 占用资源：端口(65536)、内核内存、文件描述符、内核文件打开数、tcp连接四元组、数据接收/发送缓冲区、线程(不同语言不同实现，node 下 libuv 也会为每一个 tcp 创建独立线程)
2. 对服务端、客户端都是资源消耗
1.0 之后，keep-alive 使得大多数情况下复用已有连接比创建(三次握手耗时)一个新链接的性能高很多
许多服务器为了防御 ddos 攻击，其实也会限制同一ip过来的连接数，超过会主动关闭
一种平衡策略，防止多个客户端竞争有限资源，导致马太效应
需要注意的是，浏览器对并发连接数的限制是根据不同浏览器和版本而定的，并且可以通过调整浏览器设置或使用特定的技术手段进行修改。同时，服务器也可以通过调整配置来处理更多的并发连接。

不同浏览器的请求并发限制

不同的浏览器在限制请求并发方面可能会有一些差异。以下是一些常见的浏览器及其默认的请求并发限制：

Google Chrome：对于HTTP/1.1协议，Chrome 通常允许每个域名最多同时进行 6 个并发连接。
Mozilla Firefox：Firefox通常允许每个域名最多同时进行 6 到 8 个并发连接。
Safari：Safari 通常允许每个域名最多同时进行 6 个并发连接。
Microsoft Edge：Edge 通常允许每个域名最多同时进行 6 个并发连接。
需要注意的是，上述数字仅表示默认值，并且可能会受到浏览器版本、网络配置和服务器设置的影响。此外，一些浏览器也提供了高级设置或插件来修改默认的请求并发限制。

如何突破浏览器的请求并发限制？

理论而言，突破浏览器的请求并发限制违反了浏览器设计和网络协议的原则，可能会影响用户体验和网站性能，并可能导致一些安全风险和不合法行为。但是，我们还是有一些方法，能够巧妙的突破浏览器并发限制：

可以添加浏览器启动参数，手动添加并发连接数
可以使用http1.1 的管道功能，部分解决问题
使用多个域名，常见做法是将 静态资源 放在其它域名，例如 cdn：使用CDN（内容分发网络）：CDN可以通过将资源分布到多个服务器上，从而缓解单个服务器的压力，提高资源加载速度和可靠性。
合并多种资源，将多个小的资源请求合并成一个大的请求，可以减少请求次数，从而提高性能和响应速度。
可以升级到 http2 (PS: 大概率会紧接着问 http2 的多路复用是怎么实现的，可以回头去看看过去的录播)
延迟加载：将页面中不必要的资源（如图片或视频）延迟加载，可以提高页面打开速度和性能。

51.理解浏览器的多线程架构及渲染流程

浏览器中主要的 5 大进程

浏览器进程：负责界面显示、用户交互、子进程管理、提供储存等。
渲染进程：每个 tab 都有单独的渲染进程，核心用于渲染页面。
网络进程：主要处理网络资源加载（html、css、js等）。
GPU进程：3D 绘制，提高性能。
插件进程：Chrome 中安装的一些插件。

浏览器多进程的优势

相比于单进程浏览器，多进程有如下优点：

避免单个page crash影响整个浏览器
避免第三方插件crash影响整个浏览器
多进程充分利用多核优势
方便使用沙盒模型隔离插件等进程，提高浏览器稳定性

简单点理解：如果浏览器是单进程，那么某个Tab页崩溃了，就影响了整个浏览器，体验有多差；同理如果是单进程，插件崩溃了也会影响整个浏览器；而且多进程还有其它的诸多优势。。。

当然，内存等资源消耗也会更大，有点空间换时间的意思。

梳理浏览器内核中线程之间的关系

到了这里，已经对浏览器的运行有了一个整体的概念，接下来，先简单梳理一些概念

GUI渲染线程与JS引擎线程互斥

由于JavaScript是可操纵DOM的，如果在修改这些元素属性同时渲染界面（即JS线程和UI线程同时运行），那么渲染线程前后获得的元素数据就可能不一致了。因此为了防止渲染出现不可预期的结果，浏览器设置GUI渲染线程与JS引擎为互斥的关系，当JS引擎执行时GUI线程会被挂起， GUI更新则会被保存在一个队列中等到JS引擎线程空闲时立即被执行。

JS阻塞页面加载

从上述的互斥关系，可以推导出，JS如果执行时间过长就会阻塞页面。譬如，假设JS引擎正在进行巨量的计算，此时就算GUI有更新，也会被保存到队列中，等待JS引擎空闲后执行。然后，由于巨量计算，所以JS引擎很可能很久很久后才能空闲，自然会感觉到巨卡无比。所以，要尽量避免JS执行时间过长，这样就会造成页面的渲染不连贯，导致页面渲染加载阻塞的感觉。

WebWorker，JS的多线程？

前文中有提到JS引擎是单线程的，而且JS执行时间过长会阻塞页面，那么JS就真的对cpu密集型计算无能为力么？所以，后来HTML5中支持了Web Worker。

这样理解下：

创建Worker时，JS引擎向浏览器申请开一个子线程（子线程是浏览器开的，完全受主线程控制，而且不能操作DOM）
JS引擎线程与worker线程间通过特定的方式通信（postMessage API，需要通过序列化对象来与线程交互特定的数据）

所以，如果有非常耗时的工作，请单独开一个Worker线程，这样里面不管如何翻天覆地都不会影响JS引擎主线程，只待计算出结果后，将结果通信给主线程即可，perfect!

而且注意下，JS引擎是单线程的，这一点的本质仍然未改变，Worker可以理解是浏览器给JS引擎开的外挂，专门用来解决那些大量计算问题。

WebWorker与SharedWorker

既然都到了这里，就再提一下SharedWorker（避免后续将这两个概念搞混）

WebWorker只属于某个页面，不会和其他页面的Render进程（浏览器内核进程）共享
所以Chrome在Render进程中（每一个Tab页就是一个render进程）创建一个新的线程来运行Worker中的JavaScript程序。
SharedWorker是浏览器所有页面共享的，不能采用与Worker同样的方式实现，因为它不隶属于某个Render进程，可以为多个Render进程共享使用
所以Chrome浏览器为SharedWorker单独创建一个线程来运行JavaScript程序，在浏览器中每个相同的JavaScript只存在一个SharedWorker线程，不管它被创建多少次。

看到这里，应该就很容易明白了，本质上就是进程和线程的区别。SharedWorker由独立的进程管理，WebWorker只是属于render进程下的一个线程

渲染进程详解

重点来了，我们可以看到，上面提到了这么多的进程，那么，对于普通的前端操作来说，最终要的是什么呢？答案是渲染进程。可以这样理解，页面的渲染，JS的执行，事件的循环，都在这个进程内进行。请牢记，浏览器的渲染进程是多线程的。那么接下来看看它都包含了哪些线程（列举一些主要常驻线程）：

1 GUI渲染线程

负责渲染浏览器界面，解析HTML，CSS，构建DOM树和RenderObject树，布局和绘制等。
当界面需要重绘（Repaint）或由于某种操作引发回流(reflow)时，该线程就会执行
注意，GUI渲染线程与JS引擎线程是互斥的，当JS引擎执行时GUI线程会被挂起（相当于被冻结了），GUI更新会被保存在一个队列中等到JS引擎空闲时立即被执行。

2 JS引擎线程

也称为JS内核，负责处理Javascript脚本程序。（例如V8引擎）
JS引擎线程负责解析Javascript脚本，运行代码。
JS引擎一直等待着任务队列中任务的到来，然后加以处理，一个Tab页（renderer进程）中无论什么时候都只有一个JS线程在运行JS程序
同样注意，GUI渲染线程与JS引擎线程是互斥的，所以如果JS执行的时间过长，这样就会造成页面的渲染不连贯，导致页面渲染加载阻塞。

3 事件触发线程

归属于浏览器而不是JS引擎，用来控制事件循环（可以理解，JS引擎自己都忙不过来，需要浏览器另开线程协助）
当JS引擎执行代码块如setTimeOut时（也可来自浏览器内核的其他线程,如鼠标点击、AJAX异步请求等），会将对应任务添加到事件线程中
当对应的事件符合触发条件被触发时，该线程会把事件添加到待处理队列的队尾，等待JS引擎的处理
注意，由于JS的单线程关系，所以这些待处理队列中的事件都得排队等待JS引擎处理（当JS引擎空闲时才会去执行）

4 定时触发器线程

传说中的setInterval与setTimeout所在线程
浏览器定时计数器并不是由JavaScript引擎计数的,（因为JavaScript引擎是单线程的, 如果处于阻塞线程状态就会影响记计时的准确）
因此通过单独线程来计时并触发定时（计时完毕后，添加到事件队列中，等待JS引擎空闲后执行）
注意，W3C在HTML标准中规定，规定要求setTimeout中低于4ms的时间间隔算为4ms。

5 异步http请求线程

在XMLHttpRequest在连接后是通过浏览器新开一个线程请求
将检测到状态变更时，如果设置有回调函数，异步线程就产生状态变更事件，将这个回调再放入事件队列中。再由JavaScript引擎执行。

首次渲染

对于中间的浏览器，它就是一个黑盒，下面就来看看这个黑盒是如何将静态资源转化为前端界面的。由于渲染机制比较复杂，所以渲染模块在执行过程中会被划分为很多子阶段，输入的静态资源经过这些子阶段，最后输出页面。

大致的渲染流程如下：

1、浏览器无法直接使用HTML，需要将HTML转化成DOM树（document）
2、浏览器无法解析纯文本的css样式，需要对css进行解析，解析成styleSheets（document.styleSheets）
3、计算出DOM树中每个节点的具体样式（Attachment）
4、创建渲染（布局）树，将DOM树中可见节点添加到布局树中。并计算节点渲染到页面的坐标位置（layout）
5、通过布局树进行分层（根据定位属性，透明属性，transform属性，clip属性等）生成图层树
6、将不同图层进行绘制，转交给合成线程处理。最终生成页面，并显示到浏览器上（painting,Display）
对于这五个流程，每一阶段都有对应的产物，分别是：DOM树、CSSOM树、渲染树、盒模型、界面。

关键渲染路径

理解关键渲染路径 -- 关键渲染路径。关键渲染路径是浏览器将 HTML，CSS 和 JavaScript 转换为屏幕上的像素所经历的步骤序列。优化关键渲染路径可提高渲染性能。关键渲染路径包含了文档对象模型(DOM)，CSS 对象模型 (CSSOM)，渲染树和布局。在解析 HTML 时会创建文档对象模型。HTML 可以请求 JavaScript，而 JavaScript 反过来，又可以更改 DOM。HTML 包含或请求样式，依次来构建 CSS 对象模型。浏览器引擎将两者结合起来以创建渲染树。布局确定页面上所有内容的大小和位置。确定布局后，将像素绘制到屏幕上。优化关键渲染路径可以缩短首次渲染的时间。了解和优化关键渲染路径对于确保重排和重绘可以每秒 60 帧的速度进行，以确保高效的用户交互并避免卡顿是很重要的。

JavaScript：一般来说，我们会使用 JavaScript 来实现一些视觉变化的效果。比如做一个动画或者往页面里添加一些 DOM 元素等。
Style：计算样式，这个过程是根据 CSS 选择器，对每个 DOM 元素匹配对应的 CSS 样式。这一步结束之后，就确定了每个 DOM 元素上该应用什么 CSS 样式规则。
Layout：布局，上一步确定了每个 DOM 元素的样式规则，这一步就是具体计算每个 DOM 元素最终在屏幕上显示的大小和位置。web 页面中元素的布局是相对的，因此一个元素的布局发生变化，会联动地引发其他元素的布局发生变化。比如，元素的宽度的变化会影响其子元素的宽度，其子元素宽度的变化也会继续对其孙子元素产生影响。因此对于浏览器来说，布局过程是经常发生的。
Paint：绘制，本质上就是填充像素的过程。包括绘制文字、颜色、图像、边框和阴影等，也就是一个 DOM 元素所有的可视效果。一般来说，这个绘制过程是在多个层上完成的。
Composite：渲染层合并，由上一步可知，对页面中 DOM 元素的绘制是在多个层上进行的。在每个层上完成绘制过程之后，浏览器会将所有层按照合理的顺序合并成一个图层，然后显示在屏幕上。对于有位置重叠的元素的页面，这个过程尤其重要，因为一旦图层的合并顺序出错，将会导致元素显示异常。

在页面性能优化的技巧中，大家一定听过，尽可能的减少页面的重绘和重排。上面的 Layout，也就是对应浏览器渲染过程中的重排的过程，而 Paint，对应的就是重绘的过程，而 Composite 就是最后的渲染层合并。

什么意思呢？在某一帧中，如果只有元素的 Paint，那么只需要经历 Paint --> Composite 的过程。而如果有元素的 Layout，则页面需要经历 Layout --> Paint --> Composite 的过程。而如果我们能寻找到只有 Composite 变换的渲染，则页面无需经历 Paint 和 Layout，此时页面是渲染性能就是最好的！因此，我们想要高性能的 CSS 动画，也是需要尽可能的减少页面的重排与重绘！

Layout

生成每个元素的几何形状和位置
非常消耗性能，因为渲染引擎必须重新考虑相关元素及其所有子元素后，才能计算新的布局
当操作 DOM 树、影响布局的样式、更改浏览器窗口大小、ClassName 属性更改时会发生 Layout

Paint

将每个元素的像素绘制到不同的层中
渲染引擎遍历所有元素以确定可见的内容和应显示的内容（十分消耗性能）
绘制文字、添加轮廓（outline）、阴影（shadow）或更改背景颜色（background）

Composite

只有不透明度（opacity）以及变换（transform）只触发 Composite
Blink 和 Webkit 内核为 CSS transform 和 opacity 创建了新的层（Graphics Layers）
translatez(0) 用于强制创建层（Graphics Layers），该层在动画启动后会立即进行绘制
通过 The Web's Black Magic，了解 rendering 和 compositing 的最佳解释

52.如何理解 preload 指令

是什么：

用于预加载资源的 html 指令，相当于告诉浏览器：我在当前页面马上要用到这个资源，需要你尽快帮我加载回来为什么：

网页中有非常多外联资源，js、css、图片等等，使用前总需要先等待资源的下载，如果我们能做到预先加载资源，那在资源执行的时候就不必等待网络的开销

怎么用：

<link rel="preload" 
  href="https://example.com/fonts/font.woff" 
  as="font" 
  crossorigin 
  onload="handleOnload()" 
  onerror="handlepreloadError()"/>

作用：

借助 preload，开发者可以明确声明需要预加载的资源列表
资源被 preload 后，会被首先放入浏览器缓存

问题： preload 的资源不一定都被用到，可能造成无效的预加载，在移动端下需要特别注意

53.如何理解 requestAnimationFrame 接口？如何优化渲染性能

是什么：这是一个监听“帧”的接口，在浏览器进入下一帧时触发回调为什么：

在 raf 之前，我们只能通过 setTimeout/setInterval 等接口调度动画逻辑，但这两个接口与浏览器渲染“帧”的时机并不相关，会在错误的“时机”触发回调，可能反而让浏览器渲染管线变得紊乱
思考一个问题，浏览器的帧率是不固定的 —— 取决于帧内工作量，那么借助定时器做的定时回调并不能确保跟“帧”率匹配，可能会在一帧内触发多次，那么最终可能会造成渲染紊乱，影响帧任务的执行性能
使用 raf 后，我们能确保一定在帧开始之前触发回调，也就能跟渲染管线对齐，避免不必要的计算

应用场景：

各种类型的动画，比如：元素、canvas、webgl
防抖节流
fps 计算

raf 在每一帧样式计算之前触发；setTimeout 没办法把握准确时机 raf 在一帧中只会触发一次；setTimeout 多次，导致 js 线程负载更高

如何优化帧渲染性能？(目标：60fps)

避免长时间执行 js 脚本，可以使用 web worker 执行或者分片计算方式做负载均衡，避免影响渲染流水线
优化事件回调(scroll )、异步任务性能
减少重排次数、范围(避免交错读写样式、使用 transform 等)
使用 raf 绘制动画(更好的方式，应该是 css)

54.如何理解 GPU 渲染加速？什么是合成层 CompositeLayers

简单来说，浏览器为了提升动画的性能，为了在动画的每一帧的过程中不必每次都重新绘制整个页面。在特定方式下可以触发生成一个合成层（Composite Layers），合成层拥有单独的 GraphicsLayer。

需要进行动画的元素包含在这个合成层之下，这样动画的每一帧只需要去重新绘制这个 GraphicsLayer 即可，从而达到提升动画性能的目的。

如果我们想尽可能的优化我们的 CSS 动画，或者在日常 CSS 开发中，尽可能的提升 CSS 的性能，这是一个非常重要的概念。通过生成独立的 GraphicsLayer，让此层内的重绘重排不引起整个页面的重绘重排。

这也就是我们常说的，CSS 3D 硬件加速的最本质的原因。

那么一个元素什么时候会触发创建一个 Graphics Layer 层？

从目前来说，满足以下任意情况便会创建层：

硬件加速的 iframe 元素（比如 iframe 嵌入的页面中有合成层）
硬件加速的插件，比如 flash 等等
使用加速视频解码的
3D 或者硬件加速的 2D Canvas 元素
3D 或透视变换(perspective、transform) 的 CSS 属性
对自己的 opacity 做 CSS 动画或使用一个动画变换的元素
拥有加速 CSS 过滤器的元素
元素有一个包含复合层的后代节点(换句话说，就是一个元素拥有一个子元素，该子元素在自己的层里)
元素有一个 z-index 较低且包含一个复合层的兄弟元素

因此，通常最为常见的创建一个复合层的方式就是：
transform
opacity
filter（使用频率较低）

我们可以通过合理的使用这几个元素，有效提升页面的性能，譬如使用 transform 代替 left、top，实现位移动画。

什么是 GPU 渲染加速？

GPU 渲染加速除了与上面的内容紧密相连外，还需要了解另外一个非常有意思的属性 -- will-change。根据 MDN，属性 will-change 为 web 开发者提供了一种告知浏览器该元素会有哪些变化的方法，这样浏览器可以在元素属性真正发生变化之前提前做好对应的优化准备工作。这种优化可以将一部分复杂的计算工作提前准备好，使页面的反应更为快速灵敏。譬如：

.sidebar {
  will-change: transform;
}

这会使声明了该样式属性的元素生成一个图形层，告诉浏览器接下来该元素将会进行 transform 变换，让浏览器提前做好准备。

是的，这个属性是 CSS 中，除了 transform: translateZ(0) 外，另外一种强制开启硬件加速的方式。通常，我们有两种，强制可以让元素开启硬件加速的方式。 1.transform: translateZ(0) 2.will-change: transform; 如何更好的理解硬件加速？我尝试讲讲我的理解。当我们使用 transform 和 opacity 对元素进行动画时，浏览会尝试优化这段动画。浏览器将所有内容作为纹理（texture）传输到 GPU，而不是对每一帧上的像素进行光栅化。GPU 非常擅长执行此类基于纹理的转换，因此，我们得到了非常流畅、高性能的动画，这称为“硬件加速”。而有趣的是，GPU 和 CPU 的对页面的渲染效果略有不同。当 CPU 将渲染任务交给 GPU 时，我们有时会看到页面动画会有一些轻微的变化。（譬如动画的抖动）而此时，will-change 就非常适合成为 GPU 和 CPU 之间的桥梁。通过 will-change 属性，提前告知浏览器，让浏览器提前做好准备。当然，通过将元素的渲染委托给 GPU，它将消耗更多的内存资源，而这种资源是有限的，尤其是在低端移动设备上。因此，想使用好 will-change 属性并不是很容易：

是的，这个属性是 CSS 中，除了 transform: translateZ(0) 外，另外一种强制开启硬件加速的方式。

通常，我们有两种，强制可以让元素开启硬件加速的方式。

1transform: translateZ(0)

2will-change: transform;

如何更好的理解硬件加速？我尝试讲讲我的理解。

当我们使用 transform 和 opacity 对元素进行动画时，浏览会尝试优化这段动画。浏览器将所有内容作为纹理（texture）传输到 GPU，而不是对每一帧上的像素进行光栅化。GPU 非常擅长执行此类基于纹理的转换，因此，我们得到了非常流畅、高性能的动画，这称为“硬件加速”。

而有趣的是，GPU 和 CPU 的对页面的渲染效果略有不同。当 CPU 将渲染任务交给 GPU 时，我们有时会看到页面动画会有一些轻微的变化。（譬如动画的抖动）

而此时，will-change 就非常适合成为 GPU 和 CPU 之间的桥梁。通过 will-change 属性，提前告知浏览器，让浏览器提前做好准备。

当然，通过将元素的渲染委托给 GPU，它将消耗更多的内存资源，而这种资源是有限的，尤其是在低端移动设备上。

因此，想使用好 will-change 属性并不是很容易：

在一些低端设备上，will-change 会导致很多小问题，譬如会使图片模糊，有的时候很容易适得其反，所以使用的时候还需要多加测试。
不要将 will-change 应用到太多元素上：浏览器已经尽力尝试去优化一切可以优化的东西了。有一些更强力的优化，如果与 will-change 结合在一起的话，有可能会消耗很多机器资源，如果过度使用的话，可能导致页面响应缓慢或者消耗非常多的资源。
有节制地使用：通常，当元素恢复到初始状态时，浏览器会丢弃掉之前做的优化工作。但是如果直接在样式表中显式声明了 will-change 属性，则表示目标元素可能会经常变化，浏览器会将优化工作保存得比之前更久。所以最佳实践是当元素变化之前和之后通过脚本来切换 will-change 的值。
不要过早应用 will-change 优化：如果你的页面在性能方面没什么问题，则不要添加 will-change 属性来榨取一丁点的速度。 will-change 的设计初衷是作为最后的优化手段，用来尝试解决现有的性能问题。它不应该被用来预防性能问题。过度使用 will-change 会导致生成大量图层，进而导致大量的内存占用，并会导致更复杂的渲染过程，因为浏览器会试图准备可能存在的变化过程，这会导致更严重的性能问题。
给它足够的工作时间：这个属性是用来让页面开发者告知浏览器哪些属性可能会变化的。然后浏览器可以选择在变化发生前提前去做一些优化工作。所以给浏览器一点时间去真正做这些优化工作是非常重要的。使用时需要尝试去找到一些方法提前一定时间获知元素可能发生的变化，然后为它加上 will-change 属性。

55.什么是内容安全策略（CSP）

什么是 CSP？

内容安全策略（CSP）是一个额外的安全层，用于检测并削弱某些特定类型的攻击，包括跨站脚本（XSS）和数据注入攻击等。无论是数据盗取、网站内容污染还是恶意软件分发，这些攻击都是主要的手段。 CSP 被设计成完全向后兼容。不支持 CSP 的浏览器也能与实现了 CSP 的服务器正常工作，反之亦然：不支持 CSP 的浏览器只会忽略它，如常运行，默认为网页内容使用标准的同源策略。如果网站不提供 CSP 标头，浏览器也使用标准的同源策略。简单来说，CSP 的作用是：开发者明确告诉客户端（制定比较严格的策略和规则），哪些外部资源是可以加载和执行的，即使攻击者发现漏洞，但是它是没办法注入脚本的。

CSP 的使用方式

CSP可以由两种方式指定： HTTP Header 和 HTML。

"Content-Security-Policy:" 策略集 //  HTTP Header
<meta http-equiv="content-security-policy" content="策略集"> //  HTML

如果 HTTP 头与 meta 标签同时定义了 CSP，则会优先采用 HTTP 头的。 定义后，凡是不符合 CSP 策略的外部资源都会被阻止加载。

56.浏览器的安全沙箱策略

从稳定性视角来看，单进程架构的浏览器是不稳定的，因为只要浏览器进程中的任意一个功能出现异常都有可能影响到整个浏览器，如页面卡死、浏览器崩溃等。不过浏览器的稳定性并不是本文讨论的重点，我们今天主要聊的是浏览器架构是如何影响到操作系统安全的。浏览器本身的漏洞是单进程浏览器的一个主要问题，如果浏览器被曝出存在漏洞，那么在这些漏洞没有被及时修复的情况下，黑客就有可能通过恶意的页面向浏览器中注入恶意程序，其中最常见的攻击方式是利用缓冲区溢出，不过需要注意这种类型的攻击和 XSS 注入的脚本是不一样的。

●XSS 攻击只是将恶意的 JavaScript 脚本注入到页面中，虽然能窃取一些 Cookie 相关的数据，但是 XSS 无法对操作系统进行攻击。

●而通过浏览器漏洞进行的攻击是可以入侵到浏览器进程内部的，可以读取和修改浏览器进程内部的任意内容，还可以穿透浏览器，在用户的操作系统上悄悄地安装恶意软件、监听用户键盘输入信息以及读取用户硬盘上的文件内容。

和 XSS 攻击页面相比，这类攻击无疑是枚“核弹”，它会将整个操作系统的内容都暴露给黑客，这样我们操作系统上所有的资料都是不安全的了。

安全视角下的多进程架构

现代浏览器的设计目标是安全、快速和稳定，而这种核弹级杀伤力的安全问题就是一个很大的潜在威胁，因此在设计现代浏览器的体系架构时，需要解决这个问题。

浏览器内核和渲染进程观察上图，我们知道浏览器被划分为浏览器内核和渲染内核两个核心模块，其中浏览器内核是由网络进程、浏览器主进程和 GPU 进程组成的，渲染内核就是渲染进程。那如果我们在浏览器中打开一个页面，这两个模块是怎么配合的呢？

所有的网络资源都是通过浏览器内核来下载的，下载后的资源会通过 IPC 将其提交给渲染进程（浏览器内核和渲染进程之间都是通过 IPC 来通信的）。然后渲染进程会对这些资源进行解析、绘制等操作，最终生成一幅图片。但是渲染进程并不负责将图片显示到界面上，而是将最终生成的图片提交给浏览器内核模块，由浏览器内核模块负责显示这张图片。

●设计现代浏览器体系架构时，将浏览器划分为不同的进程是为了增加其稳定性。虽然设计成了多进程架构，不过这些模块之间的沟通方式却有些复杂，也许你还有以下问题： ●为什么一定要通过浏览器内核去请求资源，再将数据转发给渲染进程，而不直接从进程内部去请求网络资源？为什么渲染进程只负责生成页面图片，生成图片还要经过 IPC 通知浏览器内核模块，然后让浏览器内核去负责展示图片？

要解释现代浏览器为什么要把这个流程弄得这么复杂，我们就得从系统安全的角度来分析。

理解安全沙箱

上面我们分析过了，由于渲染进程需要执行 DOM 解析、CSS 解析、网络图片解码等操作，如果渲染进程中存在系统级别的漏洞，那么以上操作就有可能让恶意的站点获取到渲染进程的控制权限，进而又获取操作系统的控制权限，这对于用户来说是非常危险的。因为网络资源的内容存在着各种可能性，所以浏览器会默认所有的网络资源都是不可信的，都是不安全的。但谁也不能保证浏览器不存在漏洞，只要出现漏洞，黑客就可以通过网络内容对用户发起攻击。我们知道，如果你下载了一个恶意程序，但是没有执行它，那么恶意程序是不会生效的。同理，浏览器之于网络内容也是如此，浏览器可以安全地下载各种网络资源，但是如果要执行这些网络资源，比如解析 HTML、解析 CSS、执行 JavaScript、图片编解码等操作，就需要非常谨慎了，因为一不小心，黑客就会利用这些操作对含有漏洞的浏览器发起攻击。基于以上原因，我们需要在渲染进程和操作系统之间建一道墙，即便渲染进程由于存在漏洞被黑客攻击，但由于这道墙，黑客就获取不到渲染进程之外的任何操作权限。将渲染进程和操作系统隔离的这道墙就是我们要聊的安全沙箱。浏览器中的安全沙箱是利用操作系统提供的安全技术，让渲染进程在执行过程中无法访问或者修改操作系统中的数据，在渲染进程需要访问系统资源的时候，需要通过浏览器内核来实现，然后将访问的结果通过 IPC 转发给渲染进程。安全沙箱最小的保护单位是进程。因为单进程浏览器需要频繁访问或者修改操作系统的数据，所以单进程浏览器是无法被安全沙箱保护的，而现代浏览器采用的多进程架构使得安全沙箱可以发挥作用。

安全沙箱如何影响各个模块功能

我们知道安全沙箱最小的保护单位是进程，并且能限制进程对操作系统资源的访问和修改，这就意味着如果要让安全沙箱应用在某个进程上，那么这个进程必须没有读写操作系统的功能，比如读写本地文件、发起网络请求、调用 GPU 接口等。

安全沙箱是如何影响到各个模块功能的呢？

持久存储我们先来看看安全沙箱是如何影响到浏览器持久存储的。由于安全沙箱需要负责确保渲染进程无法直接访问用户的文件系统，但是在渲染进程内部有访问 Cookie 的需求、有上传文件的需求，为了解决这些文件的访问需求，所以现代浏览器将读写文件的操作全部放在了浏览器内核中实现，然后通过 IPC 将操作结果转发给渲染进程。具体地讲，如下文件内容的读写都是在浏览器内核中完成的： ●存储 Cookie 数据的读写。通常浏览器内核会维护一个存放所有 Cookie 的 Cookie 数据库，然后当渲染进程通过 JavaScript 来读取 Cookie 时，渲染进程会通过 IPC 将读取 Cookie 的信息发送给浏览器内核，浏览器内核读取 Cookie 之后再将内容返回给渲染进程。 ●一些缓存文件的读写也是由浏览器内核实现的，比如网络文件缓存的读取。
网络访问同样有了安全沙箱的保护，在渲染进程内部也是不能直接访问网络的，如果要访问网络，则需要通过浏览器内核。不过浏览器内核在处理 URL 请求之前，会检查渲染进程是否有权限请求该 URL，比如检查 XMLHttpRequest 或者 Fetch 是否是跨站点请求，或者检测 HTTPS 的站点中是否包含了 HTTP 的请求。
用户交互渲染进程实现了安全沙箱，还影响到了一个非常重要的用户交互功能。通常情况下，如果你要实现一个 UI 程序，操作系统会提供一个界面给你，该界面允许应用程序与用户交互，允许应用程序在该界面上进行绘制，比如 Windows 提供的是 HWND，Linux 提供的 X Window，我们就把 HWND 和 X Window 统称为窗口句柄。应用程序可以在窗口句柄上进行绘制和接收键盘鼠标消息。不过在现代浏览器中，由于每个渲染进程都有安全沙箱的保护，所以在渲染进程内部是无法直接操作窗口句柄的，这也是为了限制渲染进程监控到用户的输入事件。由于渲染进程不能直接访问窗口句柄，所以渲染进程需要完成以下两点大的改变。

第一点，渲染进程需要渲染出位图。为了向用户显示渲染进程渲染出来的位图，渲染进程需要将生成好的位图发送到浏览器内核，然后浏览器内核将位图复制到屏幕上。

第二点，操作系统没有将用户输入事件直接传递给渲染进程，而是将这些事件传递给浏览器内核。然后浏览器内核再根据当前浏览器界面的状态来判断如何调度这些事件，如果当前焦点位于浏览器地址栏中，则输入事件会在浏览器内核内部处理；如果当前焦点在页面的区域内，则浏览器内核会将输入事件转发给渲染进程。之所以这样设计，就是为了限制渲染进程有监控到用户输入事件的能力，所以所有的键盘鼠标事件都是由浏览器内核来接收的，然后浏览器内核再通过 IPC 将这些事件发送给渲染进程。

上面我们分析了由于渲染进程引入了安全沙箱，所以浏览器的持久存储、网络访问和用户交互等功能都不能在渲染进程内直接使用了，因此我们需要把这些功能迁移到浏览器内核中去实现，这让原本比较简单的流程变得复杂了。

理解站点隔离

所谓站点隔离是指 Chrome 将同一站点（包含了相同根域名和相同协议的地址）中相互关联的页面放到同一个渲染进程中执行。

最开始 Chrome 划分渲染进程是以标签页为单位，也就是说整个标签页会被划分给某个渲染进程。但是，按照标签页划分渲染进程存在一些问题，原因就是一个标签页中可能包含了多个 iframe，而这些 iframe 又有可能来自于不同的站点，这就导致了多个不同站点中的内容通过 iframe 同时运行在同一个渲染进程中。目前所有操作系统都面临着两个 A 级漏洞——幽灵（Spectre）和熔毁（Meltdown），这两个漏洞是由处理器架构导致的，很难修补，黑客通过这两个漏洞可以直接入侵到进程的内部，如果入侵的进程没有安全沙箱的保护，那么黑客还可以发起对操作系统的攻击。

所以如果一个银行站点包含了一个恶意 iframe，然后这个恶意的 iframe 利用这两个 A 级漏洞去入侵渲染进程，那么恶意程序就能读取银行站点渲染进程内的所有内容了，这对于用户来说就存在很大的风险了。因此 Chrome 几年前就开始重构代码，将标签级的渲染进程重构为 iframe 级的渲染进程，然后严格按照同一站点的策略来分配渲染进程，这就是 Chrome 中的站点隔离。

实现了站点隔离，就可以将恶意的 iframe 隔离在恶意进程内部，使得它无法继续访问其他 iframe 进程的内容，因此也就无法攻击其他站点了。

值得注意是，2019 年 10 月 20 日 Chrome 团队宣布安卓版的 Chrome 已经全面支持站点隔离，你可以参考文中链接。

安全沙箱总结

由于单进程浏览器在系统安全方面的不足，如果浏览器存在漏洞，那么黑客就有机会通过页面对系统发起攻击。

因此在设计现代浏览器的体系架构时，就考虑到这个问题了。于是，在多进程的基础之上引入了安全沙箱，有了安全沙箱，就可以将操作系统和渲染进程进行隔离，这样即便渲染进程由于漏洞被攻击，也不会影响到操作系统的。由于渲染进程采用了安全沙箱，所以在渲染进程内部不能与操作系统直接交互，于是就在浏览器内核中实现了持久存储、网络访问和用户交互等一系列与操作系统交互的功能，然后通过 IPC 和渲染进程进行交互。

最后我们还分析了 Chrome 中最新的站点隔离功能。由于最初都是按照标签页来划分渲染进程的，所以如果一个标签页里面有多个不同源的 iframe，那么这些 iframe 也会被分配到同一个渲染进程中，这样就很容易让黑客通过 iframe 来攻击当前渲染进程。而站点隔离会将不同源的 iframe 分配到不同的渲染进程中，这样即使黑客攻击恶意 iframe 的渲染进程，也不会影响到其他渲染进程的。

安全沙箱介绍的内容和概念都比较多，看上去离前端比较远，不过这些内容会影响你对浏览器整体架构的理解，而深入理解了浏览器架构能帮助你更加深刻地理解前端内容。

1.什么是 XSS 攻击？​

2.如何防御 XSS 攻击？​

3.什么是 CSRF 攻击？​

4.如何防御 CSRF 攻击？​

5.什么是中间人攻击？如何防范中间人攻击？​

6. 有哪些可能引起前端安全的问题?​

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

8. 进程与线程的概念​

9. 进程和线程的区别​

10. 浏览器渲染进程的线程有哪些​

11. 进程之间的通信方式​

12. 僵尸进程和孤儿进程是什么？​

13. 死锁产生的原因？ 如果解决死锁的问题？​

14. 如何实现浏览器内多个标签页之间的通信?​

15. 对Service Worker的理解​

16. 对浏览器的缓存机制的理解​

17. 浏览器资源缓存的位置有哪些？​

18. 协商缓存和强缓存的区别​

（1）强缓存​

（2）协商缓存​

19. 为什么需要浏览器缓存？​

20. 对浏览器内核的理解​

21. 常见的浏览器内核比较​

22. 常见浏览器所用内核​

23. 浏览器的主要组成部分​

24. 浏览器的渲染过程​

25. 浏览器渲染优化​

26、渲染过程中遇到 JS 文件如何处理？​

27. CSS 如何阻塞文档解析？​

28.什么情况会阻塞渲染？​

29. 浏览器本地存储方式及使用场景​

（1）Cookie​

（2）LocalStorage​

（3）SessionStorage​

30. Cookie、LocalStorage、SessionStorage区别​

31. 前端储存的⽅式有哪些？​

32. IndexedDB有哪些特点？​

33.什么是同源策略​

34.如何解决跨越问题​

（1）CORS​

减少OPTIONS请求次数：​

CORS中Cookie相关问题：​

（2）JSONP​

（3）postMessage 跨域​

（4）nginx代理跨域​

（5）nodejs 中间件代理跨域​

（6）document.domain + iframe跨域​

（7）location.hash + iframe跨域​

（8）window.name + iframe跨域​

（9）WebSocket协议跨域​

35.正向代理和反向代理的区别​

36.Nginx的概念及其工作原理​

37.事件是什么？事件模型？​

38. 如何阻止事件冒泡​

39.对事件委托的理解​

（1）事件委托的概念​

（2）事件委托的特点​

（3）局限性​

40.事件委托的使用场景​

41.对事件循环的理解​

说一下node环境中的事件循环​

42.宏任务和微任务分别有哪些​

43.什么是执行栈​

44.Node 中的 Event Loop 和浏览器中的有什么区别？process.nextTick 执行顺序？​

45.事件触发的过程是怎样的​

46.V8的垃圾回收机制是怎样的​

47.哪些操作会造成内存泄漏？​

48.渲染合成层是什么？​

基础​

浏览器渲染流程​

性能优化​

49.iframe如何理解？ 有什么特点？一般应用在什么场景？？​

iframe 是什么？​

iframe 的安全隐患​

iframe 的应用场景​

iframe 在现代微前端中扮演的角色​

50.为什么浏览器要限制并发连接数？​

What​

Why​

不同浏览器的请求并发限制​

1.什么是 XSS 攻击？

2.如何防御 XSS 攻击？

3.什么是 CSRF 攻击？

4.如何防御 CSRF 攻击？

5.什么是中间人攻击？如何防范中间人攻击？

6. 有哪些可能引起前端安全的问题?

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

8. 进程与线程的概念

9. 进程和线程的区别

10. 浏览器渲染进程的线程有哪些

11. 进程之间的通信方式

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

13. 死锁产生的原因？如果解决死锁的问题？

14. 如何实现浏览器内多个标签页之间的通信?

15. 对Service Worker的理解

16. 对浏览器的缓存机制的理解

17. 浏览器资源缓存的位置有哪些？

18. 协商缓存和强缓存的区别

（1）强缓存

（2）协商缓存

19. 为什么需要浏览器缓存？

20. 对浏览器内核的理解

21. 常见的浏览器内核比较

22. 常见浏览器所用内核

23. 浏览器的主要组成部分

24. 浏览器的渲染过程

25. 浏览器渲染优化

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

27. CSS 如何阻塞文档解析？

28.什么情况会阻塞渲染？

29. 浏览器本地存储方式及使用场景

（1）Cookie

（2）LocalStorage

（3）SessionStorage

30. Cookie、LocalStorage、SessionStorage区别

31. 前端储存的⽅式有哪些？

32. IndexedDB有哪些特点？

33.什么是同源策略

34.如何解决跨越问题

（1）CORS

减少OPTIONS请求次数：

CORS中Cookie相关问题：

（2）JSONP

（3）postMessage 跨域

（4）nginx代理跨域

（5）nodejs 中间件代理跨域

（6）document.domain + iframe跨域

（7）location.hash + iframe跨域

（8）window.name + iframe跨域

（9）WebSocket协议跨域

35.正向代理和反向代理的区别

36.Nginx的概念及其工作原理

37.事件是什么？事件模型？

38. 如何阻止事件冒泡

39.对事件委托的理解

（1）事件委托的概念

（2）事件委托的特点

（3）局限性

40.事件委托的使用场景

41.对事件循环的理解

说一下node环境中的事件循环

42.宏任务和微任务分别有哪些

43.什么是执行栈

44.Node 中的 Event Loop 和浏览器中的有什么区别？process.nextTick 执行顺序？

45.事件触发的过程是怎样的

46.V8的垃圾回收机制是怎样的

47.哪些操作会造成内存泄漏？

48.渲染合成层是什么？

基础

浏览器渲染流程

性能优化

49.iframe如何理解？有什么特点？一般应用在什么场景？？

iframe 是什么？

iframe 的安全隐患

iframe 的应用场景

iframe 在现代微前端中扮演的角色

50.为什么浏览器要限制并发连接数？

What

Why

不同浏览器的请求并发限制