导航中会出现什么情况
本系列博文由 4 部分组成，本文将重点介绍 Chrome 的内部运作方式，本文为第 2 部分。 在上一篇博文中，我们了解了不同进程和线程如何处理浏览器的不同部分。在这篇博文中，我们将深入探讨每个进程和线程如何通信以显示网站。
我们来看一个简单的网络浏览用例：您在浏览器中输入网址，然后浏览器从互联网提取数据并显示网页。在这篇博文中，我们将重点关注用户请求访问网站，然后浏览器准备呈现网页的部分（也称为导航）。
首先是一个浏览器进程
正如我们在第 1 部分：CPU、GPU、内存和多进程架构中所介绍的，标签页以外的一切都由浏览器进程处理。浏览器进程具有如下线程：用于绘制浏览器的按钮和输入字段的界面线程、负责处理网络堆栈以从互联网接收数据的网络线程、用于控制文件访问的存储线程等。当您在地址栏中输入网址时，输入由浏览器进程的界面线程处理。
简单的导航
第 1 步：处理输入
当用户开始在地址栏中输入内容时，界面线程会问的第一个问题是“这是搜索查询或网址吗？”。在 Chrome 中，地址栏也是一个搜索输入字段，因此界面线程需要解析并决定是将您转到搜索引擎还是您请求的网站。
第 2 步：开始导航
当用户点击 Enter 键时，界面线程会发起网络调用来获取网站内容。标签页的一角会显示“正在加载”旋转图标，并且网络线程会通过适当的协议（例如 DNS 查找）并为请求建立 TLS 连接。
此时，网络线程可能会收到类似于 HTTP 301 的服务器重定向标头。在这种情况下，网络线程会与服务器请求重定向的界面线程通信。然后，系统将发起另一个网址请求。
第 3 步：阅读回复
当响应正文（载荷）开始传入后，网络线程会根据需要查看流的前几个字节。响应的 Content-Type 标头应该会显示具体的数据类型，但由于可能缺失或错误，因此请在此处完成 MIME 类型嗅探。正如源代码中所述，这是一种“棘手的业务”。 您可以阅读相关评论，了解不同浏览器如何处理内容类型/载荷对。
如果响应是 HTML 文件，下一步就是将数据传递给渲染程序进程；但如果它是 ZIP 文件或其他某个文件，则意味着它是一个下载请求，所以它们需要将数据传递给下载管理器。
系统还会在此处进行SafeBrowsing检查。 如果该网域和响应数据似乎与某个已知的恶意网站匹配，则网络线程会发出提醒并显示一个警告页面。此外，系统会进行CCOrigin Cead Clocking (C) 检查，以确保敏感的跨网站数据不会进入渲染程序进程。
第 4 步：查找渲染程序进程
在完成所有检查且网络线程确信浏览器应导航到所请求的网站后，网络线程会告知界面线程数据已准备就绪。然后，界面线程会找到渲染程序进程来继续渲染网页。
由于网络请求可能需要数百毫秒才能收到响应，因此采用了可加快此过程的优化。当界面线程在第 2 步向网络线程发送网址请求时，已经知道要导航到哪个网站。界面线程会尝试主动查找或启动与网络请求并行的渲染程序进程。这样，如果一切按预期进行，渲染器进程在网络线程接收到数据时就已处于待机状态。如果导航跨网站重定向，则可能不会使用此待机进程（在这种情况下，可能需要其他进程）。
第 5 步：提交导航
现在数据和渲染程序进程已准备就绪，浏览器进程会向渲染器进程发送 IPC 以提交导航。它还会传递数据流，以便渲染程序进程可以继续接收 HTML 数据。浏览器进程听到在渲染程序进程中发生提交的确认信息后，导航即告完成，文档加载阶段随即开始。
此时，地址栏会更新，安全指示器和网站设置界面会反映新页面的网站信息。系统会更新该标签页的会话历史记录，以便使用“往返”按钮 逐步跳转到用户刚刚访问过的网站为便于您在关闭标签页或窗口时恢复标签页/会话，系统会将会话历史记录存储在磁盘上。
额外步骤：初始加载完成
提交导航后，渲染器进程会继续加载资源并渲染页面。我们会在下一篇博文中详细介绍这一阶段会发生什么。渲染程序进程“完成”渲染后，会将 IPC 发送回浏览器进程（在网页中的所有帧上触发所有 onload 事件并完成执行后）。此时，界面线程会停止标签页上的加载旋转图标。
我说“finishes”，因为在此之后，客户端 JavaScript 仍然可以加载其他资源并渲染新视图。
导航到其他网站
简单的导航已完成！但是，如果用户再次在地址栏中输入不同的网址，会发生什么情况？浏览器进程会执行相同的步骤来导航到不同的网站。
但在此之前，它需要先确认当前呈现的网站是否关注 beforeunload 事件。
beforeunload 可在您尝试离开此网站或关闭标签页时创建“要离开此网站吗？”提醒。
标签页中的所有内容（包括 JavaScript 代码）均由渲染器进程处理，因此当新的导航请求时，浏览器进程必须检查当前的渲染器进程。
如果导航是从渲染程序进程启动的（例如用户点击链接或客户端 JavaScript 已运行 window.location = "https://newsite.com"），渲染程序进程会先检查 beforeunload 处理程序。接着，执行与浏览器进程发起的导航相同的流程。唯一的区别在于，导航请求是从渲染器进程发送到浏览器进程。
当新导航前往与当前呈现的网站不同的网站时，系统会调用单独的渲染进程来处理新的导航，同时保留当前渲染进程来处理 unload 等事件。如需了解详情，请参阅页面生命周期状态概览以及如何使用 Page Lifecycle API 接入事件。
如果是 Service Worker
此导航过程最近的一项更改是引入了 Service Worker。Service Worker 是一种在应用代码中编写网络代理的方法，可让 Web 开发者更好地控制本地缓存的内容以及何时从网络获取新数据。如果 Service Worker 设置为从缓存加载页面，则无需从网络请求数据。
需要注意的重要部分是，Service Worker 是在渲染程序进程中运行的 JavaScript 代码。但是，当导航请求传入时，浏览器进程如何知道网站有 Service Worker？
注册 Service Worker 后，Service Worker 的作用域将作为参考进行保留（如需详细了解作用域，请参阅 Service Worker 生命周期文章）。导航发生时，网络线程会根据已注册的 Service Worker 作用域检查网域，如果已针对该网址注册了 Service Worker，界面线程会查找渲染程序进程以执行 Service Worker 代码。Service Worker 可以从缓存中加载数据，这样就无需从网络请求数据，也可以从网络请求新资源。
导航预加载
您可以看到，如果 Service Worker 最终决定从网络请求数据，浏览器进程和渲染器进程之间的这种往返可能会导致延迟。Navigation 预加载是一种通过在 Service Worker 启动过程中并行加载资源来加快此过程的机制。它使用标头来标记这些请求，以便服务器决定为这些请求发送不同的内容；例如，只更新数据而不是完整文档。
小结
在这篇博文中，我们介绍了导航期间发生的情况，以及您的 Web 应用代码（例如响应标头和客户端 JavaScript）如何与浏览器互动。了解浏览器从网络获取数据所经历的步骤，可以更轻松地理解导航预加载等 API 的开发原因。在下一篇博文中，我们将深入探讨浏览器如何评估 HTML/CSS/JavaScript 以呈现网页。
您喜欢这个帖子吗？如果您对日后发布的博文有任何疑问或建议，欢迎随时通过下方的评论部分或 Twitter 上的 @kosamari 提出您的想法。