 问题-概况篇-CSDN博客

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 或者窗口后便于恢复，这些信息会存放在硬盘中。