学习资料:Inside look at modern web browser (part 2)
学习进度跟踪
- 2021.6.27晚 11.05,看到Service Worker前面,有点困,先去洗漱一下
- 2021.6.28晚 22.45,本来想看的,结果google dev doc居然被屏蔽了... 就离谱,只能草草收场
第三部分的学习笔记 传送门:Inside look at modern web browser (part 3)
导航发生了什么
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。于是有了预加载机制,例如请求服务器先发一些数据来,但不是所有数据