浏览器输入url后的详解

输入URL后浏览器的内部过程

前言： 亲爱的小伙伴们，今天小编为大家带来一篇比较完整的浏览器方面的文章，读本篇文章要求小伙伴们有一些浏览器方面的基础，比如：浏览器的缓存机制，网络方面的DNS解析，三次握手，四次挥手之类的基础性知识。接下来就由我给大家详细的讲解一下输入url后到底发生了什么。

网络

用户输入转换

我们需要在地址栏中输入一个查询关键字时，地址栏会先判断输入的关键字是搜索内容，还是请求的 URL。
如果是搜索内容字，地址栏会使用浏览器默认的搜索引擎，来合成新的搜索关键字的 URL。
如果是符合 URL 规则，那么浏览器会根据规则，加上协议，合并成为完整的 URL。

csdn.net 合并为     https://www.csdn.net

并且在发起真正的 csdn.net 请求之前，浏览器会给当前（即将跳转的页面）一次执行 beforeunload 事件的机会，允许当前页面执行一些清理性的操作，有的也会进行一次询问用户是否要跳转页面的弹框，可以用来取消导航。

构建请求行

GET /index.html HTTP/1.1

浏览器进程会通过进程通信 IPC,把 URL 请求发送至网络进程, 网络进程在收到请求后, 会发起真正的 URL 请求。

查找缓存

浏览器缓存机制篇（关于浏览器缓存机制小编已经为小伙伴们总结好了，想查看的小伙伴们可以去点击查看。）
查找缓存，我想不用解释大家都知道这步操作是干什么的，在查找的时候我们肯定要去看看有没有缓存，有就直接用缓存，没有的话再去发送请求。

DNS解析

由于我们输入的是域名，而数据包是通过IP地址传给对方的，因此我们需要得到域名对应的IP地址。这个过程需要依赖一个服务系统，这个系统将域名和IP一一映射，我们将这个系统叫做DNS（域名系统）。

具体过程如下：

浏览器提供了DNS数据缓存功能，如果一个域名已经解析过了，那么会把解析的结果缓存起来，瑕疵处理直接走缓存，不需要经过DNS解析。

利用IP建立TCP连接

TCP（Transmission Control Protocol，传输控制协议）是一种面向连接的、可靠的、基于字节流的传输层通信协议。
TCP 通过三次握手, 数据包校验、四次挥手 来保证数据传输的可靠性。《橘子猫哥-TCP连接的全过程》

发送HTTP请求

建立好TCP连接，浏览器可以和服务器进行通信，发送HTTP请求。浏览器会向服务器发送请求行、请求头信息，并把和该域相关的 Cookie 等数据附加到请求头中，然后向服务器发送请求信息。这个过程还有一个问题存在 跨域

常见的请求头信息

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3

Accept-Encoding: gzip, deflate, br

Accept-Language: zh-CN,zh;q=0.9

Cache-Control: no-cache

Connection: keep-alive

Cookie: /* 省略cookie信息 */

Host: www.baidu.com

Pragma: no-cache

Upgrade-Insecure-Requests: 1

User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 11_0 like Mac OS X) AppleWebKit/604.1.38 (KHTML, like Gecko) Version/11.0 Mobile/15A372 Safari/604.1

网络响应

服务器接收到请求后，根据请求信息生成响应数据（包含响应行、响应头和响应体等信息），接下来就是解析相应头的内容

常见的响应头

Cache-Control: no-cache

Connection: keep-alive

Content-Encoding: gzip

Content-Type: text/html;charset=utf-8

Date: Wed, 04 Dec 2019 12:29:13 GMT

Server: apache

Set-Cookie: rsv_i=f9a0SIItKqzv7kqgAAgphbGyRts3RwTg%2FLyU3Y5Eh5LwyfOOrAsvdezbay0QqkDqFZ0DfQXby4wXKT8Au8O7ZT9UuMsBq2k; path=/; domain=.baidu.com

响应完成之后怎么办？TCP连接就断开了吗？

这时候要判断 Connection 字段, 如果请求头或响应头中包含 Connection: Keep-Alive ，表示建立了持久连接，这样TCP连接会一直保持，之后请求统一站点的资源会复用这个连接。否则断开TCP连接, 请求-响应流程结束。

解析响应头

