当在浏览器地址栏输入网址，如：www.baidu.com后浏览器是怎么把最终的页面呈现出来的呢？这个过程可以大致分为两个部分：网络通信 和 页面渲染
一、网络通信
众所周知 互联网内各网络设备间的通信都遵循TCP/IP协议，利用TCP/IP协议族进行网络通信时，会通过分层顺序与对方进行通信。分层由高到低分别为：应用层、传输层、网络层、数据链路层。发送端从应用层往下走，接收端从数据链路层网上走。如图所示：
> 1.在浏览器中输入url
用户输入url，例如 <http://www.baidu.com/>。其中http为协议，www.baidu.com为网络地址，及指出需要的资源在那台计算机上。一般网络地址可以为域名或IP地址，此处为域名。使用域名是为了方便记忆，但是为了让计算机理解这个地址还需要把它解析为IP地址。
> 2.应用层DNS解析域名
- 请求发起后，游览器首先会解析这个域名，首先它会查看本地硬盘的 hosts 文件，看看其中有没有和这个域名对应的规则，如果有的话就直接使用 hosts 文件里面的 ip 地址。
- 如果在本地的 hosts 文件没有能够找到对应的 ip 地址，浏览器会发出一个 DNS请求到本地DNS(域名分布系统)服务器 。本地DNS服务器一般都是你的网络接入服务器商提供，比如中国电信，中国移动。
- 查询你输入的网址的DNS请求到达本地DNS服务器之后，本地DNS服务器会首先查询它的缓存记录，如果缓存中有此条记录，就可以直接返回结果，此过程是递归的方式进行查询。如果没有，本地DNS服务器还要向DNS根服务器进行查询
- 根DNS服务器没有记录具体的域名和IP地址的对应关系，而是告诉本地DNS服务器，你可以到域服务器上去继续查询，并给出域服务器的地址。这种过程是迭代的过程
- 本地DNS服务器继续向域服务器发出请求，在这个例子中，请求的对象是.com域服务器。.com域服务器收到请求之后，也不会直接返回域名和IP地址的对应关系，而是告诉本地DNS服务器，你的域名的解析服务器的地址
- 最后，本地DNS服务器向域名的解析服务器发出请求，这时就能收到一个域名和IP地址对应关系，本地DNS服务器不仅要把IP地址返回给用户电脑，还要把这个对应关系保存在缓存中，以备下次别的用户查询时，可以直接返回结果，加快网络访问
> 3. 应用层客户端发送HTTP请求
HTTP请求包括请求报头和请求主体两个部分，其中请求报头包含了至关重要的信息，包括请求的方法（GET / POST）、目标url、遵循的协议（http / https / ftp…），返回的信息是否需要缓存，以及客户端是否发送cookie等。
> 4. 传输层TCP传输报文
位于传输层的TCP协议为传输报文提供可靠的字节流服务。它为了方便传输，将大块的数据分割成以报文段为单位的数据包进行管理，并为它们编号，方便服务器接收时能准确地还原报文信息。TCP协议通过“三次握手”等方法保证传输的安全可靠。
“三次握手”的过程是，发送端先发送一个带有SYN（synchronize）标志的数据包给接收端，在一定的延迟时间内等待接收的回复。接收端收到数据包后，传回一个带有SYN/ACK标志的数据包以示传达确认信息。接收方收到后再发送一个带有ACK标志的数据包给接收端以示握手
成功。在这个过程中，如果发送端在规定延迟时间内没有收到回复则默认接收方没有收到请求，而再次发送，直到收到回复为止。
> 5. 网络层IP协议查询MAC地址
IP协议的作用是把TCP分割好的各种数据包传送给接收方。而要保证确实能传到接收方还需要接收方的MAC地址，也就是物理地址。IP地址和MAC地址是一一对应的关系，一个网络设备的IP地址可以更换，但是MAC地址一般是固定不变的。ARP协议可以将IP地址解析成对应的MAC地址。当通信的双方不在同一个局域网时，需要多次中转才能到达最终的目标，在中转的过程中需要通过下一个中转站的MAC地址来搜索下一个中转目标。
> 6. 数据到达数据链路层
在找到对方的MAC地址后，就将数据发送到数据链路层传输。这时，客户端发送请求的阶段结束
> 7. 服务器接收数据
接收端的服务器在链路层接收到数据包，再层层向上直到应用层。这过程中包括在传输层通过TCP协议讲分段的数据包重新组成原来的HTTP请求报文。
> 8. 服务器响应请求
服务接收到客户端发送的HTTP请求后，查找客户端请求的资源，并返回响应报文，响应报文中包括一个重要的信息——状态码。状态码由三位数字组成，其中比较常见的是200 OK表示请求成功。301表示永久重定向，即请求的资源已经永久转移到新的位置。在返回301状态码的同时，响应报文也会附带重定向的url，客户端接收到后将http请求的url做相应的改变再重新发送。404 not found 表示客户端请求的资源找不到。
服务器端收到请求后的由web服务器（准确说应该是http服务器）处理请求，诸如Apache、Ngnix、IIS等。web服务器解析用户请求，知道了需要调度哪些资源文件，再通过相应的这些资源文件处理用户请求和参数，并调用数据库信息，其中返回的响应报文中包括一个重要的信息——状态码。状态码由三位数字组成，其中比较常见的是200 OK表示请求成功。301表示永久重定向，即请求的资源已经永久转移到新的位置。在返回301状态码的同时，响应报文也会附带重定向的url，客户端接收到后将http请求的url做相应的改变再重新发送。最后将结果通过web服务器返回给浏览器客户端
二、页面渲染
可是浏览器是怎么去解析渲染页面的呢？这里就要涉及到浏览器的内核，也就是浏览器的渲染引擎（严格来说应该是渲染引擎 + Javascript引擎），页面的渲染工作便是由渲染引擎完成的。需要注意浏览器和浏览器内核是不同的概念，浏览器指的是 Chrome、Firefox 等，而浏览器内核未找到图形项目表。则是 Blink、Gecko 等，浏览器内核只负责渲染，GUI 及网络连接等跨平台工作则是浏览器实现的。主流的渲染引擎包括Trident、Gecko、Webkit，它们分别是IE、火狐和Chrome的内核（2013年，Google宣布了Blink内核，它其实是从Webkit复制出去的）。一般渲染引擎主要包括HTML解释器、CSS解释器、Javascript引擎、布局、绘图等模块。当然这些模块还依赖很多其他的基础模块。
我们先简单的了解一下渲染引擎各个主模块所做的工作（以下所有的介绍以 webkit 为介绍对象）
- HTML解释器 ：HTML解释器的工作就是将网络或者本地磁盘获取到的HTML网页和资源从字节流解释成DOM树的结构（首先是字节流，经过解码之后是字符流，然后通过词法分析器会被解释成词语（TOKENS），经过语法分析器构建成节点，最后这些节点被组建成一颗DOM树）
- CSS解释器 ：CSS字符串被CSS解释器处理后变成渲染引擎的内部规则表示。（样式规则建立完成之后，webkit会保存规则结果，当DOM的节点建立之后，webkit会为可视化节点选择合适的样式信息，即作样式规则匹配）
- *Javascript引擎 ：将Javascript代码处理并执行，一个Javascript引擎可以包括以下几个部分 ->
- 编译器 -> 主要工作是将源代码编译成抽象语法树，在某些引擎中还包括将抽象语法树转换为字节码（JavascriptCore 引擎）。
- 解释器 -> 在某些引擎中，解释器主要是接收字节码，解释执行字节码，同时也依赖垃圾回收机制等。
- JIT工具 -> 将字节码或者抽象语法树转换为本地代码 （V8 引擎）
- 垃圾回收器和分析工具
- * 布局(layout) ：计算RenderObject对象的位置、大小等信息
- * 绘图(render) ：将构建好的渲染内部表示模型使用图形库绘制出来
- 页面的最终渲染便是上述模块综合处理的结果。根据数据的流向，这里可以把渲染的过程分为三个阶段，第一个阶段是从网页的url到构建完dom树，第二个阶段是从dom树到构建完webkit的绘图上下文，第三个阶段是从绘图上下文到生成最后的图像。
上图描述的是网页 url 到构建完DOM树的整个过程，数字表示的是基本顺序，不过也不是严格一致，因为这个过程可能会有所重复或者交叉。
具体的过程如下：
- 当用户输入网页url的时候，webkit调用资源加载器加载对应的网页。
- 加载器依赖网络模块建立连接，发生请求并接收响应。
- webkit接收到各种网页或者资源的数据，其中某些资源可能是同步或者异步的方式获取的。
- 网页被交给HTML解释器解释成一系列词语（Token）
- 解释器根据词语构建节点（Node），形成DOM树。
- 如果节点是Javascript代码的话，调用Javascript引擎解释执行。
- Javascript代码可能会修改DOM树的结构。
- 如果有节点需要依赖其他的资源，比如图片、css、视频等，调用资源加载器来加载它们，不过这个过程是异步的，不会阻碍当前DOM树的继续构建。如果是Javascript资源 url （没有标记异步方式），则需要停止当前DOM树的构建，直到Javascript的资源被加载并被Javascript引擎解释执行后才继续DOM树的创建。
- 在上述过程当中，网页在加载和被渲染完毕的这一段过程会相继发出“DOMContent”事件和“onload”事件，分别表示DOM树构建完毕以及DOM树及其所有依赖的资源都加载完毕。一般来说“DOMContent”事件会先于“onload”事件发生。
接下来就是Webkit借助 css 和 dom 树构建RenderObject树直到绘图上下文。
- css文件被css解释器解释为内部表示结果
- css解释器完成工作之后在dom树上附加解释后的样式信息，这就是RenderObject树
- RenderObject节点被创建的同时，webkit会根据网页的层次结构创建RenderLayer树，同时创建一个虚拟的绘图上下文。
RenderObject树的建立并不会导致DOM树被销毁，上述四个内部表示结构直到网页被销毁都一直存在。
最后就是根据绘图上下文来生成最终图像了，这一过程主要依赖2D和3D图形库。
生成过程的简单描述如下图所示：
整个渲染的流程至此便是结束了，从渲染的整个过程中我们也可以发现，原来 CSS、图片、视频等资源的加载是异步的，同 dom 树的构建是并发的，而 Javascript 资源的加载和执行却是同步的，这个过程会阻塞 dom 树的构建，同时当然也会阻碍后续资源（比如图片资源）的下载，因为这时候webkit对需要什么资源一无所知，这导致了资源不能并发下载这一严重的性能问题。（其实对于这样的情况，webkit采取了资源预扫描和预加载的机制来实现资源的并发下载而不被 Javascript 的执行所阻碍，但仍要避免这种情况的出现，因为并不是所有的渲染引擎都做了如此的考虑）。所以从这里我们也可以得到一些关于渲染优化方面的启示：
- 最好把脚本文件放在HTML文件的末尾，这样就不会阻塞 dom 树的构建和资源的并发下载
- 如果非要把脚本文件放在HTML文件的前面，请给 script 标签添加 “async” 属性或者 “defer” 属性。前者表明这是一段可以异步执行的 Javascript 代码，而后者表示在加载完 Javascript 之后延迟到 dom 树构建就绪之后再执行代码。如果同时添加 “async” 和 “defer” ，在同时支持这两个属性的浏览器中 “async” 会覆盖掉 “defer”。需要注意的一点是，如果当前添加 “async” 属性的脚本文件依赖有其他的脚本文件，可能会导致添加 “async” 属性的脚本文件先于依赖脚本执行，即使依赖脚本先于添加 “async” 属性的脚本文件被定义。
------------------------------------------------------------------------------
拓展内容：
如何避免触发回流和重绘
CSS：
1、避免使用table布局。
2、尽可能在DOM树的最末端改变class。
3、避免设置多层内联样式。
4、将动画效果应用到position属性为absolute或fixed的元素上
5、避免使用CSS表达式（例如：calc()）
6、CSS3硬件加速（GPU加速）
JavaScript：
1、避免频繁操作样式，最好一次性重写style属性，或者将样式列表定义为class并一次性更改class属性
2、避免频繁操作DOM，创建一个documentFragment，在它上面应用所有DOM操作，最后再把它添加到文档中
3、也可以先为元素设置display: none，操作结束后再把它显示出来。因为在display属性为none的元素上进行的DOM操作不会引发回流和重绘
4、避免频繁读取会引发回流/重绘的属性，如果确实需要多次使用，就用一个变量缓存起来
5、对具有复杂动画的元素使用绝对定位，使它脱离文档流，否则会引起父元素及后续元素频繁回流
结语
以上是最近总结的一些经典面试题中的必问题，希望大家都能掌握，各位看官看完觉得有帮助的帮忙收藏加关注，感谢大家。
