前端基础知识之浏览器(browser)篇

[zptime]

Repaint 和 Reflow

• 浏览器渲染过程

1. 解析 HTML，生成 DOM 树，解析 CSS，生成 CSSOM 树
2. 将 DOM 树和 CSSOM 树结合，生成渲染树(Render Tree)
3. Layout(回流):根据生成的渲染树，进行回流(Layout)，得到节点的几何信息（位置，大小）
4. Painting(重绘):根据渲染树以及回流得到的几何信息，得到节点的绝对像素
5. Display:将像素发送给 GPU，展示在页面上。

• 生成渲染树：从 DOM 树的根节点开始遍历每个可见节点；对于每个可见的节点，找到 CSSOM 树中对应的规则，并应用它们；根据每个可见节点以及其对应的样式，组合生成渲染树。（注意：渲染树只包含可见的节点）
• 回流：布局或者几何属性需要改变就称为回流。通过构造渲染树，将可见 DOM 节点以及它对应的样式结合起来，可是我们还需要计算它们在设备视口(viewport)内的确切位置和大小，这个计算的阶段就是回流。当页面布局和几何信息发生变化的时候，就需要回流，比如如下情况：（注意：回流一定会触发重绘，而重绘不一定会回流）

1. 添加或删除可见的 DOM 元素
2. 元素的位置发生变化
3. 元素的尺寸发生变化（包括外边距、内边框、边框大小、高度和宽度等）
4. 内容发生变化，比如文本变化或图片被另一个不同尺寸的图片所替代。
5. 页面一开始渲染的时候
6. 浏览器的窗口尺寸变化（因为回流是根据视口的大小来计算元素的位置和大小的）

• 重绘：由于节点的几何属性发生改变或者由于样式发生改变而不会影响布局的，称为重绘。通过构造渲染树和回流阶段，知道哪些节点是可见的，以及可见节点的样式和具体的几何信息(位置、大小)，就可以将渲染树的每个节点都转换为屏幕上的实际像素，这个阶段就叫做重绘节点。

浏览器和 node 循环事件区别

• 关于微任务和宏任务在浏览器的执行顺序是这样的：执行一只 task（宏任务）-> 执行完 micro-task 队列（微任务）-> 如此循环往复下去
• 浏览器的 task（宏任务）执行顺序在 html#event-loops 里面有讲。常见的 task（宏任务） 比如：setTimeout、setInterval、script（整体代码）、 I/O 操作、UI 渲染等。 常见的 micro-task 比如: new Promise().then(回调)、MutationObserver(html5 新特性) 等。
• Node 10 以前：执行完一个阶段的所有任务 执行完 nextTick 队列里面的内容 然后执行完微任务队列的内容。在 node11 以下版本的执行结果(先执行所有的宏任务，再执行微任务)。
• Node 11 以后： 和浏览器的行为统一了，都是每执行一个宏任务就执行完微任务队列。在 node11 及浏览器的执行结果(顺序执行宏任务和微任务)。

脚本攻击

• cookie：登陆后后端生成一个 sessionid 放在 cookie 中返回给客户端，并且服务端一直记录着这个 sessionid，客户端以后每次请求都会带上这个 sessionid，服务端通过这个 sessionid 来验证身份之类的操作。所以别人拿到了 cookie 拿到了 sessionid 后，就可以完全替代你。

• token：登陆后后端不返回一个 token 给客户端，客户端将这个 token 存储起来，然后每次客户端请求都需要开发者手动将 token 放在 header 中带过去，服务端每次只需要对这个 token 进行验证就能使用 token 中的信息来进行下一步操作了。

• xss(Cross Site Scripting, 跨站脚本攻击)：用户通过各种方式将恶意代码注入到其他用户的页面中。就可以通过脚本获取信息，发起请求，之类的操作。

• csrf（Cross-site request forgery 跨站请求伪造）：简单地说，是攻击者通过一些技术手段欺骗用户的浏览器去访问一个自己曾经认证过的网站并运行一些操作（如发邮件，发消息，甚至财产操作如转账和购买商品）。由于浏览器曾经认证过，所以被访问的网站会认为是真正的用户操作而去运行。这利用了 web 中用户身份验证的一个漏洞：简单的身份验证只能保证请求发自某个用户的浏览器，却不能保证请求本身是用户自愿发出的。csrf 并不能够拿到用户的任何信息，它只是欺骗用户浏览器，让其以用户的名义进行操作。

浏览器缓存机制

