Web 前端入门必知 —— 浏览器基础知识
是将用户选择的 web 资源呈现出来，它需要从服务器请求资源，并将其显示在浏览器窗口中，资源的格式通常是 HTML，也包括 PDF、image 及其他格式。用户用 URI（Uniform Resource Identifier 统一资源标识符）来指定所请求资源的位置。
浏览器的主要组件包括：
1. 用户界面 － 包括地址栏、后退 / 前进按钮、书签目录等，也就是你所看到的除了用来显示你所请求页面的主窗口之外的其他部分。
2. 浏览器引擎 － 用来查询及操作渲染引擎的接口。
3. 渲染引擎 － 用来显示请求的内容，例如，如果请求内容为 html，它负责解析 html 及 css，并将解析后的结果显示出来。
4. 网络 － 用来完成网络调用，例如 http 请求，它具有平台无关的接口，可以在不同平台上工作。
5. UI 后端 － 用来绘制类似组合选择框及对话框等基本组件，具有不特定于某个平台的通用接口，底层使用操作系统的用户接口。
6. JS 解释器 － 用来解释执行 JS 代码。
7. 数据存储 － 属于持久层，浏览器需要在硬盘中保存类似 cookie 的各种数据，HTML5 定义了 web database 技术，这是一种轻量级完整的客户端存储技术。
1. 浏览器输入 URL 到显示页面发生了什么？
老问题，大家面试的时候应该都被问过这种问题，网上的答案千篇一律，我们来更深入的了解一下。
1.1 在浏览器中输入 url
1.2 查看浏览器缓存
如果访问过该 url，会先进入浏览器缓存中查询是否有要请求的文件（浏览器缓存是在本地保存资源副本）。
当浏览器发现请求的资源已经在浏览器缓存中存有副本，它会拦截请求，返回该资源的副本，并直接结束请求，而不会再去源服务器重新下载。如果缓存查找失败，就会进入网络请求过程了。
在 network 中会标注该请求是在服务器中请求的还是浏览器缓存中的。
一条域名的 DNS 记录会在本地有两种缓存：浏览器缓存和操作系统 (OS) 缓存。
1.2.1 浏览器缓存 – 浏览器会缓存 DNS 记录一段时间。一般是 2 分钟到 30 分钟不等。查找浏览器缓存时会按顺序查找: Service Worker–>Memory Cache–>Disk Cache–>Push Cache。
Service Worker：
是运行在浏览器背后的独立线程，一般可以用来实现缓存功能。使用 Service Worker 的话，传输协议必须为 HTTPS。因为 Service Worker 中涉及到请求拦截，所以必须使用 HTTPS 协议来保障安全。Service Worker 的缓存与浏览器其他内建的缓存机制不同，它可以让我们自由控制缓存哪些文件、如何匹配缓存、如何读取缓存，并且缓存是持续性的。
Memory Cache：
内存中的缓存，主要包含的是当前中页面中已经抓取到的资源，例如页面上已经下载的样式、脚本、图片等。读取内存中的数据肯定比磁盘快，内存缓存虽然读取高效，可是缓存持续性很短，会随着进程的释放而释放。一旦我们关闭 Tab 页面，内存中的缓存也就被释放了。
Disk Cache：
存储在硬盘中的缓存，读取速度慢点，但是什么都能存储到磁盘中，比之 Memory Cache 胜在容量和存储时效性上。
在所有浏览器缓存中，Disk Cache 覆盖面基本是最大的。它会根据 HTTP Herder 中的字段判断哪些资源需要缓存，哪些资源可以不请求直接使用，哪些资源已经过期需要重新请求。并且即使在跨站点的情况下，相同地址的资源一旦被硬盘缓存下来，就不会再次去请求数据。绝大部分的缓存都来自 Disk Cache。
Push Cache：
Push Cache（推送缓存）是 HTTP/2 中的内容，当以上三种缓存都没有命中时，它才会被使用。它只在会话（Session）中存在，一旦会话结束就被释放，并且缓存时间也很短暂，在 Chrome 浏览器中只有 5 分钟左右，同时它也并非严格执行 HTTP 头中的缓存指令。
1.2.2 系统缓存 – 如果在浏览器缓存里没有找到需要的记录，浏览器会做一个系统调用获得系统缓存中的记录（windows 里是 gethostbyname）。
1.2.3 路由器缓存 ** – 接着，前面的查询请求发向路由器，它一般会有自己的 DNS 缓存。
1.2.4 ISP DNS 缓存 ** – 接下来要 check 的就是 ISP 缓存 DNS 的服务器。在这一般都能找到相应的缓存记录。
1.2.5 递归搜索 ** – 你的 ISP 的 DNS 服务器从跟域名服务器开始进行递归搜索，从.com 顶级域名服务器到 Facebook 的域名服务器。一般 DNS 服务器的缓存中会有.com 域名服务器中的域名，所以到顶级服务器的匹配过程不是那么必要了。
1.3 DNS 域名解析
如果没有访问过该 url，就会进行 DNS 域名解析了。
IP 地址和域名一样都是用来做网络标识的，域名和 IP 地址是一一对应的映射关系。
DNS：Domain Name System 域名系统（基于 RFC 规范解释），是万维网上作为域名和 IP 地址相互映射的一个分布式数据库，能够使用户更方便的访问互联网，而不用去记住能够被机器直接读取的 IP 数串。
DNS 解析过程：
1.3.1 用户主机上运行着 DNS 的客户端，就是我们的 PC 机或者手机客户端运行着 DNS 客户端。
1.3.2 浏览器将接收到的 url 中抽取出域名字段，就是访问的主机名，比如 www.feng.com, 并将这个主机名传送给 DNS 应用的客户端.
1.3.3 DNS 客户机端向 DNS 服务器端发送一份查询报文，报文中包含着要访问的主机名字段（中间包括一些列缓存查询以及分布式 DNS 集群的工作）。
1.3.4 该 DNS 客户机最终会收到一份回答报文，其中包含有该主机名对应的 IP 地址。
1.3.5 一旦该浏览器收到来自 DNS 的 IP 地址，就可以向该 IP 地址定位的 HTTP 服务器发起 TCP 连接。
1.4 获取端口号
可能域名下有多个端口号，对应着不同的网络功能，所以在 DNS 解析之后，浏览器还会获取端口号。
1.5 建立 TCP 连接
TCP 连接，就是耳熟能详的三次握手好朋友，四次挥手是路人。
TCP 连接过程：
1.5.1 服务端通过 socket，bind 和 listen 准备好接受外来的连接，此时服务端状态为 Listen。
1.5.2 客户端通过调用 connect 来发起主动连接，导致客户端 TCP 发送一个 SYN（同步）字节，告诉服务器客户将在（待建立的）连接中发送的数据的初始序列号，客户端状态为 SYN_SENT。
1.5.3 服务器确认（ACK）客户的 SYN，并自己也发送一个 SYN，它包含服务器将在同一连接中发送数据的初始序列号。
1.5.4 客户端确认服务的 ACK 和 SYN，向服务器发送 ACK，客户端状态 ESTABLISHED。
1.5.5 服务器接收 ACK, 服务器状态 ESABLISHED。
1.6 HTTP 请求
既然我们握手成功了，连接到了 Web 服务器，浏览器会根据解析到的 IP 地址和端口号发起 HTTP 请求。
1.6.1 http 协议向服务器发送请求，发送请求的过程中，浏览器会向 Web 服务器以 Stream (流) 的形式传输数据，告诉 Web 服务器要访问服务器里面的哪个 Web 应用下的 Web 资源。
1.6.2 服务器接收到浏览器传输的数据后，开始解析接收到的数据，服务器解析请求里面的内容时知道客户端浏览器要访问的是应用里面的哪这个 Web 资源，然后服务器就去读取这个 Web 资源里面的内容，将读到的内容再以 Stream (流) 的形式传输给浏览器。
1.7 关闭 TCP
TCP 连接中止过程：
1.7.1 某端首先调用 close，成为主动关闭端，向另一端发送 FIN 分节，表示数据发送完毕，此时主动关闭端状态 FIN_WAIT_1；
1.7.2 接收到 FIN 的是被动关闭端，FIN 由 TCP 确认，先向主动关闭端发送 ACK，作为一个文件结束符传递给接收端应用进程（放在已排队等候该应用进程接收到的任何其他数据之后），因为 FIN 的接收意味着接收端应用进程在相应连接无额外数据可接收，接收端状态 CLOSE_WAIT；主动关闭端接收到 ACK 状态变为 FIN_WAIT_2；
1.7.3 一段时间后，接收端接收到这个文件结束符的应用进程调用 close 关闭套接字，向主动关闭端发送 FIN，接收端状态为 LAST_ACK；
1.7.4 主动关闭端确认 FIN，状态变为 TIME_WAIT，并向接收端发送 ACK，接收端接收到 ACK 关闭 TCP，而主动关闭端一段时间后也关闭 TCP；
1.8 浏览器渲染
当浏览器获得一个 html 文件时，会自上而下的加载，并在加载过程中进行解析渲染。
解析：
\1. 浏览器会将 HTML 解析成一个 DOM 树，DOM 树的构建过程是一个深度遍历过程：当前节点的所有子节点都构建好后才会去构建当前节点的下一个兄弟节点。
\2. 将 CSS 解析成 CSS Rule Tree 。
\3. 根据 DOM 树和 CSSOM 来构造 Rendering Tree。注意：Rendering Tree 渲染树并不等同于 DOM 树，因为一些像 Header 或 display:none 的东西就没必要放在渲染树中了。
\4. 有了 Render Tree，浏览器已经能知道网页中有哪些节点、各个节点的 CSS 定义以及他们的从属关系。下一步操作称之为 Layout，顾名思义就是计算出每个节点在屏幕中的位置。
- 再下一步就是绘制，即遍历 render 树，并使用 UI 后端层绘制每个节点
渲染：
\1. 接收服务器返回 html 文件。
\2. 浏览器开始载入 html 代码，发现＜head＞标签内有一个＜link＞标签引用外部 CSS 文件，浏览器又发出 CSS 文件的请求，服务器返回这个 CSS 文件。
\3. 浏览器继续载入 html 中＜body＞部分的代码，并且 CSS 文件已经拿到手了，可以开始渲染页面了。
\4. 浏览器在代码中发现一个＜img＞标签引用了一张图片，向服务器发出请求。此时浏览器不会等到图片下载完，而是继续渲染后面的代码。
\5. 服务器返回图片文件，由于图片占用了一定面积，影响了后面段落的排布，因此浏览器需要回过头来重新渲染这部分代码。
\6. 浏览器发现了一个包含一行 Javascript 代码的＜script＞标签，赶快运行它。
\7. Javascript 脚本执行了这条语句，它命令浏览器隐藏掉代码中的某个＜div＞ （style.display=”none”）。突然少了这么一个元素，浏览器不得不重新渲染这部分代码。
\8. 终于等到了＜/html＞的到来，浏览器泪流满面。
\9. 等等，还没完，用户点了一下界面中的 “换肤” 按钮，Javascript 让浏览器换了一下＜link＞标签的 CSS 路径。
\10. 浏览器召集了在座的各位＜div＞＜span＞＜ul＞＜li＞们，“大伙儿收拾收拾行李，咱得重新来过……”，浏览器向服务器请求了新的 CSS 文件，重新渲染页面。
2. 浏览器是如何解析代码的？
上面已经描述了大概，我们深入的了解一下，了解之后可以考虑考虑我们怎么写代码可以给浏览器减少点工作量。
2.1 解析 HTML
HTML 的解析是逐行解析。
浏览器的渲染引擎会解析ＨＴＭＬ文档并把标签转换成内容树中的ＤＯＭ节点。
它会解析 style 元素和外部文件中的样式数据。样式数据和ＨＴＭＬ中的显示控制将共同用来创建另一棵树 —— 渲染树。
渲染引擎会尝试尽快的把内容显示出来。它不会等到所有ＨＴＭＬ都被解析完才创建并布局渲染树。它会 在处理后续内容的同时把处理过的局部内容先展示出来。
浏览器的解析器通常把工作分给两个组件 —— 分词程序负责把输入切分成合法符号序列，解析程序负责按照句法规则分析文档结构和构建句法树。词法分析器知道如何过滤像空格，换行之类的无关字符。
解析器输出的树是由ＤＯＭ元素和属性节点组成的。
ＤＯＭ与标签几乎有着一一对应的关系，如下面的标签
<html>
<body>
<p>
Hello 枫
</p>
<div> <img src="feng.png"/></div>
</body>
</html>
会被转换成如的ＤＯＭ树：
2.2 解析 CSS
CSS 选择器的读取顺序是从右向左。
#molly div.haha span{color:#f00}
如上面的代码，浏览器会按照从右向左的顺序去读取选择器。
先找到 span 然后顺着往上找到 class 为 “haha” 的 div 再找到 id 为 “molly” 的元素。
成功匹配到则加入结果集，如果直到根元素 html 都没有匹配，则不再遍历这条路径，从下一个 span 开始重复这个过程。
整个过程会形成一条符合规则的索引树，树由上至下的节点是规则中从右向左的一个个选择符匹配的节点。
如果从左向右的顺序读取，在执行到左边的分支后发现没有相对应标签匹配，则会回溯到上一个节点再继续遍历，直到找到或者没有相匹配的标签才结束。
如果有 100 个甚至 1000 个分支的时候会消耗很多性能。反之从右向左查找极大的缩小的查找范围从而提高了性能。
这就解释了为什么 id 选择器大于类选择器，类选择器大于元素选择器。
2.3 解析 JS
在浏览器中有一个 js 解析器的工具，专门用来解析我们的 js 代码。
当浏览器遇到 js 代码时，立马召唤 “js 解析器” 出来工作。
解析器会找到 js 当中的所有变量、函数、参数等等，并且把变量赋值为未定义 (undefined)。
把函数取出来成为一个函数块，然后存放到仓库当中。这件事情做完了之后才开始逐行解析代码（由上向下，由左向右），然后再去和仓库进行匹配。
<script>
alert(a); //undefined
var a = 1;
alert(a); //1
</script>
<script>
a = 1;
alert(a);
//这个时候会运行报错！
//这时候a并不是一个变量，解析器找不到，仓库里面并没有a
</script>
再看一下这段代码
<script>
alert(a); //function a(){alert(4)}
var a = 1;
alert(a); //1
function a(){alert(2)}
alert(a); //1
var a = 3;
alert(a); //3
function a(){alert(4)}
alert(a); //3
</script>
在 js 预解析的时候，在遇到变量和函数重名的时候，只会保留函数块。在逐行解析代码的时候表达式（+、-、*、/、%、++、–、 参数 ……）会改变仓库里对应的值。
我们来了解一个词 “作用域”，现在把这个词拆分一下。 作用：读、写操作 域：空间、范围、区域… 连起来就是能够进行读写操作的一个区域。 “域”：函数、json、…… 都是作为一块作用域。 全局变量、局部变量、全局函数 一段 也是一块域。在域解析的时候，也是由上向下开始解析。这就解释了为什么引用的外部公共 js 文件（比如：jquery）应该放到自定义 js 上边的原因。
再来看一下这段代码
<script>
var a = 1;
function fn(){
alert(a); //undefined
var a = 2;
}
fn();
alert(a); //1
</script>
继续跟踪一下解析器的解析过程：首先函数 fn () 外部的 a 是一个全局变量，fn () 里面的 a 是一个局部变量。fn () 函数同时是一个作用域，只要是作用域，就得做预解析和逐行解析的步骤。所以第一个 alert 打印的是 fn () 作用域的仓库指向的变量 a，即为 undefined。第二个 alert 打印的是全局的变量 a，即为 1。
接下来继续看代码，基本雷同的代码，我改变其中一小个地方。
<script>
var a = 1;
function fn(){
alert(a); //1
a = 2;
}
fn();
alert(a); //2
</script>
看到这里当解析到 fn () 的时候，发现里面并没有任何变量，所以也就不往仓库里面存什么，此时的仓库里面是空的，啥也没有。但是这个时候解析并没有结束，而是从函数里面向外开始找，找到全局的变量 a。此时打印的正式全局变量 a 的值。
这里就涉及到一个作用域链的问题。整个解析过程像是一条链子一样。由上向下，由里到外。局部能够读写全局，全局无法读写局部。
来，继续看代码，基本雷同的代码，我再次改变其中一小个地方。
<script>
var a = 1;
function fn(a){
alert(a); //undefined
a = 2;
}
fn();
alert(a); //1
</script>
千万不能忘了，在预解析的时候浏览器除了要找变量和函数之外还需要找一些参数，并且赋值为未定义。所以这里的 fn (a) 相当于 fn (var a)，这个时候的逻辑就和第一段实例代码一样了。
继续搞事情，继续看代码，基本雷同的代码，我再次改变其中一小个地方。
<script>
var a = 1;
function fn(a){
alert(a); //1
a = 2;
}
fn(a);
alert(a); //1
</script>
当代码执行到 fn (a); 的时候调用的 fn () 函数并且把全局变量 a 作为参数传递进去。
此时打印的自然是 1，要记住 function fn (a) 相当于 function fn (var a)，所以这时候 a=2；改变的是局部变量 a，并没有影响到全局变量 a，所以第二次打印的依然是 1。
3. 浏览器的垃圾回收机制
由于字符串、对象和数组没有固定大小，所有当他们的大小已知时，才能对他们进行动态的存储分配。JavaScript 程序每次创建字符串、数组或对象时，解释器都必须分配内存来存储那个实体。只要像这样动态地分配了内存，最终都要释放这些内存以便他们能够被再用，否则，JavaScript 的解释器将会消耗完系统中所有可用的内存，造成系统崩溃。
JavaScript 的解释器可以检测到何时程序不再使用一个对象了，当他确定了一个对象是无用的时候，他就知道不再需要这个对象，可以把它所占用的内存释放掉了。
var a = "before";
var b = "override a";
var a = b; //重写a
这段代码运行之后，“before” 这个字符串失去了引用（之前是被 a 引用），系统检测到这个事实之后，就会释放该字符串的存储空间以便这些空间可以被再利用。
浏览器通常用采用的垃圾回收有两种方法：标记清除、引用计数。
3.1 标记清除
这是 javascript 中最常用的垃圾回收方式。当变量进入执行环境是，就标记这个变量为 “进入环境”。从逻辑上讲，永远不能释放进入环境的变量所占用的内存，因为只要执行流进入相应的环境，就可能会用到他们。当变量离开环境时，则将其标记为 “离开环境”。
垃圾收集器在运行的时候会给存储在内存中的所有变量都加上标记。然后，它会去掉环境中的变量以及被环境中的变量引用的标记。而在此之后再被加上标记的变量将被视为准备删除的变量，原因是环境中的变量已经无法访问到这些变量了。最后。垃圾收集器完成内存清除工作，销毁那些带标记的值，并回收他们所占用的内存空间。
当对象，无法从根对象沿着引用遍历到，即不可达（unreachable），进行清除。对于上面的例子，fn () 里面的 a 和 b 在函数执行完毕后，就不能通过外面的上下文进行访问了，所以就可以清除了。
这是当前主流的 GC 算法，V8 里面就是用这种。
不管是高级语言，还是低级语言。内存的管理都是：分配内存使用内存（读或写）释放内存前两步，大家都没有太大异议。关键是释放内存这一步，各种语言都有自己的垃圾回收（garbage collection, 简称GC）机制。
在大部分的应用场景：一个新创建的对象，生命周期通常很短。所以，V8 里面，GC 处理分为两大类：新生代和老生代。
新生代的堆空间为 1M~8M，而且被平分成两份（to-space 和 from-space），通常一个新创建的对象，内存被分配在新生代。当 to-space 满的时候，to-space 和 form-space 交换位置（此时，to 空，from 满），并执行 GC。如果一个对象被断定为，未被引用，就清除；有被引用，逃逸次数 + 1（如果此时逃逸次数为 2，就移入老生代，否则移入 to-space）。
老生代的堆空间大，GC 不适合像新生代那样，用平分成两个 space 这种空间换时间的方式。老生代的垃圾回收，分两个阶段：标记、清理（有 Sweeping 和 Compacting 这两种方式）。
标记，采用 3 色标记：黑、白、灰。步骤如下：
GC 开始，所以对象标记为白色。
根对象标记为黑色，并开始遍历其子节点（引用的对象）。
当前被遍历的节点，标记为灰色，被放入一个叫 marking bitmap 的栈。在栈中，把当前被遍历的节点，标记为黑色，并出栈，同时，把它的子节点（如果有的话）标记为灰色，并压入栈。（大对象比较特殊，这里不展开）
当所有对象被遍历完后，就只剩下黑和白。通过 Sweeping 或 Compacting 的方式，清理掉白色，完成 GC。
3.2 引用计次
引用计数的含义是跟踪记录每个值被引用的次数。当声明了一个变量并将一个引用类型赋值给该变量时，则这个值的引用次数就是 1。相反，如果包含对这个值引用的变量又取得了另外一个值，则这个值的引用次数就减 1。当这个引用次数变成 0 时，则说明没有办法再访问这个值了，因而就可以将其所占的内存空间给收回来。这样，垃圾收集器下次再运行时，它就会释放那些引用次数为 0 的值所占的内存。
但是用这种方法存在着一个问题，下面来看看代码：
function problem() {
var objA = new Object();
var objB = new Object();
objA.someOtherObject = objB;
objB.anotherObject = objA;
}
在这个例子中，objA 和 objB 通过各自的属性相互引用；也就是说这两个对象的引用次数都是 2。在采用引用计数的策略中，由于函数执行之后，这两个对象都离开了作用域，函数执行完成之后，objA 和 objB 还将会继续存在，因为他们的引用次数永远不会是 0。这样的相互引用如果说很大量的存在就会导致大量的内存泄露。
大多数浏览器已经放弃了这种回收方式。
4. 浏览器的本地存储
如果我问你，浏览器中的缓存有哪些，我相信绝大部分人会说有三种：cookie，sessionStorage，localStorage。
但是诶，我不知为什么大家都叫这三个为缓存，他们叫缓存，我们上面提到的 Memory Cache 等 cache 也叫缓存，不是很乱吗，而且浏览器把他们归到了 storage 里面，storage 翻译过来为存储。
还有一点，这里有五种：Cookies、Local Storage、Session Storage、WebSQL 和 IndexedDB。
4.1 cookie
Cookies 是最早的本地存储，是浏览器提供的功能，并且对服务器和 JS 开放，这意味着我们可以通过服务器端和客户端保存 Cookies。不过可以存储的数据总量大小只有 4KB，如果超过了这个限制就会忽略，没法进行保存。
HTTP 协议本身是无状态的。什么是无状态呢，即服务器无法判断用户身份。Cookie 实际上是一小段的文本信息（key-value 格式）。客户端向服务器发起请求，如果服务器需要记录该用户状态，就使用 response 向客户端浏览器颁发一个 Cookie。客户端浏览器会把 Cookie 保存起来。当浏览器再请求该网站时，浏览器把请求的网址连同该 Cookie 一同提交给服务器。服务器检查该 Cookie，以此来辨认用户状态。
4.2 Local Storage Session Storage
Local Storage 与 Session Storage 都属于 Web Storage。Web Storage 和 Cookies 类似，区别在于它有更大容量的存储。其中 Local Storage 是持久化的本地存储，除非我们主动删除数据，否则会一直存储在本地。Session Storage 只存在于 Session 会话中，也就是说只有在同一个 Session 的页面才能使用，当 Session 会话结束后，数据也会自动释放掉。
4.3 cookie Local Storage Session Storage 比较
一般在我们面试的时候，面试官都会问 cookie Local Storage Session Storage 之间有什么区别。
特性
Cookie
Local Storage
Session Storage
数据的生命期
可设置失效时间，默认是关闭浏览器后失效
除非被显式清除，否则永久保存
会话级存储，仅在当前会话下有效，会话结束，关闭页面或浏览器后被清除
存放数据大小
4KB 左右
5MB~10MB (浏览器不同，情况不同)
5MB~10MB (浏览器不同，情况不同)
与服务器端通信
每次都会携带在 HTTP 头中，如果使用 cookie 保存过多数据会带来性能和安全问题
仅在客户端（即浏览器）中保存，不参与和服务器的通信
仅在客户端（即浏览器）中保存，不参与和服务器的通信
易用性
源生的 Cookie 接口不友好，开发者需要根据需求封装
源生接口良好，亦可再次封装来对 Object 和 Array 有更好的支持
源生接口良好，亦可再次封装来对 Object 和 Array 有更好的支持
应用场景
用户登录时，保存服务器返回的一段加密过的唯一辨识单一用户的 code，用以判断当前用户登录状态，或者之前电商网站用来保存用户的购物车信息。
Local Storage 可以替代 Cookie 完成用户购物车信息的前端保存功能，同时可以当作 HTML5 游戏的本地数据的存储空间。
当页面存在多表单的情况下，可以利用 Session Storage 实现表单页拆分，优化用户体验。
注意
不要将系统敏感的数据保存到 Cookie，Local Storage，Session Storage 中，防止 XSS 注入的风险。因为 XSS 注入可以通过控制台对你的属性值进行修改，具体可以参考我写的另一篇博客，前端黑客技术。
4.4 WebSQL
WebSQL 与 IndexedDB 都是最新的 HTML5 本地缓存技术，相比于 Local Storage 和 Session Storage 来说，存储功能更强大，支持的数据类型也更多，比如图片、视频等。
WebSQL 更准确的说是 WebSQL DB API，它是一种操作本地数据库的网页 API 接口，通过 API 可以完成客户端数据库的操作。当我们使用 WebSQL 的时候，可以方便地用 SQL 来对数据进行增删改查。而这些浏览器客户端，比如 Chrome 和 Safari 会用 SQLite 实现本地存储，微信就采用了 SQLite 作为本地聊天记录的存储。
4.5 IndexedDB
IndexedDB 就是浏览器提供的本地数据库，它可以被网页脚本创建和操作。它可以存储大量数据，提供了查找接口，能够建立索引。但是不属于关系型数据库（不支持 SQL 查询语句，更类似于 NoSQL 数据库）。
IndexedDB 的特点：
- 键值对存储：IndexedDB 内部采用对象仓库（object store）存放数据。所有类型的数据都可以直接存入，包括 JavaScript 对象。对象仓库中，数据以 “键值对” 的形式保存。每一个数据记录都有对应的主键，主键是唯一的，如果重复会抛出一个错误。
- 异步：IndexedDB 操作不会锁死浏览器，用户依然可以进行其他操作，与 Local Storage 的同步操作不同，异步的设计是为了大量数据的读写，拖慢页面的表现，降低用户体验。
- 支持事务：IndexedDB 支持事务（transaction）, 这意味着一些列操作步骤中，只要有某个步骤出现异常，则整个事务就会消失，数据库回滚到事务发生之前的状态，不存在只写一部分数据的情况。
- 同源限制：IndexedDB 受到同源限制，每一个数据库对应创建它的域名。网页只能访问自身域名下的数据库，而不能够访问跨域的 IndexedDB 数据库。
- 存储空间大：IndexedDB 的存储空间一般不少于 250MB，或者更大。
- 支持二进制存储：IndexedDB 不仅可以储存字符串，还可以储存二进制数据（ArrayBuffer 对象和 Blob 对象）。
事务是数据库的概念，事务 (transaction) 是访问并可能操作各种数据项的一个数据库操作序列，这些操作要么全部执行，要么全部不执行，是一个不可分割的工作单位。事务由事务开始与事务结束之间执行的全部数据库操作组成。
5. 浏览器的线程
我们平常使用 JavaScript 的时候都知道 js 是单线程的，而浏览器，则是多线程的。
5.1 CPU
CPU 是计算机的核心，其负责承担计算机的计算任务。这里我们比喻为一个工厂。
5.2 进程
进程是一个具有一定独立功能的程序在一个数据集上的一次动态执行的过程，是操作系统进行资源分配和调度的一个独立单位，是应用程序运行的载体。
我们这里将进程比喻为工厂的车间，它代表 CPU 所能处理的单个任务。任一时刻，CPU 总是运行一个进程，其他进程处于非运行状态。
5.3 线程
线程是程序执行中一个单一的顺序控制流程，是程序执行流的最小单元。
这里把线程比喻一个车间的工人，即一个车间可以允许由多个工人协同完成一个任务。
5.4 浏览器的多线程
浏览器内核是多线程，在内核控制下各线程相互配合以保持同步，一个浏览器通常由以下常驻线程组成：
- GUI 渲染线程
- JavaScript 引擎线程
- 事件触发线程
- 定时触发器线程
- 异步 http 请求线程
5.4.1 GUI 渲染线程
GUI 渲染线程负责渲染浏览器界面 HTML 元素，解析 HTML，CSS，构建 DOM 树和 RenderObject 树，布局和绘制等。
当界面需要重绘 (Repaint) 或由于某种操作引发回流 (重排)(reflow) 时，该线程就会执行。
在 Javascript 引擎运行脚本期间，GUI 渲染线程都是处于挂起状态的，也就是说被” 冻结” 了，GUI 更新会被保存在一个队列中等到 JS 引擎空闲时立即被执行。
5.4.2 JavaScript 引擎线程
JavaScript 引擎，也可以称为 JS 内核，主要负责处理 Javascript 脚本程序，例如 V8 引擎。
JS 引擎一直等待着任务队列中任务的到来，然后加以处理，一个 Tab 页（renderer 进程）中无论什么时候都只有一个 JS 线程在运行 JS 程序（单线程）。
注意：GUI渲染线程和JavaScript引擎线程互斥。
由于 JavaScript 是可操纵 DOM 的，如果在修改这些元素属性同时渲染界面（即 JavaScript 线程和 UI 线程同时运行），那么渲染线程前后获得的元素数据就可能不一致了。
因此为了防止渲染出现不可预期的结果，浏览器设置 GUI 渲染线程与 JavaScript 引擎为互斥的关系，当 JavaScript 引擎执行时 GUI 线程会被挂起，GUI 更新会被保存在一个队列中等到引擎线程空闲时立即被执行。
如果 JS 执行的时间过长，这样就会造成页面的渲染不连贯，导致页面渲染加载阻塞的感觉。
5.4.3 事件触发线程
当一个事件被触发时该线程会把事件添加到待处理队列的队尾，等待 JS 引擎的处理。
这些事件可以是当前执行的代码块如定时任务、也可来自浏览器内核的其他线程如鼠标点击、AJAX 异步请求等，但由于 JS 的单线程关系所有这些事件都得排队等待 JS 引擎处理。
5.4.4 定时触发器线程
setInterval 与 setTimeout 所在线程
浏览器定时计数器并不是由 JavaScript 引擎计数的，因为 JavaScript 引擎是单线程的，如果处于阻塞线程状态就会影响记计时的准确。
通过单独线程来计时并触发定时（计时完毕后，添加到事件队列中，等待 JS 引擎空闲后执行）
注意，W3C 在 HTML 标准中规定，规定要求 setTimeout 中低于 4ms 的时间间隔算为 4ms。
5.4.5 异步 http 请求线程
在 XMLHttpRequest 在连接后是通过浏览器新开一个线程请求。
将检测到状态变更时，如果设置有回调函数，异步线程就产生状态变更事件，将这个回调再放入事件队列中，再由 JavaScript 引擎执行。
6. 浏览器的兼容
浏览器的兼容问题一直是一个让人很头痛的问题，前段时间我还在为 qiankun 兼容 IE 弄得焦头烂额。
6.1 为什么我们的代码在浏览器中会出现兼容问题？
因为不同的浏览器对同一段代码有不同的解析，造成页面显示效果不统一的情况。在大多数情况下，我们的需求是，无论用户用什么浏览器来查看我们的网站或者登陆我们的系统，都应该是统一的显示效果。
版本越高的浏览器，支持的特性越多，我们用的某个插件使用的特性可能高版本的浏览器支持，低版本的不支持。
6.2 我们要怎么解决呢？
6.2.1 CSS Hack
在 CSS 方面，我们可以使用 CSS Hack。CSS hack 是通过在 CSS 样式中加入一些特殊的符号也就是浏览器前缀，让不同的浏览器识别不同的符号（什么样的浏览器识别什么样的符号是有标准的，CSS hack 就是让你记住这个标准），以达到应用不同的 CSS 样式的目的。
6.2.2 polyfill
在 JS 方面，我们可以使用 polyfill。polyfill 是一段代码 (或者插件)，提供了那些开发者们希望浏览器原生提供支持的功能。程序库先检查浏览器是否支持某个 API，如果不支持则加载对应的 polyfill。比如，html5 的 storage。不同浏览器，不同版本，有些支持，有些不支持。其实 polyfill 就是 shim 的一种。
Shim 指的是在一个旧的环境中模拟出一个新 API ，而且仅靠旧环境中已有的手段实现，以便所有的浏览
器具有相同的行为。
6.2.3 PostCSS
PostCSS 是一个利用 JS 插件来对 CSS 进行转换的工具，这些插件非常强大，强大到无所不能。其中，Autoprefixer 就是众多 PostCSS 插件中最流行的一个。
Autoprefixer 可以自动帮我们加上浏览器前缀。
6.2.4 Modernizr.js
Modernizr.js 十分的强大，既能给老版本浏览器打补丁，又能保证新浏览器渐进增强的用户体验。
Modernizr 默认做的事情很少，除了（在你选择的情况下）给不支持 html5 的标签的浏览器，如 IE6，7，8 追加一点由 Remy Sharp 开发的 html5 垫片脚本，使其识别
、等 html5 元素之外，它主要做的就是浏览器功能检测。因此，它知道浏览器是否支持各种 html5 和 css3 特性。
最后
从时代发展的角度看，网络安全的知识是学不完的，而且以后要学的会更多，同学们要摆正心态，既然选择入门网络安全，就不能仅仅只是入门程度而已，能力越强机会才越多。
因为入门学习阶段知识点比较杂，所以我讲得比较笼统，大家如果有不懂的地方可以找我咨询，我保证知无不言言无不尽，需要相关资料也可以找我要，我的网盘里一大堆资料都在吃灰呢。
干货主要有：
①1000+CTF历届题库（主流和经典的应该都有了）
②CTF技术文档（最全中文版）
③项目源码（四五十个有趣且经典的练手项目及源码）
④ CTF大赛、web安全、渗透测试方面的视频（适合小白学习）
⑤ 网络安全学习路线图（告别不入流的学习）
⑥ CTF/渗透测试工具镜像文件大全
⑦ 2023密码学/隐身术/PWN技术手册大全
如果你对网络安全入门感兴趣，那么你需要的话可以点击这里👉网络安全重磅福利：入门&进阶全套282G学习资源包免费分享！
扫码领取
扫一扫
5万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
