浏览器输入url到页面呈现的全过程

储备知识：

ip（网络层，域名转换ip地址）——> tcp（传输层，一种安全可靠的传输协议，三次握手建立传输通道）——> http（应用层，一种请求-响应协议，前后端交互数据）

大致流程：

1、DNS解析；

2、TCP连接；

3、发送HTTP请求；

4、服务器处理请求并返回HTTP报文；

5、浏览器解析渲染页面；

6、连接结束；

具体过程：

DNS解析：

就是域名到ip地址的转换（同一个网站转换出的ip地址不一定相同（DNS服务器负载均衡，距离就近原则，cdn也是这个原理），但是mac地址一定唯一）。

 

上述图片是查找www.google.com的IP地址过程。首先在本地域名服务器中查询IP地址，如果没有找到的情况下，本地域名服务器会向根域名服务器发送一个请求，如果根域名服务器也不存在该域名时，本地域名会向com顶级域名服务器发送一个请求，依次类推下去。直到最后本地域名服务器得到google的IP地址并把它缓存到本地，供下次查询使用。从上述过程中，可以看出网址的解析是一个从右向左的过程: com -> google.com -> www.google.com。但是你是否发现少了点什么，根域名服务器的解析过程呢？事实上，真正的网址是www.google.com.，并不是我多打了一个.，这个.对应的就是根域名服务器，默认情况下所有的网址的最后一位都是.，既然是默认情况下，为了方便用户，通常都会省略，浏览器在请求DNS的时候会自动加上，所有网址真正的解析过程为: . -> com. -> google.com. -> www.google.com.。

DNS优化：做DNS缓存。DNS存在着多级缓存，从离浏览器的距离排序的话，有以下几种: 浏览器缓存（chrome浏览器输入:chrome://dns/），系统缓存（/etc/hosts文件），路由器缓存，IPS服务器缓存，根域名服务器缓存，顶级域名服务器缓存，主域名服务器缓存。

TCP连接：

为了方便传输，将大块的数据分割成以报文段为单位的数据包进行管理，并为它们编号，方便服务器接收时能准确地还原报文信息。TCP协议通过“三次握手”等方法保证传输的安全可靠。

三次握手：

1. 发送端先发送一个带有SYN（synchronize）标志的数据包给接收端，在一定的延迟时间内等待接收的回复；

2. 接收端收到数据包后，传回一个带有SYN/ACK标志的数据包以示传达确认信息；

3. 接收方收到后再发送一个带有ACK标志的数据包给接收端以示握手成功；

在这个过程中，如果发送端在规定延迟时间内没有收到回复则默认接收方没有收到请求，则再次发送，直到收到回复为止。

发送HTTP请求：

包含三部分：请求行、请求头、请求正文。

服务器处理请求并返回HTTP报文：

包含三部分：状态码、响应报头、响应报文。

浏览器解析渲染页面：

基本流程：解析html以构建dom树->解析CSS生成cssom规则树 ->dom树与cssom规则树合并在一起生成render树（render树不会包含display为none的元素）->布局render树-> 绘制render树（注：这是一个渐进的过程。浏览器不必等到整个 HTML 文档解析完毕，就会开始构建render树和设置布局。在不断接收和处理来自网络的其余内容的同时，浏览器会将部分内容解析并显示出来。）

Reflow（回流）：浏览器要花时间去渲染，当它发现了某个部分发生了变化影响了布局，那就需要倒回去重新渲染。 比如：页面初次渲染；浏览器窗口大小改变，DOM结构变化； render树变化，某些元素的尺寸，未知，内容变了；元素字体大小改变，激活CSS伪类（如：hover）。

Repaint（重绘）：如果只是改变了某个元素的背景颜色，文字颜色等，不影响元素周围或内部布局的属性，将只会引起浏览器的repaint，重画某一部分。

回流一定伴随着重绘，而重绘却可以单独出现，Reflow要比Repaint更花费时间，也就更影响性能。所以在写代码的时候，要尽量避免过多的Reflow。

 

总的来说，浏览器对 HTML 的解析过程不会被 CSS、IMG 等资源的下载阻塞，但脚本的加载和执行会终止 HTML 的解析。这主要是因为 JS 可能会改变 DOM 的结构，或者是 JS 动态加载其他 JS 再改变 DOM 等潜在问题。

显然，尽管浏览器可以并发几个 network 线程下载资源，但如果仅像上述策略这样处理，当解析到 <script> 时，如果文件较大或者延迟较高，可能会发生「脚本独占线程而没有其他资源在下载」的空窗期（idle network）。因此，pre-loader （或者 preload scanner 等叫法）将会在主线程之外，扫描余下的标签，充分利用 network 线程下载其他资源。这种机制可以优化 19% 的加载时长。

了解这个过程的目的：

为了web优化：能不从网络中加载的资源就不从网络中加载，当我们合理使用缓存，将资源放在浏览器端，这是最快的方式。如果资源必须从网络中加载，则要考虑缩短连接时间，即DNS优化部分；减少响应内容大小，即对内容进行压缩。另一方面，如果加载的资源数比较少的话，也可以快速的响应用户。当资源到达浏览器之后，浏览器开始进行解析渲染，浏览器中最耗时的部分就是reflow，所以围绕这一部分就是考虑如何减少reflow的次数。