• Service Worker 是运行在浏览器背后的独立线程，一般可以用来实现缓存功能。使用 Service Worker 的话，传输协议必须为 HTTPS。因为 Service Worker 中涉及到请求拦截，所以必须使用 HTTPS 协议来保障安全。Service Worker 的缓存与浏览器其他内建的缓存机制不同，它可以让我们自由控制缓存哪些文件、如何匹配缓存、如何读取缓存，并且缓存是持续性的。
• Memory Cache 也就是内存中的缓存，主要包含的是当前中页面中已经抓取到的资源，例如页面上已经下载的样式、脚本、图片等。读取内存中的数据肯定比磁盘快，内存缓存虽然读取高效，可是缓存持续性很短，会随着进程的释放而释放。 一旦我们关闭 Tab 页面，内存中的缓存也就被释放了。
• Disk Cache 也就是存储在硬盘中的缓存，读取速度慢点，但是什么都能存储到磁盘中，比之 Memory Cache 胜在容量和存储时效性上。在所有浏览器缓存中，Disk Cache 覆盖面基本是最大的。它会根据 HTTP Header 中的字段判断哪些资源需要缓存，哪些资源可以不请求直接使用，哪些资源已经过期需要重新请求。并且即使在跨站点的情况下，相同地址的资源一旦被硬盘缓存下来，就不会再次去请求数据。
• Push Cache（推送缓存）是 HTTP/2 中的内容，当以上三种缓存都没有命中时，它才会被使用。它只在会话（Session）中存在，一旦会话结束就被释放，并且缓存时间也很短暂，在 Chrome 浏览器中只有 5 分钟左右，同时它也并非严格执行 HTTP 头中的缓存指令。

Charles，手机配置代理

• 电脑上安装代理软件 (charles, fiddler 等等)
• 以 charles 为例，打开 Proxy - Proxy Settings - Proxies 配置/记录代理端口 (HTTP Proxy port)， 如 8888
• 打开 Tools - Map Remote Settings, 添加一行 127.0.0.1 localhost，将 localhost 定向到电脑本地
• 手机和电脑连接同一个 WIFI 网络，修改手机的 WIFI 配置，找到高级设置，填入电脑的 IP 和刚才记录的端口号 (例如 192.168.10.199:8888)
• 打开手机中支持 PWA 特性的浏览器 (推荐 Google Chrome)，输入 URL localohst:3000 (3000 为 lavas 默认服务端口)，能够展现首页的话，在右上角菜单中也可以看到“添加到主屏幕”。
• 注意：实际使用时，还是只能通过 ip 访问，localhost 无法访问。

window.name 属性

• window.name 是一个所有浏览器都有的属性，表示浏览器窗口的名称，默认是一个空字符串，所有浏览器都是个空字符串。
• window.name 的跨页面特性：如果设置了 window.name，即使页面跳转到了其他页面，这个 window.name 还是会保留。可以用来记忆来源页面设置的 window.name 值，比 document.referrer 还要好用。
• 新窗口打开的 window.name 无效，仍未空。
• window.name 的值是跟着浏览器窗体走的，只要在一个窗体中，就可以共享一个值，于是可以实现跨域数据获取，这个在以前还是挺有名的一个跨域方法，名叫“window.name Transport”，要比 JSONP 要安全些。现在使用 window.name 实现跨域通信已经属于鸡肋方法了，可使用postMessage 跨域跨文档通信代替，更好用更安全更强大。

sessionStorage 、localStorage 和 cookie 之间的区别

• 共同点：都是保存在浏览器端，且同源的。
• 区别
  • cookie数据始终在同源的http请求中携带（即使不需要），即cookie在浏览器和服务器间来回传递。而sessionStorage和localStorage不会自动把数据发给服务器，仅在本地保存。
  • cookie数据还有路径（path）的概念，可以限制cookie只属于某个路径下。
  • 存储大小限制也不同，cookie数据不能超过4k，同时因为每次http请求都会携带cookie，所以cookie只适合保存很小的数据，如会话标识。sessionStorage和localStorage 虽然也有存储大小的限制，但比cookie大得多，可以达到5M或更大。
  • 数据有效期不同，sessionStorage：仅在当前浏览器窗口关闭前有效，自然也就不可能持久保持；localStorage：始终有效，窗口或浏览器关闭也一直保存，因此用作持久数据；cookie只在设置的cookie过期时间之前一直有效，即使窗口或浏览器关闭。
  • 作用域不同，sessionStorage不在不同的浏览器窗口中共享，即使是同一个页面；localStorage 在所有同源窗口中都是共享的；cookie也是在所有同源窗口中都是共享的。
  • Web Storage 支持事件通知机制，可以将数据更新的通知发送给监听者。Web Storage 的 api 接口使用更方便。

Html5解决跨域问题

• 跨域，指的是浏览器不能执行其他网站的脚本。它是由浏览器的同源策略造成的，是浏览器对JavaScript施加的安全限制。域名、端口、协议有一个不同，都属于跨域。
• HTML5提供的XMLHttpRequest Level2实现了跨域访问以及其他的一些新功能