• 重定向
  HTTP直接返回HTTP响应数据的状态301或者302同时在请求头的Location字段中附上重定向地址，浏览器会根据 状态码 和 Location 进行重定向操作，然后按照重定向地址按照上面步骤重新发起请求。 如果响应行是 200，那么浏览器将继续处理
• 协商缓存
  如果不是重定向，首先服务器会根据请求头中的If-None-Match 的值来判断请求的资源是否被更新，如果没有更新，就返回 304 状态码, 相当于告诉浏览器之前的缓存还可以使用, 就不返回新数据了，直接获取缓存数据
• 返回数据
  网络进程将获取到的数据包进行解析，根据响应头中的 Content-type 来判断响应数据的类型，如果是字节流类型，就将该请求交给下载管理器，该导航流程结束，不再进行；如果是 text/html 类型，就通知浏览器进程获取到文档准备渲染进程。

准备渲染进程

默认情况下，Chrome 会为每个页面分配一个渲染进程，也就是说，每打开一个新页面就会配套创建一个新的渲染进程。但是，也有一些例外，在同一站点下(同一站点章节)，浏览器会让多个页面直接运行在同一个渲染进程中。渲染进程准备好之后，还不能立即进入文档解析状态，因为此时的文档数据还在网络进程中，并没有提交给渲染进程，所以下一步就进入了 提交文档阶段 。

提交文档阶段

• 首先当浏览器进程接收到网络进程的响应头数据之后，便向渲染进程发起提交文档的消息
• 渲染进程接受到"提交文档"的消息后,会和网络进程建立传输数据管道
• 等文档数据传输完成之后,渲染进程会返回确认提交的消息给浏览器进程
• 浏览器进程在收到"确认提交"的消息后,会更新浏览器界面状态,包括了安全状态,地址栏的URL,前进后退的历史状态,并更新Web界面

解析

渲染流程

通过输入HTML,CSS,JavaScript数据,经过渲染模块的处理,输出为屏幕上的像素
渲染模块在执行过程中会被划分为很多个子阶段。这个处理流程叫做渲染流水线（回流的根本原因就是渲染流水线重复做的事情多）

构建DOM树(结合如何构建DOM树过程)

浏览器无法直接理解和使用HTML,所以需要将HTML转换为浏览器能够理解的结构----DOM树.
构建DOM树的输入内容是一个非常简单的HTML文件,然后经由HTML解析器解析,最终输出树结构的DOM
通过在Chrome开发者工具,通过在Console中输入document来看完整的DOM树结构
DOM 和 HTML 内容几乎是一样的，但是和 HTML 不同的是，DOM 是保存在内存中树状结构，可以通过 JavaScript 来查询或修改其内容。

样式计算

1.关于css样式，来源： link标签， style标签中的样式 ，元素的内嵌style属性
当渲染引擎接收到 CSS 文本时, 会执行一个转换操作，将 CSS 文本转换为浏览器可以理解的结构——styleSheets。
2.转换样式表中的属性值，使其标准化，有一些css样式的数值并不容易被渲染引擎所理解，因此在进行样式计算之前将他们标签化，em -> px , red -> #ff0000 , blod->700等等
3.计算出DOM树中每个节点的具体样式,将样式进行格式化和标签化之后,接下来就是计算每个节点的具体样式信息,涉及到CSS的继承规则和层叠规则

布局计算

在生成了 DOM 树和 DOM 样式，接下来就是通过浏览器的布局系统确定元素的位置，要生成一颗 布局树。
1.创建布局树 DOM 树还含有很多不可见的元素，比如 head 标签，还有使用了 display:none 属性的元素。所以在显示之前，我们还要额外地构建一棵只包含可见元素布局树, 它会遍历生成的 DOM 树节点，把他们添加到 布局树中。
2.布局计算 现在我们有了一棵完整的布局树。那么接下来，就要计算布局树节点的坐标位置了。执行布局操作的时候，会把布局运算的结果重新写回布局树中，所以布局树既是输入内容也是输出内容，这是一个不合理的地方。Chrome团队正在重构布局代码，下一代布局系统叫 LayoutNG，试图更清晰地分离输入和输出，从而让新设计的布局算法更加简单。

渲染

分层

如一些复杂的 3D 变换、页面滚动，或者使用 z-indexing 做 z 轴排序等。 为了更加方便地实现这些效果，渲染引擎还需要为特定的节点生成专用的图层，并生成一棵对应的图层树（LayerTree）。
浏览器的页面实际上被分成了很多图层，这些图层叠加后合成了最终的页面。

