问题-概况篇

2-问题-概况篇

回溯

首先回顾一下咱们的问题：

「在浏览器地址栏中输入 url 到页面展示的短短几秒内浏览器究竟作了什么？」

咱们根据前文的两篇文章，能够知道整个浏览器中的主进程是Browser Process，而进程中会有不一样的线程，因此该进程将不一样的任务交给不一样的线程处理：

• UI thread：控制浏览器上的按钮及输入框
• network thread：处理网络请求，从网上获取数据
• storage thread：控制文件等的访问

解决问题

回到问题自己，这样的操做在浏览器看来能够分为如下几步：

1. 处理输入

UI thread 须要判断用户输入的是 URL 仍是 query。

2. 开始导航

当用户点击回车，UI thread 通知 Network thread 获取网页内容，同时控制 tab 上的 spinner 展现（逆时针），表示正在请求页面。

Network thread 会按照顺序查询 DNS，随后为请求简历 TLS （傳輸層安全性協定：Transport Layer Security）链接。

若是 Network thread 接收到了重定向的请求头如 301，Network thread 会通知 UI thread： 服务器要求重定向了，随后，另外一个 URL 请求会被触发。

3. 读取响应

当请求响应回来，Network thread 会依据文档的 Content-type 及 MIME Type sniffing 判断响应内容的格式。

若是响应内容的格式是 HTML，下一步将会把对应的文档交给 Renderer process，若是是 zip文件或是其它文件，会把相关数据传输给下载管理器。

Safe Browsing 检查也会在此时触发，若是域名或是请求内容匹配到已知的恶意站点，Network thread 会展现一个警告页。此外 CORB 检测也会触发确保敏感数据不会被传递 Renderer process。

4. 查看渲染进程

当上述检查完成，Network thread 确信浏览器能够导航到请求的网页，Network thread 会通知 UI thread 数据已经准备好了，UI thread 会查找到一个 Renderer process进行网页的渲染。

因为网络请求获取响应须要时间，这里其实还存在着一个加速方案。当 UI thread 发送 URL 请求给 network thread 时，浏览器其实已经知道了将要导航到那个站点。UI thread 会并行的预先查找和启动一个渲染进程，若是一切正常，当 network thread 接收到数据时，渲染进程已经准备就绪了，可是若是遇到重定向，准备好的渲染进程也许就不可用了，这时候就须要重启一个新的渲染进程。

5. 确认导航

完成了上述过程，数据和渲染进行都是准备状态，Browser Process 会给 Renderer Process 发送 IPC 消息来确认导航，一旦 Browser Process 收到 renderer process 的渲染确认消息，导航过程结束，页面加载过程开始（ UI thread 通知 tab 的 spinner 展现（顺时针））。

此时，地址栏会更新，展现出新页面的网页信息。history tab 会更新，可经过返回键返回导航来的页面，为了让关闭 tab 或者窗口后便于恢复，这些信息会存放在硬盘中。

6. 额外的步骤

导航被确认，Renderer Processs 会使用相关的资源将页面渲染出来。当 Renderer Process 渲染结束（即触发因此页面的onload事件），会发送 IPC 消息到 Browser Process，而后 UI thread 中止展现 tab 中的 spinner。

固然上面的流程只是网页首帧渲染完成，在此以后，客户端依旧可下载额外的资源渲染出新的视图。

以上就是浏览器对应咱们问题的处理步骤了，是否是从以往回答更多侧重如何查询 DNS 的维度看到了本身的不足哩。

其实系列文章能够在这里结束咯，可总感受仍是将知识仅仅涉及表层（固然面试管够啦~）。因此问了本身一个问题：

Renderer Process 是如何将文档渲染出来的呢？

随便说一下：让咱们前端工程师曾经头疼的不就是浏览器内核吗? （毕竟我作的第一个网站就是用 window XP系统运行的）而浏览器内核就是 Renderer Process！

注：部分图片引自参考文献

下一篇文章

浏览器内核-流程概况