[译]深入了解现代web浏览器（二）

本文是根据Mariko Kosaka在谷歌开发者网站上的系列文章https://developer.chrome.com/blog/inside-browser-part2/ 翻译而来，共有四篇，该篇是第二篇。对于其中一些直译出来不太好理解的句子，笔者做了加工处理和提炼。

在导航中发生了什么

在上一篇文章中，我们了解到了不同的进程和线程如何处理浏览器中的各个部分。在这篇文章中，我们将更深入探讨各个进程和线程如何通信以展示出一个网页来。

让我们来看一个简单的浏览网页的场景：当你输入URL后，浏览器从因特网中获取数据并把页面展示出来。在本文中，我们将重点关注用户请求站点和浏览器准备呈现页面的部分——也就是导航。

从浏览器进程开始

如我们在第一篇文章中https://www.cnblogs.com/geek1116/p/16419720.html所述，tab页之外的所有内容都是由浏览器进程处理的。浏览器进程具有诸如渲染按钮和输入框的UI线程、处理网络栈以从因特网中接收数据的网络线程，以及控制文件等内容访问的存储线程；当你向地址栏中输入URL时，就是由浏览器进程的UI线程来处理你的输入。

顶部的浏览器UI，底部是包含UI、网络和存储线程的浏览器进程

一个简单的导航

步骤1：处理输入

当用户在地址栏中输入的时候，UI线程首先需要考虑的是：“输入内容是一个搜索请求还是URL呢？”。在Chrome中，地址栏同时也是搜索输入域，因此UI线程需要解析并决定将输入内容发送到搜索引擎还是你想要请求的站点。

UI线程在判断输入内容是一个搜索请求还是URL

步骤2：开始导航

当用户敲击回车键后，UI线程发起一个网络调用来获取站点内容。在tab栏的一角会显示加载效果，网络线程会查找合适的协议做接下来的事 例如根据DNS查找域名、为请求建立TSL连接。

UI线程通知网络线程导航至mysite.com

此时，网络线程可能会收到HTTP 301之类的服务重定向标头(header)。这种情况下，网络线程会告知UI线程该服务需要请求重定向。接着便会发起另一个URL请求。

步骤3：读取响应

一旦响应主体（有效负载）开始进入，网络线程会在有必要时检查流（stream）的前面几个字节。这是因为：响应头部的Content-Type字段会告知数据的类型，但它可能会丢失或者出错，所以在这里进行MIME 嗅探。如chromium源码注释中所说，这是一项“棘手的业务”；你可以阅读该处的注释并看到不同浏览器是如何处理content-type/payload的。

如果响应是一个HTML类型文件，则会将该数据传递给渲染进程；而如果是一个zip或其他类型文件的话，意味着这是一个下载请求所以需要将该数据传递给下载管理器。

网络线程询问响应数据是否是来自安全站点的HTML文件

↑这里也是进行安全浏览检查的地方。如果响应数据和对应的域（domain）与已知的恶意站点相匹配的话，网络线程会发出警告页面。此外，还会做的一项检查CROB——跨域源读阻止（注意是CROB不是CROS），确保跨域的敏感数据不会到达渲染进程。

步骤4：查找渲染进程

当所有的检查完成并且网络线程确信浏览器应该导航至请求站点后，就会告知UI线程数据已经准备就绪。然后UI线程找出一个渲染进程来进行网页的渲染：

由于网络请求可能需要花费数百毫秒之久来等待响应返回，所以一项加速此过程的优化手段应运而生：当UI线程在上述步骤2中向网络线程发送URL请求时，是已经知道它所要导航的站点的，此时它会在网络请求期间并行地查找或启动一个渲染进程。这样一来，如果一切按预期进行，当网络线程的数据到达时，渲染进程就已经处于就绪状态了。如果导航发生重定向是且跨站点的话，则可能不会使用该就绪进程，这种情况下需要使用另外的进程了。

步骤5：提交导航

现在数据和渲染进程都已经准备好了，浏览器进程会向渲染进程发送一个IPC（第一篇文章中提到的进程间通讯手段）来提交导航。该IPC也会被用来传递数据流(stream)以让渲染进程可以持续接收HTML数据。当浏览器进程收到渲染进程中对导航提交的确认，本次导航就结束了，接着开始HTML文档的加载阶段。

这时候地址栏就被更新了，安全指示器和站点设置UI（地址栏最左侧的

标签：web,浏览器,渲染,线程,UI,进程,深入,导航
来源： https://www.cnblogs.com/geek1116/p/16447969.html