Inside look at modern web browser (part 2)

导航发生了什么

Part 1介绍浏览器有哪些进程，以及线程的相关知识。Part 2将深挖进程和线程是如何工作，最终展示出网页效果的

考虑一个这样简单的案例：在浏览器中输入URL，浏览器从远端服务器拉取数据并且展现web效果。本文重点关注这个过程的机制

从Browser Process开始

Part 1介绍过，除了tab之外的浏览器内容，都由Browser Process处理。

Browser Process有以下Thread：

• UI thread，用于Draw Buttons 和 User Input
• NetWork thread，处理服务器数据
• Storage thread，处理文件读写

 

一次简单的导航案例 

Step1：处理输入

Chrome的搜索栏和地址栏是同一个field，因此UI thread首先要Parse User Input

Step2：开始导航

当用于敲击Enter，UI thread 初始化NetWork相关的信息，NetWork thread 通过 DNS和TLS之类的协议，请求网页数据

 

Step 3：获取响应

当数据包发送到Network thread时，先根据包头，检查数据格式是否为html，如果是，则将数据传输到Render Process；如果是zip之类的，那就是下载请求

 

 此时在Network thread也在进行浏览器安全确认，如果发现数据要跳转到一个“邪恶的网站”，Network thread会警告危险网站。Cross Origin Read Blocking（CORB）会阻止数据进入Render Process

Step 4 寻找渲染进程

一旦所有的check都pass后，Network thread告诉UI thread，帮我找个Render Process吧！因为UI拿到数据，再去找Render Process是很缓慢的，因此做点预处理工作（提前准备好Render Process）

 

 

Step 5 提交导航

数据都准备好了，Browser Process通过IPC，讲数据传输给Render Process，并请求其帮忙render this page

 

Extra Step:initial load complete

Render Process 渲染 page完成后，通过IPC返回一个回调协议，然后转圈的加载UI就可以消失了。下一个post将会解释在Render Process中发生了什么

 

 

 导航到其他网页

    在导航到其他site的请求被发起的时候，会重复上面的流程。但在此之前会先去确认当前的site-Render Process是否有beforeunload的逻辑（类似在编辑blog的时候，点击chrome右上角的×，则会弹出alter是否要保存之类的information）

 

 假如导航由Render Process发起（例如在tab里面点击了一个link），则Render Process会先去处理beforeunload，Render Process和Browser Process经历相同的流程（问题：是指渲染进程也会去生成Network thread吗？），然后把导航请求发送到Browser Process，再派一个新的Render Process去做一次新的render
 

 

 

In case of Service Worker
    Service Worker是JS Code，并运行在Render Process中。允许程序员有更多的控制，决定缓存的内容，就可以不需要从Browser Process的network thread请求数据。

导航预加载
    导航发生的时候，如果Service Worker最后决定还是让network thread request data，则会造成latency/delay。于是有了预加载机制，例如请求服务器先发一些数据来，但不是所有数据
 

转自《Inside look at modern web browser (part 2)》学习笔记_Conchpeng的博客-CSDN博客