提升图层的条件:
1.拥有层叠上下文属性的元素会被提升为单独的一层

• HTML 根元素本身就是具有层叠上下文.
• position值absolute 或 relative, 且z-index为auto
• position值 fixed 或 sticky
• flex容器的子元素，且 z-index 不为 auto
• 元素的 opacity 的值不是 1.
• 元素的 transform 不为 none.
• 元素的 filter 值不是 none。
• will-change 指定的属性值为上面的任意一个。

2.需要裁剪的地方
比如一个div,里面的文字太多,需要被裁剪,渲染引擎会为文字部分单独创建一个层,如果出现滚动条,滚动条会单独提升为一个图层.

图层绘制

接下来渲染引擎会将图层的绘制拆分成一个个绘制指令,比如先画背景,在描述边框,然后将这些指令按照顺序组合成一个待绘制的列表.
查看Chrome的Layers面板,就能够查看绘制列表

栅格化(raster)操作

绘制列表只是用来记录绘制顺序和绘制指令的列表, 而实际上绘制操作是由渲染引擎中的合成线程来完成的.

当图层的绘制列表准备好之后，主线程会把该绘制列表提交（commit）给合成线程.

分块
如果说分层式宏观上的Chrome对生成图片的优化，那么分块就是微观上的优化。

首先，考虑到视口就这么大（用户能够看到的部分），当页面非常大的时候，要滑很长的时间才能够到底，如果一次性全部绘制出来时相当的耗费性能的。因此合成线程会将图层划分为图块，这些块的大小一般不会特别大，通常是 256 * 256 或者 512 * 512 这个规格。这样可以大大加速页面的首屏展示。

显示一个页面时，如果等待所有的图层都生成好之后，在进行合成的话，会产生一些不必要的开销，会让合成图片的时间变的更久, 合成线程会按照视口附近的图块来优先生成位图.

位图
实际生成位图的操作时由栅格化来执行的, 而图块是栅格化执行的最小单位. 渲染进程维护了一个栅格化线程池，所有的图块栅格化都是在线程池内执行的。

通常，栅格化过程都会使用 GPU 来加速生成的，使用 GPU 生成位图的过程叫做快速栅格化，或者 GPU 栅格化，生成的位图被保存在 GPU 内存中。

要使用 GPU，就涉及到跨进程操作，GPU 操作运行在 GPU 进程中。GPU将生成位图，并且保存在 GPU 内存中

小知识点： 考虑到浏览器内存上传到 GPU 内存的操作比较慢，即使是绘制一部分图块，也会耗费大量的时间。针对这个问题，Chrome 采用了一个策略：在首次合成图块时只采用一个低分辨率的图片，这样首屏展示的时候只是展示出低分辨率的拖，这个时候继续进行合成操作，当正常的图块绘制完毕之后，会将当前低分辨率的图块内容替换。这也是 Chrome 底层优化首屏加载速度的一个手段。

合成和显示

一旦所有图块都被光栅化, 合成线程就会生成一个绘制图块的命令—DrawQuad, 然后将该命令提交给浏览器进程。

浏览器进程中的 viz 组件接收到这个命令，根据这个命令，把页面内容绘制到内存，也就是生成了页面，然后把这个内容发送给显卡。

每个显示器都有固定的刷新频率，通常是 60 HZ，每秒更新 60 张图片，更新的图片都是来自于显卡中的前缓冲区的地方。显示器所做的事情，就是每秒固定读取 60 次前缓冲区的图像。并显示到显示器上。

显卡所做的就是合成新的图像，并将图像保存到后缓存区，一旦显卡把合成的图像写到后缓存区，系统就会让后缓冲区和前缓冲区互换，如此循环更新。保证显示器能够读取到最新合成的图像。通常情况下，显卡的更新频率和显示器的刷新频率是一致的。但是有些复杂的场景中，显卡处理一张图片的速度会变慢，导致多次读取的图像是上一次的，就会造成视觉上的卡顿。

到这里，经过这一系列的阶段，编写好的 HTML、CSS、JavaScript 等文件，经过浏览器就会显示出漂亮的页面了。

---

至此url输入的全过程就完结啦~ , 喜欢的同学可以一键三连.
相关文章: 《V8引擎-js执行原理》《TCP连接》