(转载)从输入URL到页面加载的过程

大纲

  • 对知识体系进行一次预评级
  • 为什么说知识体系如此重要?
  • 梳理主干流程
  • 从浏览器接收 url 到开启网络请求线程
    • 多进程的浏览器
    • 多线程的浏览器内核
    • 解析 URL
    • 网络请求都是单独的线程
    • 更多
  • 开启网络线程到发出一个完整的 http 请求
    • DNS 查询得到 IP
    • tcp/ip 请求
    • 五层因特网协议栈
  • 从服务器接收到请求到对应后台接收到请求
    • 负载均衡
    • 后台的处理
  • 后台和前台的 http 交互
    • http 报文结构
    • cookie 以及优化
    • gzip 压缩
    • 长连接与短连接
    • http 2.0
    • https
  • 单独拎出来的缓存问题,http 的缓存
    • 强缓存与弱缓存
    • 缓存头部简述
    • 头部的区别
  • 解析页面流程
    • 流程简述
    • HTML 解析,构建 DOM
    • 生成 CSS 规则
    • 构建渲染树
    • 渲染
    • 了解层
    • Chrome 中的调试
    • 资源外链的下载
    • loaded 和 domcontentloaded
  • CSS 的可视化格式模型
    • 包含块(Containing Block)
    • 控制框(Controlling Box)
    • 盒模型
    • BFC(Block Formatting Context)
    • IFC(Inline Formatting Context)
    • 其它
  • JS 引擎解析过程
    • JS 的解释阶段
    • JS 的预处理阶段
    • JS 的执行阶段
    • 回收机制
  • 其它
  • 总结

对知识体系进行一次预评级

看到这道题目,不借助搜索引擎,自己的心里是否有一个答案?

这里,以目前的经验(了解过一些处于不同阶段的相关前端人员的情况),大概有以下几种情况:(以下都是以点见面,实际上不同阶段人员一般都会有其它的隐藏知识点的)

level1

完全没什么概念的,支支吾吾的回答,一般就是这种水平(大致形象点描述):

  • 浏览器发起请求,服务端返回数据,然后前端解析成网页,执行脚本。。。

这类人员一般都是:

  • 萌新(刚接触前端的,包括 0-6 个月都有可能有这种回答)
  • 沉淀人员(就是那种可能已经接触了前端几年,但是仍然处于初级阶段的那种。。。)

当然了,后者一般还会偶尔提下http、后台、浏览器渲染,js引擎等等关键字,但基本都是一详细的问就不知道了。。。

level2

已经有初步概念,但是可能没有完整梳理过,导致无法形成一个完整的体系,或者是很多细节都不会展开,大概是这样子的:(可能符合若干条)

  • 知道浏览器输入 url 后会有 http 请求这个概念
  • 有后台这个概念,大致知道前后端的交互,知道前后端靠 http 报文通信
  • 知道浏览器接收到数据后会进行解析,有一定概念,但是具体流程不熟悉(如 render 树构建流程,layout、paint,复合层与简单层,常用优化方案等不是很熟悉)
  • 对于 js 引擎的解析流程有一定概念,但是细节不熟悉(如具体的形参,函数,变量提升,执行上下文以及 VO、AO、作用域链,回收机制等概念不是很熟悉)
  • 如可能知道一些 http 规范初步概念,但是不熟悉(如 http 报文结构,常用头部,缓存机制,http2.0,https 等特性,跨域与 web 安全等不是很熟悉)

到这里,看到这上面一大堆的概念后,心里应该也会有点底了。。。

实际上,大部分的前端人员可能都处于 level2,但是,跳出这个阶段并不容易,一般需要积累,不断学习,才能水到渠成。

这类人员一般都是:

  • 工作 1-3 年左右的普通人员(占大多数,而且大多数人员工作 3 年左右并没有实质上的提升)
  • 工作 3 年以上的老人(这部分人大多都业务十分娴熟,一个当好几个用,但是,基础比较薄弱,可能没有尝试写过框架、组件、脚手架等)

大部分的初中级都陷在这个阶段,如果要突破,不断学习,积累,自然能水到渠成,打通任督二脉。

level3

基本能到这一步的,不是高阶就是接近高阶,因为很多概念并不是靠背就能理解的,而要理解这么多,需形成体系,一般都需要积累,非一日之功。

一般包括什么样的回答呢?(这里就以自己的简略回答进行举例),一般这个阶段的人员都会符合若干条(不一定全部,当然可能还有些是这里遗漏的):

  • 首先略去那些键盘输入、和操作系统交互、以及屏幕显示原理、网卡等硬件交互之类的(前端向中,很多硬件原理暂时略去。。。)
  • 对浏览器模型有整体概念,知道浏览器是多进程的,浏览器内核是多线程的,清楚进程与线程之间得区别,以及输入 url 后会开一个新的网络线程
  • 对从开启网络线程到发出一个完整的 http 请求中间的过程有所了解(如 dns 查询,tcp/ip 链接,五层因特网协议栈等等,以及一些优化方案,如 dns-prefetch)
  • 对从服务器接收到请求到对应后台接收到请求有一定了解(如负载均衡,安全拦截以及后台代码处理等)
  • 对后台和前台的 http 交互熟悉(包括 http 报文结构,场景头部,cookie,跨域,web 安全,http 缓存,http2.0,https 等)
  • 对浏览器接收到 http 数据包后的解析流程熟悉(包括解析 html,词法分析然后解析成 dom 树、解析 css 生成 css 规则树、合并成 render 树,然后 layout、painting 渲染、里面可能还包括复合图层的合成、GPU 绘制、外链处理、加载顺序等)
  • 对 JS 引擎解析过程熟悉(包括 JS 的解释,预处理,执行上下文,VO,作用域链,this,回收机制等)

可以看到,上述包括了一大堆的概念,仅仅是偏前端向,而且没有详细展开,就已经如此之多的概念了,所以,个人认为如果没有自己的见解,没有形成自己的知识体系,仅仅是看看,背背是没用的,过一段时间就会忘光了。

再说下一般这个阶段的都可能是什么样的人吧。(不一定准确,这里主要是靠少部分现实以及大部分推测得出)

  • 工作 2 年以上的前端(基本上如果按正常进度的话,至少接触前端两年左右才会开始走向高阶,当然,现在很多都是上学时就开始学了的,还有部分是天赋异禀,不好预估。。。)
  • 或者是已经十分熟悉其它某门语言,再转前端的人(基本上是很快就可以将前端水准提升上去)

一般符合这个条件的都会有各种隐藏属性(如看过各大框架、组件的源码,写过自己的组件、框架、脚手架,做过大型项目,整理过若干精品博文等)

level4

由于本人层次尚未达到,所以大致说下自己的见解吧。

一般这个层次,很多大佬都并不仅仅是某个技术栈了,而是成为了技术专家,技术 leader 之类的角色。所以仅仅是回答某个技术问题已经无法看出水准了, 可能更多的要看架构,整体把控,大型工程构建能力等等

不过,对于某些执着于技术的大佬,大概会有一些回答吧:(猜的)

  • 从键盘谈起到系统交互,从浏览器到 CPU,从调度机制到系统内核,从数据请求到二进制、汇编,从 GPU 绘图到 LCD 显示,然后再分析系统底层的进程、内存等等

总之,从软件到硬件,到材料,到分子,原子,量子,薛定谔的猫,人类起源,宇宙大爆炸,平行宇宙?感觉都毫无违和感。。。

这点可以参考下本题的原始出处:查阅

为什么说知识体系如此重要

为什么说知识体系如此重要呢?这里举几个例子

假设有被问到这样一道题目(随意想到的一个):

  • 如何理解getComputedStyle

在尚未梳理知识体系前,大概会这样回答:

  • 普通版本:getComputedStyle会获取当前元素所有最终使用的 CSS 属性值(最终计算后的结果),通过window.getComputedStyle等价于document.defaultView.getComputedStyle调用
  • 详细版本:window.getComputedStyle(elem, null).getPropertyValue("height")可能的值为100px,而且,就算是 css 上写的是inheritgetComputedStyle也会把它最终计算出来的。不过注意,如果元素的背景色透明,那么getComputedStyle获取出来的就是透明的这个背景(因为透明本身也是有效的),而不会是父节点的背景。所以它不一定是最终显示的颜色。

就这个 API 来说,上述的回答已经比较全面了。

但是,其实它是可以继续延伸的。

譬如现在会这样回答:

  • getComputedStyle会获取当前元素所有最终使用的 CSS 属性值,window.document.defaultView.等价
  • getComputedStyle会引起回流,因为它需要获取祖先节点的一些信息进行计算(譬如宽高等),所以用的时候慎用,回流会引起性能问题。然后合适的话会将话题引导回流,重绘,浏览器渲染原理等等。当然也可以列举一些其它会引发回流的操作,如offsetXXX,scrollXXX,clientXXX,currentStyle等等

再举一个例子:

  • visibility: hiddendisplay: none的区别

可以如下回答:

  • 普通回答,一个隐藏,但占据位置,一个隐藏,不占据位置
  • 进一步,display 由于隐藏后不占据位置,所以造成了 dom 树的改变,会引发回流,代价较大
  • 再进一步,当一个页面某个元素经常需要切换display时如何优化,一般会用复合层优化,或者要求低一点用absolute让其脱离普通文档流也行。然后可以将话题引到普通文档流,absolute文档流,复合图层的区别,
  • 再进一步可以描述下浏览器渲染原理以及复合图层和普通图层的绘制区别(复合图层单独分配资源,独立绘制,性能提升,但是不能过多,还有隐式合成等等)

上面这些大概就是知识系统化后的回答,会更全面,容易由浅入深,而且一有机会就可以往更底层挖

前端向知识的重点

此部分的内容是站在个人视角分析的,并不是说就一定是正确答案

首先明确,计算机方面的知识是可以无穷无尽的挖的,而本文的重点是梳理前端向的重点知识

对于前端向(这里可能没有提到node.js之类的,更多的是指客户端前端),这里将知识点按重要程度划分成以下几大类:

  • 核心知识,必须掌握的,也是最基础的,譬如浏览器模型,渲染原理,JS 解析过程,JS 运行机制等,作为骨架来承载知识体系
  • 重点知识,往往每一块都是一个知识点,而且这些知识点都很重要,譬如 http 相关,web 安全相关,跨域处理等
  • 拓展知识,这一块可能更多的是了解,稍微实践过,但是认识上可能没有上面那么深刻,譬如五层因特网协议栈,hybrid 模式,移动原生开发,后台相关等等(当然,在不同领域,可能有某些知识就上升到重点知识层次了,譬如 hybrid 开发时,懂原生开发是很重要的)

为什么要按上面这种方式划分?

这大概与个人的技术成长有关。

记得最开始学前端知识时,是一点一点的积累,一个知识点一个知识点的攻克。

就这样,虽然在很长一段时间内积累了不少的知识,但是,总是无法将它串联到一起。每次梳理时都是很分散的,无法保持思路连贯性。

直到后来,在将浏览器渲染原理JS运行机制JS引擎解析流程梳理一遍后,感觉就跟打通了任督二脉一样,有了一个整体的架构,以前的知识点都连贯起来了。

梳理出了一个知识体系,以后就算再学新的知识,也会尽量往这个体系上靠拢,环环相扣,更容易理解,也更不容易遗忘。

梳理主干流程

回到这道题上,如何回答呢?先梳理一个骨架

知识体系中,最重要的是骨架,脉络。有了骨架后,才方便填充细节。所以,先梳理下主干流程

  1. 从浏览器接收 url 到开启网络请求线程(这一部分可以展开浏览器的机制以及进程与线程之间的关系)
  2. 开启网络线程到发出一个完整的 http 请求(这一部分涉及到 dns 查询,tcp/ip 请求,五层因特网协议栈等知识)
  3. 从服务器接收到请求到对应后台接收到请求(这一部分可能涉及到负载均衡,安全拦截以及后台内部的处理等等)
  4. 后台和前台的 http 交互(这一部分包括 http 头部、响应码、报文结构、cookie 等知识,可以提下静态资源的 cookie 优化,以及编码解码,如 gzip 压缩等)
  5. 单独拎出来的缓存问题,http 的缓存(这部分包括 http 缓存头部,etag,catch-control 等)
  6. 浏览器接收到 http 数据包后的解析流程(解析 html-词法分析然后解析成 dom 树、解析 css 生成 css 规则树、合并成 render 树,然后 layout、painting 渲染、复合图层的合成、GPU 绘制、外链资源的处理、loaded 和 domcontentloaded 等)
  7. CSS 的可视化格式模型(元素的渲染规则,如包含块,控制框,BFC,IFC 等概念)
  8. JS 引擎解析过程(JS 的解释阶段,预处理阶段,执行阶段生成执行上下文,VO,作用域链、回收机制等等)
  9. 其它(可以拓展不同的知识模块,如跨域,web 安全,hybrid 模式等等内容)

梳理出主干骨架,然后就需要往骨架上填充细节内容。

从浏览器接收 url 到开启网络请求线程

这一部分展开的内容是:浏览器进程/线程模型JS引擎的运行机制

多进程的浏览器

浏览器是多进程的,有一个主控进程,以及每一个 tab 页面都会新开一个进程(某些情况下多个 tab 会合并进程)

进程可能包括主控进程,插件进程,GPU,tab 页(浏览器内核)等等

  • Browser 进程:浏览器的主进程(负责协调、主控),只有一个
  • 第三方插件进程:每种类型的插件对应一个进程,仅当使用该插件时才创建
  • GPU 进程:最多一个,用于 3D 绘制
  • 浏览器渲染进程(内核):默认每个 Tab 页面一个进程,互不影响,控制页面渲染,脚本执行,事件处理等(有时候会优化,如多个空白 tab 会合并成一个进程)

多进程的浏览器

多线程的浏览器内核

每一个 tab 页面可以看作是浏览器内核进程,然后这个进程是多线程的,它有几大类子线程

  • GUI 线程
  • JS 引擎线程
  • 事件触发线程
  • 定时器线程
  • 网络请求线程

多线程的浏览器内核

可以看到,里面的 JS 引擎是内核进程中的一个线程,这也是为什么常说 JS 引擎是单线程的,JS 引擎的运行机制查阅

解析 URL

输入 URL 后,会进行解析(URL 的本质就是统一资源定位符)

URL 一般包括几大部分:

  • protocol,协议头,譬如有 http,ftp 等
  • host,主机域名或 IP 地址
  • port,端口号
  • path,目录路径
  • query,即查询参数
  • fragment,即#后的 hash 值,一般用来定位到某个位置

网络请求都是单独的线程

每次网络请求时都需要开辟单独的线程进行,譬如如果 URL 解析到 http 协议,就会新建一个网络线程去处理资源下载

因此浏览器会根据解析出得协议,开辟一个网络线程,前往请求资源(这里,暂时理解为是浏览器内核开辟的,如有错误,后续修复)

开启网络线程到发出一个完整的 http 请求

这一部分主要内容包括:dns查询tcp/ip请求构建七层因特网协议栈(ISO)等等

仍然是先梳理主干,有些详细的过程不展开(因为展开的话内容过多)

DNS 查询得到 IP

如果输入的是域名,需要进行 dns 解析成 IP,大致流程:

  • 如果浏览器有缓存,直接使用浏览器缓存,否则使用本机缓存,再没有的话就是用host
  • 如果本地没有,就向 dns 域名服务器查询(当然,中间可能还会经过路由,也有缓存等),查询到对应的 IP

注意,域名查询时有可能是经过了 CDN 调度器的(如果有 cdn 存储功能的话)

而且,需要知道 dns 解析是很耗时的,因此如果解析域名过多,会让首屏加载变得过慢,可以考虑dns-prefetch优化

这一块可以深入展开,具体请去网上搜索,这里就不占篇幅了(网上可以看到很详细的解答)

tcp/ip 请求

http的本质就是tcp/ip请求,tcphttp长报文划分为短报文,通过三次握手与服务端建立连接,进行可靠传输。

然后,待到断开连接时,由于 TCP 连接是全双工的,因此每个方向都必须单独进行关闭。这原则是当一方完成它的数据发送任务后就能发送一个FIN来终止这个方向的连接。收到一个FIN只意味着这一方向上没有数据流动,一个 TCP 连接在收到一个FIN后仍能发送数据。首先进行关闭的一方将执行主动关闭,而另一方执行被动关闭

HTTP 与 TCP/IP 区别

  • TPC/IP 协议是传输层协议,主要解决数据如何在网络中传输
  • HTTP 是应用层协议,主要解决如何包装数据
  • WEB 使用 HTTP 协议作应用层协议,以封装 HTTP 文本信息,然后使用 TCP/IP 做传输层协议将它发到网络上。

名词解释

  • SYN(synchronous 建立联机)同步序列号
  • ACK(acknowledgement 确认)应答码
  • PSH(push 传送)
  • FIN(finish 结束)
  • RST(reset 重置)
  • URG(urgent 紧急)
  • Sequence number(seq 顺序号码) 对方上次的 ack(首次发送时 seq 为系统随机生成)
  • Acknowledge number(ack 确认号码)对方的 seq+1(无数据传输时) 或者 seq+L(报文数据的长度 L)

TCP通信握手图解

三次握手的步骤

  1. 客户端发送SYN包(SYN=1,seq=x,x 为随机数)的数据包到服务器,并进入SYN_SEND状态,等待服务器确认
  2. 服务器收到SYN包,发现 SYN=1 知客户端想请求连接,然后需要确认客户的SYN包(ACK number=x+1,ACK 位码=1),同时自己也发送一个SYN包(seq=y),即SYN+ACK包,此时服务器进入SYN_RECV状态
  3. 客户端收到服务器的SYN+ACK包,发现ACK number=x+1,ACK位码=1的话, 就向服务器发送确认包ACK(ACK number=y+1,ACK 位码=1),此包发送完毕,客户端和服务器进入ESTABLISHED状态,完成三次握手

建立连接成功后,接下来就正式传输数据。

四次挥手的步骤

  1. 主动关闭方发送一个FIN包,用来关闭主动方到被动方的数据传送
  2. 被动方收到FIN包后,发送一个ACK给对方,确认序号为收到序号+1
  3. 被动方发送一个FIN包,用来关闭被动方到主动方的数据传送
  4. 主动方收到FIN包后,发送一个ACK给被动关闭方,确认序号为收到序号+1

注:2,3 次挥手不会一起发送,当Server端收到FIN报文时,很可能并不会立即关闭 SOCKET,所以只能先回复一个ACK报文,告诉Client端,”你发的FIN报文我收到了”。只有等到我Server端所有的报文都发送完了,我才能发送FIN报文,因此不能一起发送。

tcp/ip 的并发限制

HTTP/1.0 中,一个服务器在发送完一个 HTTP 响应后,会断开 TCP 链接。但是这样每次请求都会重新建立和断开 TCP 连接,代价过大。

所以 HTTP/1.1 就把 Connection 头写进标准(Connection: keep-alive),并且默认开启持久连接,除非请求中写明 Connection: close,那么浏览器和服务器之间是会维持一段时间的 TCP 连接,不会一个请求结束就断掉,这样 SSL 的开销也可以避免。 在 chrome 浏览器里通过 network 标签 -> connection ID表示TCP连接的重用

HTTP/1.1中,单个 TCP连接 在同一时刻只能处理一个请求,顺序处理多个请求; 在 HTTP2 中由于 Multiplexing 特点的存在,多个 HTTP 请求 可以在同一个 TCP 连接 中并行进行。

浏览器对同一域名下并发的 tcp 连接是有限制的(2-10 个不等),Chrome 最多允许对同一个 Host 建立六个 TCP 连接。

get 和 post 的区别

get 方法的含义是请求从服务器获取资源,这个资源可以是静态的文本、页面、图片视频等。

post 方法则是相反操作,它向 URI 指定的资源提交数据,数据就放在报文的 body 里。

get 方法就是安全且幂等,post 则不是.

getpost虽然本质都是tcp/ip,但两者除了在http层面外,在tcp/ip层面也有区别,get会产生一个tcp数据包,post两个。

具体就是:

  • get请求时,浏览器会把headersdata一起发送出去,服务器响应 200(返回数据),
  • post请求时,浏览器先发送headers,服务器响应100 continue, 浏览器再发送data,服务器响应 200(返回数据)。

再说一点,这里的区别是specification(规范)层面,而不是implementation(对规范的实现)

TCP/UDP 的区别

  • TCP 是面向连接的,UDP 是面向无连接的。TCP 在通信之前必须通过三次握手机制与对方建立连接,而 UDP 通信不必与对方建立连接,不管对方的状态就直接把数据发送给对方
  • TCP 连接过程耗时,UDP 不耗时
  • TCP 连接过程中出现的延时增加了被攻击的可能,安全性不高,而 UDP 不需要连接,安全性较高
  • TCP 是可靠的,保证数据传输的正确性,不易丢包;UDP 是不可靠的,易丢包
  • TCP 传输速率较慢,实时性差,udp 传输速率较快。tcp 建立连接需要耗时,并且 tcp 首部信息太多,每次传输的有用信息较少,实时性差
  • TCP 是流模式,udp 是数据包模式。tcp 只要不超过缓冲区的大小就可以连续发送数据到缓冲区上,接收端只要缓冲区上有数据就可以读取,可以一次读取多个数据包,而 udp 一次只能读取一个数据包,数据包之间独立

TCP 可靠性的六大手段

  • 顺序编号:tcp 在传输文件的时候,会将文件拆分为多个 tcp 数据包,每个装满的数据包大小大约在 1k 左右,tcp 协议为保证可靠传输,会将这些数据包顺序编号
  • 确认机制:当数据包成功的被发送方发送给接收方,接收方会根据 tcp 协议反馈给发送方一个成功接收的 ACK 信号,信号中包含了当前包的序号
  • 超时重传:当发送方发送数据包给接收方时,会为每一个数据包设置一个定时器,当在设定的时间内,发送方仍没有收到接收方的 ACK 信号,会再次发送该数据包,直到收到接收方的 ACK 信号或者连接已断开
  • 校验信息:tcp 首部校验信息较多,udp 首部校验信息较少
  • 流量控制:如果发送者发送数据过快,接收者来不及接收,那么就会有分组丢失。为了避免分组丢失,控制发送者的发送速度,使得接收者来得及接收,这就是流量控制。由滑动窗口协议(连续 ARQ 协议)实现。滑动窗口协议既保证了分组无差错、有序接收,也实现了流量控制。主要的方式就是接收方返回的 ACK 中会包含自己的接收窗口的大小,并且利用大小来控制发送方的数据发送。()
  • 拥塞控制:拥塞控制是作用于网络的,它是防止过多的数据注入到网络中,避免出现网络负载过大的情况;常用的方法就是:( 1 )慢开始、拥塞避免( 2 )快重传、快恢复。

七层因特网协议栈(ISO)

五层因特网协议栈

从客户端发出 http 请求到服务器接收,中间会经过一系列的流程。

简括就是:从应用层的发送 http 请求,到传输层通过三次握手建立 tcp/ip 连接,再到网络层的 ip 寻址,再到数据链路层的封装成帧,最后到物理层的利用物理介质传输。

当然,服务端的接收就是反过来的步骤。

七层因特网协议栈其实就是:

  1. 应用层(http,ftp) 这一层为操作系统或网络应用程序提供访问网络服务的接口,如 DNS 解析成 IP 并发送 http 请求
  2. 表示层(Telnet,SNMP) 主要处理两个通信系统中交换信息的表示方式,包括数据格式交换,数据加密与解密,数据压缩与终端类型转换等
  3. 会话层(dns,SMTP) 这一层管理主机之间的会话进程,即负责建立、管理、终止进程之间的会话,如控制登陆和注销过程。 (QoS)
  4. 传输层(tcp,udp) 建立 tcp 连接(三次握手),数据的单位称为数据段(segment)(四层交换机)
  5. 网络层(IP,ARP) IP 寻址,数据的单位称为数据包(packet)(路由器、三层交换机)
  6. 数据链路层(PPP) 将 bit 流封装成 frame 帧(网桥、二层交换机)
  7. 物理层(传输 bit 流) 物理传输(然后传输的时候通过双绞线、电磁波、光纤、中继器和集线器 & RJ-45(网线接口)等各种介质)

从服务器接收到请求到对应后台接收到请求

服务端在接收到请求时,内部会进行很多的处理

这里由于不是专业的后端分析,所以只是简单的介绍下,不深入

负载均衡

对于大型的项目,由于并发访问量很大,所以往往一台服务器是吃不消的,所以一般会有若干台服务器组成一个集群,然后配合反向代理实现负载均衡

当然了,负载均衡不止这一种实现方式,这里不深入…

简单的说:用户发起的请求都指向调度服务器(反向代理服务器,譬如安装了 nginx 控制负载均衡),然后调度服务器根据实际的调度算法,分配不同的请求给对应集群中的服务器执行,然后调度器等待实际服务器的 HTTP 响应,并将它反馈给用户

后台的处理

一般后台都是部署到容器中的,所以一般为:

  • 先是容器接受到请求(如 tomcat 容器)
  • 然后对应容器中的后台程序接收到请求(如 java 程序)
  • 然后就是后台会有自己的统一处理,处理完后响应响应结果

概括下:

  • 一般有的后端是有统一的验证的,如安全拦截,跨域验证
  • 如果这一步不符合规则,就直接返回了相应的 http 报文(如拒绝请求等)
  • 然后当验证通过后,才会进入实际的后台代码,此时是程序接收到请求,然后执行(譬如查询数据库,大量计算等等)
  • 等程序执行完毕后,就会返回一个 http 响应包(一般这一步也会经过多层封装)
  • 然后就是将这个包从后端发送到前端,完成交互

后台和前台的 http 交互

前后端交互时,http(超文本传输协议,HyperText Transfer Protocol) 报文作为信息的载体,所以 http 是一块很重要的内容,这一部分重点介绍它。

HTTP 是一个在计算机世界里专门在「两点」之间「传输」文字、图片、音频、视频等「超文本」数据的「约定和规范」。

http 特性

HTTP 最凸出的优点是 简单、灵活和易于扩展、应用广泛和跨平台

HTTP 最大双刃剑是 无状态、明文传输

HTTP 最大缺点是 不安全

http 工作流程

  1. 地址解析
  2. 封装 HTTP 请求数据包
  3. 封装成 TCP 包,建立 TCP 连接(TCP 的三次握手)
  4. 客户机发送请求命令
  5. 服务器响应
  6. 服务器关闭 TCP 连接

客户机发起一次请求的时候:

客户机会将请求封装成 http 数据包–>封装成 Tcp 数据包–>封装成 Ip 数据包—>封装成数据帧—>硬件将帧数据转换成 bit 流(二进制数据)–>最后通过物理硬件(网卡芯片)发送到指定地点。

服务器硬件首先收到 bit 流……. 然后转换成 ip 数据包。于是通过 ip 协议解析 Ip 数据包,然后又发现里面是 tcp 数据包,就通过 tcp 协议解析 Tcp 数据包,接着发现是 http 数据包通过 http 协议再解析 http 数据包得到数据。

http 报文结构

报文一般包括了:通用头部(General)请求/响应头部请求/响应体

通用头部

这也是开发人员见过的最多的信息,包括如下:

  • Request Url: 请求的 web 服务器地址
  • Request Method: 请求方式(Get、POST、OPTIONS、PUT、HEAD、DELETE、CONNECT、TRACE)
  • Status Code: 请求的返回状态码,如 200 代表成功
  • Remote Address: 请求的远程服务器地址(会转为 IP)
  • Referrer-Policy: 控制请求头中 referrer 的内容查阅

譬如,在跨域拒绝时,可能是methodoptions,状态码为404/405等(当然,实际上可能的组合有很多)

其中,Method的话一般分为两批次:

  • HTTP1.0定义了三种请求方法:GET, POST 和 HEAD方法。以及几种Additional Request Methods:PUT、DELETE、LINK、UNLINK
  • HTTP1.1定义了八种请求方法:GET、POST、HEAD、OPTIONS, PUT, DELETE, TRACE 和 CONNECT 方法。

这里面最常用到的就是状态码,很多时候都是通过状态码来判断,如(列举几个最常见的):

  • 200——表明该请求被成功地完成,所请求的资源发送回客户端
  • 304——自从上次请求后,请求的网页未修改过,请客户端使用本地缓存
  • 400——客户端请求有错(譬如可以是安全模块拦截)
  • 401——请求未经授权
  • 403——禁止访问(譬如可以是未登录时禁止)
  • 404——资源未找到
  • 500——服务器内部错误
  • 503——服务不可用

再列举下大致不同范围状态的意义

  • 1xx——指示信息,表示请求已接收,继续处理
  • 2xx——成功,表示请求已被成功接收、理解、接受
  • 3xx——重定向,要完成请求必须进行更进一步的操作
  • 4xx——客户端错误,请求有语法错误或请求无法实现
  • 5xx——服务器端错误,服务器未能实现合法的请求

http status

总之,当请求出错时,状态码能帮助快速定位问题,完整版本的状态可以自行去互联网搜索

请求/响应头部

请求和响应头部也是分析时常用到的

常用的请求头部(部分):

  • Accept: 接收类型,表示浏览器支持的 MIME 类型(对标服务端返回的 Content-Type)
  • Accept-Encoding:浏览器支持的压缩类型,如 gzip 等,超出类型不能接收
  • Content-Type:客户端发送出去实体内容的类型
  • Cache-Control: 指定请求和响应遵循的缓存机制,如 no-cache
  • If-Modified-Since:对应服务端的 Last-Modified,用来匹配看文件是否变动,只能精确到 1s 之内,http1.0 中
  • Expires:缓存控制,在这个时间内不会请求,直接使用缓存,http1.0,而且是服务端时间
  • Max-age:代表资源在本地缓存多少秒,有效时间内不会请求,而是使用缓存,http1.1 中
  • If-None-Match:对应服务端的 ETag,用来匹配文件内容是否改变(非常精确),http1.1 中
  • Cookie: 有 cookie 并且同域访问时会自动带上
  • Connection: 当浏览器与服务器通信时对于长连接如何进行处理,如 keep-alive
  • Host:请求的服务器 URL
  • Origin:最初的请求是从哪里发起的(只会精确到端口),Origin 比 Referer 更尊重隐私
  • Referer:该页面的来源 URL(适用于所有类型的请求,会精确到详细页面地址,csrf 拦截常用到这个字段)
  • User-Agent:用户客户端的一些必要信息,如 UA 头部等

常用的响应头部(部分):

  • Access-Control-Allow-Headers: 服务器端允许的请求 Headers
  • Access-Control-Allow-Methods: 服务器端允许的请求方法
  • Access-Control-Allow-Origin: 服务器端允许的请求 Origin 头部(譬如为*)
  • Content-Type:服务端返回的实体内容的类型
  • Content-Length:表明本次回应的数据长度
  • Content-Encoding:表示服务器返回的数据使用了什么压缩格式
  • Date:数据从服务器发送的时间
  • Cache-Control:告诉浏览器或其他客户,什么环境可以安全的缓存文档
  • Last-Modified:请求资源的最后修改时间
  • Expires:应该在什么时候认为文档已经过期,从而不再缓存它
  • Max-age:客户端的本地资源应该缓存多少秒,开启了 Cache-Control 后有效
  • ETag:请求变量的实体标签的当前值
  • Set-Cookie:设置和页面关联的 cookie,服务器通过这个头部把 cookie 传给客户端
  • Keep-Alive:如果客户端有 keep-alive,服务端也会有响应(如 timeout=38)
  • Server:服务器的一些相关信息

一般来说,请求头部和响应头部是匹配分析的。

譬如,请求头部的Accept要和响应头部的Content-Type匹配,否则会报错

譬如,跨域请求时,请求头部的Origin要匹配响应头部的Access-Control-Allow-Origin,否则会报跨域错误

譬如,在使用缓存时,请求头部的If-Modified-Since、If-None-Match分别和响应头部的Last-Modified、ETag对应

请求/响应实体

http请求时,除了头部,还有消息实体,一般来说:

  • 请求实体中会将一些需要的参数都放入进入(用于 post 请求)如实体中可以放参数的序列化形式(a=1&b=2 这种),或者直接放表单对象(Form Data 对象,上传时可以夹杂参数以及文件)等等

  • 响应实体中就是放服务端需要传给客户端的内容,一般现在的接口请求时,实体中就是对于的信息的 json 格式,而像页面请求这种,里面就是直接放了一个 html 字符串,然后浏览器自己解析并渲染。

CRLF

CRLF(Carriage-Return Line-Feed),意思是回车换行,一般作为分隔符存在

请求头和实体消息之间有一个 CRLF 分隔,响应头部和响应实体之间用一个 CRLF 分隔

一般来说(分隔符类别):

1
2
3
CRLF->Windows-style
LF->Unix Style
CR->Mac Style

如下图是对某请求的 http 报文结构的简要分析:

http报文结构

cookie是浏览器的一种本地存储方式,一般用来帮助客户端和服务端通信的,常用来进行身份校验,结合服务端的session使用。

场景如下(简述):

1
2
3
4
5
在登陆页面,用户登陆了
此时,服务端会生成一个session,session中有对于用户的信息(如用户名、密码等)
然后会有一个sessionid(相当于是服务端的这个session对应的key)
然后服务端在登录页面中写入cookie,值就是:jsessionid=xxx
然后浏览器本地就有这个cookie了,以后访问同域名下的页面时,自动带上cookie,自动检验,在有效时间内无需二次登陆。

上述就是cookie的常用场景简述(当然了,实际情况下得考虑更多因素)

一般来说,cookie是不允许存放敏感信息的(千万不要明文存储用户名、密码),因为非常不安全,如果一定要强行存储,首先,一定要在cookie中设置httponly(这样就无法通过 js 操作了),另外可以考虑rsa等非对称加密(因为实际上,浏览器本地也是容易被攻克的,并不安全)

另外,由于在同域名的资源请求时,浏览器会默认带上本地的 cookie,针对这种情况,在某些场景下是需要优化的。

譬如以下场景:

1
2
3
4
5
客户端在域名A下有cookie(这个可以是登陆时由服务端写入的)
然后在域名A下有一个页面,页面中有很多依赖的静态资源(都是域名A的,譬如有20个静态资源)
此时就有一个问题,页面加载,请求这些静态资源时,浏览器会默认带上cookie
也就是说,这20个静态资源的http请求,每一个都得带上cookie,而实际上静态资源并不需要cookie验证
此时就造成了较为严重的浪费,而且也降低了访问速度(因为内容更多了)

当然了,针对这种场景,是有优化方案的(多域名拆分)。具体做法就是:

  • 将静态资源分组,分别放到不同的域名下(如static.base.com
  • page.base.com(页面所在域名)下请求时,是不会带上static.base.com域名的cookie的,所以就避免了浪费

说到了多域名拆分,这里再提一个问题,那就是:

  • 在移动端,如果请求的域名数过多,会降低请求速度(因为域名整套解析流程是很耗费时间的,而且移动端一般带宽都比不上 pc)
  • 此时就需要用到一种优化方案:dns-prefetch(让浏览器空闲时提前解析 dns 域名,不过也请合理使用,勿滥用)

关于 cookie 的交互,可以看下图总结:

cookie交互

gzip 压缩

首先,明确gzip是一种压缩格式,需要浏览器支持才有效(不过一般现在浏览器都支持), 而且gzip压缩效率很好(高达 70%左右),一般是由apache、tomcatweb服务器开启

一般只需要在服务器上开启了gzip压缩,然后之后的请求就都是基于gzip压缩格式的,当然服务器除了gzip外,也还会有其它压缩格式(如 deflate,没有 gzip 高效,且不流行)

长连接与短连接

首先看tcp/ip层面的定义:

  • 长连接:一个tcp/ip连接上可以连续发送多个数据包,在tcp连接保持期间,如果没有数据包发送,需要双方发检测包以维持此连接,一般需要自己做在线维持(类似于心跳包)
  • 短连接:通信双方有数据交互时,就建立一个tcp连接,数据发送完成后,则断开此tcp连接

然后在 http 层面:

  • http1.0中,默认使用的是短连接,也就是说,浏览器没进行一次 http 操作,就建立一次连接,任务结束就中断连接,譬如每一个静态资源请求时都是一个单独的连接
  • http1.1起,默认使用长连接,使用长连接会有这一行Connection: keep-alive,在长连接的情况下,当一个网页打开完成后,客户端和服务端之间用于传输httptcp连接不会关闭,如果客户端再次访问这个服务器的页面,会继续使用这一条已经建立的连接

注意: keep-alive 不会永远保持,它有一个持续时间,一般在服务器中配置(如 apache),另外长连接需要客户端和服务器都支持时才有效

http 1.1 性能瓶颈

  • 请求 / 响应头部(Header)未经压缩就发送,首部信息越多延迟越大。只能压缩 Body 的部分;
  • 发送冗长的首部。每次互相发送相同的首部造成的浪费较多;
  • 服务器是按请求的顺序响应的,如果服务器响应慢,会招致客户端一直请求不到数据,也就是队头阻塞;
  • 没有请求优先级控制;
  • 请求只能从客户端开始,服务器只能被动响应。

http 2.0

http2.0不是https,它相当于是http的下一代规范(譬如https的请求可以是http2.0规范的)

然后简述下http2.0http1.1的显著不同点:

  • http1.1中,每请求一个资源,都是需要开启一个tcp/ip连接的,所以对应的结果是,每一个资源对应一个tcp/ip请求,由于tcp/ip本身有并发数限制,所以当资源一多,速度就显著慢下来
  • http2.0中,一个tcp/ip请求可以请求多个资源,也就是说,只要一次tcp/ip请求,就可以请求若干个资源,分割成更小的帧请求,速度明显提升。

所以,如果http2.0全面应用,很多http1.1中的优化方案就无需用到了(譬如打包成精灵图,静态资源多域名拆分等)

然后简述下http2.0的一些特性:

  • 多路复用(即允许同时通过单一的 HTTP/2 连接(tcp/ip连接)可以请求多个资源,在 HTTP/1.1 协议中 「浏览器客户端在同一时间,针对同一域名下的请求有一定数量限制。超过限制数目的请求会被阻塞」)
  • 首部压缩http头部压缩(HPACK 算法),减少体积)
  • 二进制分帧(在应用层(HTTP/2)跟传输层(TCP or UDP)之间增加了一个二进制分帧层,改进传输性能,实现低延迟和高吞吐量)
  • 服务器端推送(也称为缓存推送,服务端可以对客户端的一个请求发出多个响应,可以主动通知客户端,当一个客户端请求资源 X,而服务器知道它很可能也需要资源 Z 的情况下,服务器可以在客户端发送请求前,主动将资源 Z 推送给客户端)
  • 请求优先级(如果数据流被赋予了优先级,它就会基于这个优先级来处理,由服务器决定需要多少资源来处理该请求。)

https

https就是安全版本的http,譬如一些支付等操作基本都是基于 https 的,因为 http 请求的安全系数太低了。

简单来看,httpshttp的区别就是: 在请求前,会建立ssl链接,确保接下来的通信都是加密的,无法被轻易截取分析。

一般来说,如果要将网站升级成https,需要后端支持(后端需要申请CA证书等),然后https的开销也比http要大(因为需要额外建立安全链接以及加密等),所以一般来说http2.0配合https的体验更佳(因为http2.0更快了)

https 原理

一般来说,主要关注的就是SSL/TLS的握手流程:

  1. ClientHello

    浏览器发起 https 请求建立 SSL链接(服务器的 443 端口),并向服务端发送以下信息(第一次 HTTP 请求)(明文传输):

    • 随机数 Client random,后面用于生成 会话对称加密密钥
    • 客户端支持的加密方法,比如 RSA 加密
    • 客户端支持的 SSL/TLS 协议版本,如 TLS 1.2 版本
  2. SeverHello

    服务器收到客户端请求后,向客户端发出响应,向客户端发送以下信息(明文传输):

    • 随机数 Server random,后面用于生成 会话对称加密密钥
    • 确认的 加密算法Hash算法
    • 确认 SSL/ TLS 协议版本,如果浏览器不支持,则关闭加密通信
    • 服务器的数字证书(证书里包含了网站地址,非对称加密的公钥,以及证书颁发机构等信息)
  3. 浏览器回应

    TLS 来验证证书的合法性(通过浏览器或者操作系统中的 CA 公钥验证颁发机构是否合法,证书中包含的网址是否和正在访问的一样,过期时间等),如果证书信任则浏览器会显示一个小锁头,否则会弹出一个警告框提示证书存在问题。

    客户端接收证书后(不管信不信任),会从数字证书中取出服务器的公钥,然后使用它加密报文,向服务器发送如下信息(第二次 HTTP 请求):

    • 新的随机数 Premaster secret,该随机数会被服务器公钥加密
    • 加密通信算法改变通知,表示随后的信息都将用「会话秘钥」加密通信。
    • 客户端握手结束通知,表示客户端的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要,用来供服务端校验。

    利用 Client randomServer randomPremaster secret 通过双方协商的加密算法各自生成本次通信的 会话对称加密密钥

  4. 服务器的最后回应

    服务器收到客户端的第三个随机数 Premaster secret 之后,通过协商的加密算法计算出本次通信的 会话对称加密密钥。使用该密钥解密浏览器发来的握手消息,并验证Hash是否与浏览器发来的一致。然后向客户端发生最后的信息:

    • 加密通信算法改变通知,表示随后的信息都将用会话对称加密密钥加密通信。
    • 服务器握手结束通知,表示服务器的握手阶段已经结束。这一项同时把之前所有内容的发生的数据做个摘要,用来供客户端校验。
  5. 浏览器解密并计算握手消息的 HASH,如果与服务端发来的 HASH一致,此时握手过程结束。接下来,客户端与服务器进入加密通信,就完全是使用普通的 HTTP 协议,只不过用会话对称加密密钥加密内容。

这里放一张图(来源:阮一峰-图解 SSL/TLS 协议)

图解SSL/TLS协议

https 加密是在传输层

https 报文在被包装成 tcp 报文的时候完成加密的过程,无论是 httpsheader 域也好,body 域也罢都是会被加密的。

当使用 tcpdump 或者 wireshark 之类的 tcp 层工具抓包,获取是加密的内容,而如果用应用层抓包,使用 Charels(Mac)、Fildder(Windows) 抓包工具,那当然看到是明文的

加密算法,信息摘要,数字签名,数字证书,CA

  • 对称加密算法:AES,RC4,3DES
  • 非对称加密算法:RSA,DSA/DSS
  • 摘要算法(哈希 hash 算法、散列算法):MD5,SHA1,SHA256,加盐 salt 提升复杂度
  • 信息摘要:通过信息摘要算法(HASH),将原信息摘要为一个固定长度的摘要
  • 数字签名:信息摘要被私钥加密后的密文
  • 数字证书:可以简单理解为 被 CA 承认且无法篡改的公钥,可用于验证网站是否可信(针对 HTTPS)、验证某文件是否可信(是否被篡改)等,也可以用一个证书来证明另一个证书是真实可信,最顶级的证书称为根证书。除了根证书(自己证明自己是可靠),其它证书都要依靠上一级的证书,来证明自己。
  • CA:Certificate Authority 签发证书的权威机构
  • 根 CA:CA 的 CA,可以签发 CA 的证书
  • 根证书:根 CA 的自签名证书,内置在操作系统和浏览器中

HTTPS 和 HTTP 的区别

  1. https 协议需要到 ca 申请证书或自制证书。
  2. http 的信息是明文传输,https 则是具有安全性的 ssl 加密。
  3. http 是直接与 TCP 进行数据传输,而 https 是经过一层 SSL(OSI 会话层),用的端口也不一样,前者是 80(需要国内备案),后者是 443
  4. http 的连接很简单,是无状态的;https 协议是由 SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议,比 http 协议安全。
  5. https 协议握手阶段比较费时,会使页面的加载时间延长近 50%,增加 10% 到 20% 的耗电。
  6. https 连接缓存不如 http 高效,会增加数据开销和功耗,甚至已有的安全措施也会因此而受到影响。
  7. 谷歌曾在 2014 年 8 月份调整搜索引擎算法,并称“比起同等 HTTP 网站,采用 HTTPS 加密的网站在搜索结果中的排名将会更高”。

单独拎出来的缓存问题,http 的缓存

前后端的http交互中,使用缓存能很大程度上的提升效率,而且基本上对性能有要求的前端项目都是必用缓存的

强缓存与弱缓存

缓存可以简单的划分成两种类型:强缓存(200 from cache)协商缓存(304)

区别简述如下:

  • 强缓存(200 from cache)时,浏览器如果判断本地缓存未过期,就直接使用,无需发起http请求
  • 协商缓存(304)时,浏览器会向服务端发起http请求,然后服务端告诉浏览器文件未改变,让浏览器使用本地缓存

对于协商缓存,使用Ctrl + F5强制刷新可以使得缓存无效

但是对于强缓存,在未过期时,必须更新资源路径才能发起新的请求(更改了路径相当于是另一个资源了,这也是前端工程化中常用到的技巧)

缓存头部简述

上述提到了强缓存和协商缓存,那它们是怎么区分的呢?

答案是通过不同的 http 头部控制

先看下这几个头部:

1
If-None-Match/E-tag、If-Modified-Since/Last-Modified、Cache-Control/Max-Age、Pragma/Expires

这些就是缓存中常用到的头部,这里不展开。仅列举下大致使用。

属于强缓存控制的:

1
(http1.1)Cache-Control/Max-Age (http1.0)Pragma/Expires

注意:Max-Age不是一个头部,它是Cache-Control头部的值

属于协商缓存控制的:

1
(http1.1)If-None-Match/E-tag (http1.0)If-Modified-Since/Last-Modified

可以看到,上述有提到http1.1http1.0,这些不同的头部是属于不同http时期的

再提一点,其实 HTML 页面中也有一个meta标签可以控制缓存方案:Pragma

1
<meta http-equiv="Pragma" content="no-cache" />

不过,这种方案还是比较少用到,因为支持情况不佳,譬如缓存代理服务器肯定不支持,所以不推荐

头部的区别

首先明确,http的发展是从http1.0http1.1

而在http1.1中,出了一些新内容,弥补了http1.0的不足。

http1.0 中的缓存控制

  • Pragma:严格来说,它不属于专门的缓存控制头部,但是它设置 no-cache 时可以让本地强缓存失效(属于编译控制,来实现特定的指令,主要是因为兼容 http1.0,所以以前又被大量应用)
  • Expires:服务端配置的,属于强缓存,用来控制在规定的时间之前,浏览器不会发出请求,而是直接使用本地缓存,注意,Expires 一般对应服务器端时间,如 Expires:Fri, 30 Oct 1998 14:19:41
  • If-Modified-Since/Last-Modified:这两个是成对出现的,属于协商缓存的内容,其中浏览器的头部是 If-Modified-Since,而服务端的是 Last-Modified,它的作用是,在发起请求时,如果 If-Modified-Since 和 Last-Modified 匹配,那么代表服务器资源并未改变,因此服务端不会返回资源实体,而是只返回头部,通知浏览器可以使用本地缓存。Last-Modified,顾名思义,指的是文件最后的修改时间,而且只能精确到 1s 以内

http1.1 中的缓存控制

  • Cache-Control:缓存控制头部,有 no-cache、max-age 等多种取值
  • Max-Age:服务端配置的,用来控制强缓存,在规定的时间之内,浏览器无需发出请求,直接使用本地缓存,注意,Max-Age 是 Cache-Control 头部的值,不是独立的头部,譬如 Cache-Control: max-age=3600,而且它值得是绝对时间,由浏览器自己计算
  • If-None-Match/E-tag:这两个是成对出现的,属于协商缓存的内容,其中浏览器的头部是 If-None-Match,而服务端的是 E-tag,同样,发出请求后,如果 If-None-Match 和 E-tag 匹配,则代表内容未变,通知浏览器使用本地缓存,和 Last-Modified 不同,E-tag 更精确,它是类似于指纹一样的东西,基于 FileEtag INode Mtime Size 生成,也就是说,只要文件变,指纹就会变,而且没有 1s 精确度的限制。

Max-Age 相比 Expires

  • Expires: 使用的是服务器端的时间,但是有时候会有这样一种情况-客户端时间和服务端不同步,那这样,可能就会出问题了,造成了浏览器本地的缓存无用或者一直无法过期,所以一般http1.1后不推荐使用Expires

  • Max-Age: 使用的是客户端本地时间的计算,因此不会有这个问题,因此推荐使用Max-Age

注意,如果同时启用了Cache-ControlExpiresCache-Control优先级高。

E-tag 相比 Last-Modified

  • Last-Modified:表明服务端的文件最后何时改变的,它有一个缺陷就是只能精确到 1s,而且有的服务端的文件会周期性的改变,导致缓存失效

  • E-tag:是一种指纹机制,代表文件相关指纹,只有文件变才会变,也只要文件变就会变,也没有精确时间的限制,只要文件一遍,立马 E-tag 就不一样了

如果同时带有E-tagLast-Modified,服务端会优先检查E-tag

各大缓存头部的整体关系如下图:

缓存

解析页面流程

前面有提到http交互,那么接下来就是浏览器获取到html,然后解析,渲染

流程简述

浏览器内核拿到内容后,渲染步骤大致可以分为以下几步:

  1. 解析 HTML,构建 DOM 树
  2. 解析 CSS,生成 CSS 规则树
  3. 合并 DOM 树和 CSS 规则树,生成 render 树
  4. 布局 render 树(Layout/reflow),负责各元素尺寸、位置的计算
  5. 绘制 render 树(paint),绘制页面像素信息
  6. 浏览器会将各层的信息发送给 GPU,GPU 会将各层合成(composite),显示在屏幕上

如下图:

页面渲染

HTML 解析,构建 DOM 树

整个渲染步骤中,HTML 解析是第一步。

简单的理解,这一步的流程是这样的:浏览器解析 HTML,构建 DOM 树。

解析 HTML 到构建出 DOM 当然过程可以简述如下:Bytes → characters → tokens → nodes → DOM

譬如假设有这样一个 HTML 页面:

1
2
3
4
5
6
7
8
9
10
11
<html>
<head>
<meta name="viewport" content="width=device-width,initial-scale=1" />
<link href="style.css" rel="stylesheet" />
<title>Critical Path</title>
</head>
<body>
<p>Hello <span>web performance</span> students!</p>
<div><img src="awesome-photo.jpg" /></div>
</body>
</html>

浏览器的处理如下:

构建DOM树1

列举其中的一些重点过程:

  • Conversion 转换:浏览器将获得的 HTML 内容(Bytes)基于他的编码转换为单个字符
  • Tokenizing 分词:浏览器按照 HTML 规范标准将这些字符转换为不同的标记 token。每个 token 都有自己独特的含义以及规则集
  • Lexing 词法分析:分词的结果是得到一堆的 token,此时把他们转换为对象,这些对象分别定义他们的属性和规则
  • DOM 构建:因为 HTML 标记定义的就是不同标签之间的关系,这个关系就像是一个树形结构一样 例如:body 对象的父节点就是 HTML 对象,然后段落 p 对象的父节点就是 body 对象

最后的 DOM 树如下:

构建DOM树2

生成 CSS 规则树

同理,CSS 规则树的生成也是类似。简述为:Bytes → characters → tokens → nodes → CSSOM

譬如 style.css 内容如下:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
body {
font-size: 16px;
}
p {
font-weight: bold;
}
span {
color: red;
}
p span {
display: none;
}
img {
float: right;
}

那么最终的 CSSOM 树就是:

CSSOM树

构建渲染树

DOM树CSSOM树都有了后,就要开始构建渲染树了,一般来说,渲染树和 DOM 树相对应的,但不是严格意义上的一一对应,因为有一些不可见的DOM元素不会插入到渲染树中,如head这种不可见的标签或者display: none等。

整体来说可以看图:

构建渲染树

渲染

有了 render 树,接下来就是开始渲染,基本流程如下:

渲染

图中重要的四个步骤就是:

  1. 计算 CSS 样式
  2. 构建渲染树
  3. 布局,主要定位坐标和大小,是否换行,各种position,overflow,z-index属性
  4. 绘制,将图像绘制出来

然后,图中的线与箭头代表通过 js 动态修改了DOMCSS,导致了重新布局(Layout)渲染(Repaint)

这里LayoutRepaint的概念是有区别的:

  • Layout,也称为Reflow(重排),即回流。一般意味着元素的内容、结构、位置或尺寸发生了变化,需要重新计算样式和渲染树
    • 以下会触发回流:
      • 盒子模型相关属性会触发重布局(width,height,padding,margin,display,border-width,border,min-height)
      • 定位属性及浮动也会触发重布局(top,bottom,left,right,position,float,clear)
      • 改变节点内部文字结构也会触发重布局(text-align,overflow-y,font-weight,overflow,font-family,line-height,vertival-align,white-space,font-size)
      • 获取某些属性也会引发回流,很多浏览器会对回流做优化,会等到数量足够时做一次批处理回流,但是除了 render 树的直接变化,当获取一些属性时,浏览器为了获得正确的值也会触发回流,这样使得浏览器优化无效,包括:
        • offset(Top/Left/Width/Height)
        • scroll(Top/Left/Width/Height)
        • cilent(Top/Left/Width/Height)
        • width,height
        • 调用了getComputedStyle()或者 IE 的currentStyle
  • Repaint,即重绘。意味着元素发生的改变只是影响了元素的一些外观之类的时候(color,border-style,border-radius,visibility,text-decoration,background,background-image,background-position,background-repeat,background-size,outline-color,outline,outline-style,outline-width,box-shadow),此时只需要应用新样式绘制这个元素就可以了

回流一定伴随着重绘重绘却可以单独出现。回流的成本开销要高于重绘,而且一个节点的回流往往回导致子节点以及同级节点的回流, 所以优化方案中一般都包括,尽量避免回流

本身浏览器通过队列化修改批量显示优化重排版过程。其他一般会有一些优化方案,如:

  • 减少逐项更改 dom 样式,最好一次性更改style,或者将样式定义为class并一次性更新
  • DOM离线后修改
    • 使用documentFragment 对象在内存里操作DOM
    • 先把DOMdisplay:none(有一次reflow),然后你想怎么改就怎么改。比如修改 100 次,然后再把他显示出来
    • clone一个DOM结点到内存里,然后想怎么改就怎么改,改完后,和在线的那个的交换一下
  • 不要把DOM结点的属性值(offset等)放在一个循环里当成循环里的变量。不然这会导致大量地读写这个结点的属性,无法避免则将它们缓存到变量
  • 尽可能的修改层级比较低的DOM。当然,改变层级比较底的DOM有可能会造成大面积的reflow,但是也可能影响范围很小
  • 将复杂的元素绝对定位(absolute)或固定定位(fixed),使得它脱离文档流,否则回流代价会很高
  • 千万不要使用table布局。因为可能很小的一个小改动会造成整个table的重新布局

再来看一个示例:

1
2
3
4
5
6
7
8
9
var s = document.body.style;

s.padding = '2px'; // 回流+重绘
s.border = '1px solid red'; // 再一次 回流+重绘
s.color = 'blue'; // 再一次重绘
s.backgroundColor = '#ccc'; // 再一次 重绘
s.fontSize = '14px'; // 再一次 回流+重绘
// 添加node,再一次 回流+重绘
document.body.appendChild(document.createTextNode('abc!'));

了解层

在第 6 步:

1
6. 浏览器会将各层的信息发送给GPU,GPU会将各层合成(composite),显示在屏幕上

什么是 composite

DOM 树中每个节点都会对应一个 LayoutObject,当他们的 LayoutObject 处于相同的坐标空间时,就会形成一个 RenderLayers ,也就是渲染层。RenderLayers 来保证页面元素以正确的顺序合成,这时候就会出现层合成(composite),从而正确处理透明元素和重叠元素的显示。

GPU中,各个复合图层是单独绘制的,所以互不影响,可以通过硬件加速的方式,声明一个新的复合图层,它会单独分配资源。复合层是独立的,所以一般做动画推荐使用硬件加速。

调试方式 :

  • Chrome源码调试 -> More Tools -> Layers
  • Chrome源码调试 -> More Tools -> Rendering -> Layer borders,黄色的就是复合图层信息

RenderLayers 与 GraphicsLayers

RenderLayers 与 GraphicsLayers

chrome 中:

  • RenderLayers 渲染层,这是负责对应 DOM 子树
  • GraphicsLayers 图形层,这是负责对应 RenderLayers 子树

RenderObjects 保持了树结构,他通过向一个绘图上下文(GraphicsContext)发出必要的绘制调用来绘制 nodes

每个 GraphicsLayer 都有一个 GraphicsContextGraphicsContext 会负责输出该层的位图位图是存储在共享内存中,作为纹理上传到 GPU 中,最后由 GPU 将多个位图进行合成,然后 draw 到屏幕上,此时,我们的页面也就展现到了屏幕上。

影响 composite 因素

以下情形浏览器会主动将渲染层提至合成层(硬件加速):

  • z-index
  • 3D 或透视变换(perspective transform) CSS 属性
  • video, canvas, iframe, Flash 等元素
  • opacity 属性/过渡动画
  • position: fixed
  • will-change
  • filter
  • backface-visibility
  • 元素有一个包含复合层的后代节点(换句话说,就是一个元素拥有一个子元素,该子元素在自己的层里)
  • 元素有一个 z-index 较低且包含一个复合层的兄弟元素(换句话说就是该元素在复合层上面渲染)

使用硬件加速时,尽可能的使用z-index,防止浏览器默认给后续的元素创建复合层渲染.因为在 webkit CSS3 中,如果这个元素添加了硬件加速,并且 index 层级比较低,
那么在这个元素的后面其它元素会默认变为复合层渲染,如果处理不当会极大的影响性能,即如果 a 是一个复合图层,而且 b 在 a 上面,那么 b 也会被隐式转为一个复合图层。

复合图层的优劣

  • 优:合成层的位图,会交由 GPU 合成,比 CPU 处理要快
  • 优:当需要 repaint 时,只需要 repaint 本身,不会影响到其他的层
  • 优:元素提升为合成层后,transformopacity 才不会触发 paint,如果不是合成层,则其依然会触发 paint
  • 劣:大量的合成层,这样会占用很多无辜的 CPU 和内存资源,严重影响了页面的性能
  • 劣:层爆炸,由于某些原因可能导致产生大量不在预期内的合成层,虽然有浏览器的层压缩机制,但是也有很多无法进行压缩的情况,这就可能出现层爆炸的现象

如果你已经把一个元素放到一个新的合成层里,那么可以使用 Timeline 来确认这么做是否真的改进了渲染性能。别盲目提升合成层,一定要分析其实际性能表现。

在内存资源有限的设备上,合成层带来的性能改善,可能远远赶不上过多合成层开销给页面性能带来的负面影响。同时,由于每个渲染层的纹理都需要上传到 GPU 处理,因此我们还需要考虑 CPU 和 GPU 之间的带宽问题、以及有多大内存供 GPU 处理这些纹理的问题。

Chrome 中的调试

Chrome 的开发者工具中,Performance 中可以看到详细的渲染过程:

Chrome中的调试

资源外链的下载

上面介绍了 html 解析,渲染流程。但实际上,在解析 html 时,会遇到一些资源连接,此时就需要进行单独处理了

简单起见,这里将遇到的静态资源分为一下几大类(未列举所有):

  • CSS 样式资源
  • JS 脚本资源
  • img 图片类资源

遇到外链时的处理

当遇到上述的外链时,会单独开启一个下载线程去下载资源(http1.1 中是每一个资源的下载都要开启一个 http 请求,对应一个 tcp/ip 链接)

遇到 CSS 样式资源

CSS 资源的处理有几个特点:

  • CSS 下载时异步,不会阻塞浏览器构建DOM树
  • 但是会阻塞渲染,也就是在构建render时,会等到 css 下载解析完毕后才进行(这点与浏览器优化有关,防止 css 规则不断改变,避免了重复的构建)
  • 有例外,media query声明的 CSS 是不会阻塞渲染的

遇到 JS 脚本资源

JS 脚本资源的处理有几个特点:

  • 阻塞浏览器的解析,也就是说发现一个外链脚本时,需等待脚本下载完成并执行后才会继续解析 HTML
  • 当解析器遇到一个脚本标签而 CSSOM 还没有准备好时,会发生什么情况呢?答案很简单。Javascript 执行将会停止,直到 CSSOM 就绪。
  • 浏览器的优化在脚本阻塞时,也会继续下载其它资源(当然有并发上限),但是虽然脚本可以并行下载,解析过程仍然是阻塞的,也就是说必须这个脚本执行完毕后才会接下来的解析,并行下载只是一种优化而已
  • deferasync,普通的脚本是会阻塞浏览器解析的,但是可以加上deferasync属性,这样脚本就变成异步了,可以等到解析完毕后再执行

注意,deferasync是有区别的: defer 是延迟执行,而 async 是异步执行。

简单的说:

  • async是异步执行,异步下载完毕后就会执行,不确保执行顺序,一定在onload前,但不确定在DOMContentLoaded事件的前或后
  • defer是延迟执行,在浏览器看起来的效果像是将脚本放在了 body 后面一样(虽然按规范应该是在DOMContentLoaded事件前,但实际上不同浏览器的优化效果不一样,也有可能在它后面)

遇到 img 图片类资源

遇到图片等资源时,直接就是异步下载,不会阻塞解析,下载完毕后直接用图片替换原有 src 的地方

loaded 和 domcontentloaded

简单的对比:

  • DOMContentLoaded 事件触发时,仅当DOM加载完成,不包括样式表,图片(譬如如果有 async 加载的脚本就不一定完成)
  • load 事件触发时,页面上所有的 DOM,样式表,脚本,图片都已经加载完成了

CSS 的可视化格式模型

前面提到了整体的渲染概念,但实际上文档树中的元素是按什么渲染规则渲染的,是可以进一步展开的

先了解:

  • CSS 中规定每一个元素都有自己的盒子模型(相当于规定了这个元素如何显示)
  • 然后可视化格式模型则是把这些盒子按照规则摆放到页面上,也就是如何布局及相互作用

说到底: CSS 的可视化格式模型就是规定了浏览器在页面中如何处理文档树

关键字:

1
2
3
4
5
6
7
8
包含块(Containing Block)
控制框(Controlling Box)
盒模型
BFC(Block Formatting Context)
IFC(Inline Formatting Context)
定位体系
浮动等
...

另外,CSS 有三种定位机制:普通流浮动绝对定位,如无特别提及,下文中都是针对普通流中的

包含块(Containing Block)

一个元素的box的定位和尺寸,会与某一矩形框有关,这个框就称之为包含块

元素会为它的子孙元素创建包含块,但是,并不是说元素的包含块就是它的父元素,元素的包含块与它的祖先元素的样式等有关系。

譬如:

  • 根元素是最顶端的元素,它没有父节点,它的包含块就是初始包含块
  • staticrelative的包含块由它最近的块级单元格或者行内块祖先元素的内容框(content)创建
  • fixed的包含块是当前可视窗口
  • absolute的包含块由它最近的position属性为absoluterelative或者fixed的祖先元素创建
    • 如果其祖先元素是行内元素,则包含块取决于其祖先元素的direction特性
    • 如果祖先元素不是行内元素,那么包含块的区域应该是祖先元素的内边距边界

控制框(Controlling Box)

块级元素和块框以及行内元素和行框的相关概念

块框

  • 块级元素会生成一个块框(Block Box),块框会占据一整行,用来包含子 box 和生成的内容
  • 块框同时也是一个块包含框(Containing Box),里面要么只包含块框,要么只包含行内框(不能混杂),如果块框内部有块级元素也有行内元素,那么行内元素会被匿名块框包围

关于匿名块框的生成,示例:

1
2
3
4
<div>
Some text
<p>More text</p>
</div>

div生成了一个块框,包含了另一个块框p以及文本内容Some text,此时Some text文本会被强制加到一个匿名的块框里面,被div生成的块框包含(其实这个就是 IFC 中提到的行框,包含这些行内框的这一行匿名块形成的框,行框和行内框不同)

换句话说:
如果一个块框在其中包含另外一个块框,那么我们强迫它只能包含块框,因此其它文本内容生成出来的都是匿名块框(而不是匿名行内框)

行内框

  • 一个行内元素生成一个行内框
  • 行内元素能排在一行,允许左右有其它元素

关于匿名行内框的生成,示例:

1
<p>Some <em>emphasized</em> text</p>

P 元素生成一个块框,其中有几个行内框(如 EM),以及文本 Some , text,此时会专门为这些文本生成匿名行内框

display 属性的影响

display 的几个属性也可以影响不同框的生成:

  • block,元素生成一个块框
  • inline,元素产生一个或多个的行内框
  • inline-block,元素产生一个行内级块框,行内块框的内部会被当作块块来格式化,而此元素本身会被当作行内级框来格式化(这也是为什么会产生 BFC)
  • none,不生成框,不再格式化结构中,当然了,另一个 visibility: hidden 则会产生一个不可见的框

总结:

  • 如果一个框里,有一个块级元素,那么这个框里的内容都会被当作块框来进行格式化,因为只要出现了块级元素,就会将里面的内容分块几块,每一块独占一行(出现行内可以用匿名块框解决)
  • 如果一个框里,没有任何块级元素,那么这个框里的内容会被当成行内框来格式化,因为里面的内容是按照顺序成行的排列

盒模型

CSS盒模型本质上是一个盒子,封装周围的HTML元素,它包括:外边距(margin)、边框(border)、内边距(padding)、实际内容(content)四个属性。

标准盒子模型

标准盒子模型

paddingborder不被包含在定义的widthheight之内。对象的实际宽度等于设置的width值和borderpadding之和,即 Element width = width + border + padding

IE 盒子模型(怪异盒模型)

IE盒子模型

paddingborder被包含在定义的widthheight之内。对象的实际宽度就等于设置的width值,即使定义有borderpadding也不会改变对象的实际宽度,即 Element width = width

box-sizing

box-sizing 用于指定盒子模型种类

1
2
3
box-sizing: content-box; /*默认值,对应标准盒子模型  */
box-sizing: border-box; /* 对应IE盒子模型 */
box-sizing: inherit; /* 规定应从父元素继承 box-sizing 属性 */

BFC & IFC

篇幅太长,详情跳转此处BFC 等 Formatting Contexts 浅析

JS 引擎解析过程

前面有提到遇到 JS 脚本时,会等到它的执行,实际上是需要引擎解析的,这里展开描述(介绍主干流程)

JS 的解释阶段

首先得明确: JS 是解释型语言,所以它无需提前编译,而是由解释器实时运行

引擎对 JS 的处理过程可以简述如下:

  1. 读取代码,进行词法分析(Lexical analysis),然后将代码分解成词元(token)
  2. 对词元进行语法分析(parsing),然后将代码整理成语法树(syntax tree)
  3. 使用翻译器(translator),将代码转为字节码(bytecode)
  4. 使用字节码解释器(bytecode interpreter),将字节码转为机器码

最终计算机执行的就是机器码

为了提高运行速度,现代浏览器一般采用即时编译(JIT-Just In Time compiler),即字节码只在运行时编译,用到哪一行就编译哪一行,并且把编译结果缓存(inline cache),这样整个程序的运行速度能得到显著提升。而且,不同浏览器策略可能还不同,有的浏览器就省略了字节码的翻译步骤,直接转为机器码(如 chrome 的 v8)

总结起来可以认为是: 核心的JIT编译器将源码编译成机器码运行。

JS 的预处理阶段

上述将的是解释器的整体过程,这里再提下在正式执行 JS 前,还会有一个预处理阶段 (譬如变量提升,分号补全等)

预处理阶段会做一些事情,确保 JS 可以正确执行,这里仅提部分:

分号补全

JS 执行是需要分号的,但为什么以下语句却可以正常运行呢?

1
2
console.log('a');
console.log('b');

原因就是 JS 解释器有一个Semicolon Insertion规则,它会按照一定规则,在适当的位置补充分号

譬如列举几条自动加分号的规则:

  • 当有换行符(包括含有换行符的多行注释),并且下一个 token 没法跟前面的语法匹配时,会自动补分号。
  • 当有}时,如果缺少分号,会补分号。
  • 程序源代码结束时,如果缺少分号,会补分号。

于是,上述的代码就变成了

1
2
console.log('a');
console.log('b');

所以可以正常运行。

当然了,这里有一个经典的例子:

1
2
3
4
5
6
function b() {
return;
{
a: 'a';
}
}

由于分号补全机制,所以它变成了:

1
2
3
4
5
6
function b() {
return;
{
a: 'a';
}
}

所以运行后是undefined

变量提升

一般包括函数提升变量提升

譬如:

1
2
3
4
5
6
a = 1;
b();
function b() {
console.log('b');
}
var a;

经过变量提升后,就变成:

1
2
3
4
5
6
function b() {
console.log('b');
}
var a;
a = 1;
b();

这里没有展开,其实展开也可以牵涉到很多内容的,譬如可以提下变量声明,函数声明,形参,实参的优先级顺序,以及 es6 中 let 有关的临时死区等.

JS 的执行阶段

相关概念中文文档翻译查阅

解释器解释完语法规则后,就开始执行,然后整个执行流程中大致包含以下概念:

  • 执行上下文,执行堆栈概念(如全局上下文,当前活动上下文)
  • VO(变量对象)和 AO(活动对象)
  • 作用域链
  • this 机制等

这些概念如果深入讲解的话内容过多,因此这里仅提及部分特性

执行上下文简单解释

  • JS 有执行上下文
  • 浏览器首次载入脚本,它将创建全局执行上下文,并压入执行栈栈顶(不可被弹出)
  • 然后每进入其它作用域就创建对应的执行上下文并把它压入执行栈的顶部
  • 一旦对应的上下文执行完毕,就从栈顶弹出,并将上下文控制权交给当前的栈
  • 这样依次执行(最终都会回到全局执行上下文)

譬如,如果程序执行完毕,被弹出执行栈,然后有没有被引用(没有形成闭包),那么这个函数中用到的内存就会被垃圾处理器自动回收

执行上下文

然后执行上下文与 VO,作用域链,this 的关系是:

每一个执行上下文,都有三个重要属性:

  • 变量对象(Variable object-VO)
  • 作用域链(Scope chain)
  • this

execution context

VO 与 AO

VO是执行上下文的属性(抽象概念),但是只有全局上下文的变量对象允许通过VO的属性名称来间接访问(因为在全局上下文里,全局对象自身就是变量对象)

AO(activation object) 活动对象,当函数被调用者激活,AO就被创建了

可以理解为:

  • 在函数上下文中:VO === AO
  • 在全局上下文中:VO === this === global

总的来说,VO中会存放一些变量信息(如声明的变量,函数,arguments 参数等等)

作用域链

它是执行上下文中的一个属性,原理和原型链很相似,作用很重要。

譬如流程简述:

  • 在函数上下文中,查找一个变量foo
  • 如果函数的VO中找到了,就直接使用
  • 否则去它的父级作用域链中(parent)找
  • 如果父级中没找到,继续往上找
  • 直到全局上下文中也没找到就报错

this 指针

这也是 JS 的核心知识之一,由于内容过多,这里就不展开,仅提及部分,更多this 介绍查询

注意:this 是执行上下文环境的一个属性,而不是某个变量对象的属性

因此:

  • this是没有一个类似搜寻变量的过程
  • 当代码中使用了this,这个 this的值就直接从执行的上下文中获取了,而不会从作用域链中搜寻
  • this的值只取决中进入上下文时的情况

所以经典的例子:

1
2
3
4
5
6
7
8
9
10
11
12
var baz = 200;
var bar = {
baz: 100,
foo: function () {
console.log(this.baz);
},
};
var foo = bar.foo;
// 进入环境:global
foo(); // 200,严格模式中会报错,Cannot read property 'baz' of undefined
// 进入环境:global bar
bar.foo(); // 100

就要明白了上面this的介绍,上述例子很好理解.

回收机制

JS 有垃圾处理器,所以无需手动回收内存,而是由垃圾处理器自动处理。

一般来说,垃圾处理器有自己的回收策略。譬如对于那些执行完毕的函数,如果没有外部引用(被引用的话会形成闭包),则会回收。(当然一般会把回收动作切割到不同的时间段执行,防止影响性能)

常用的两种垃圾回收规则是:

  • 标记清除
  • 引用计数

Javascript引擎基础GC方案是(simple GC):mark and sweep(标记清除),简单解释如下:

  • 遍历所有可访问的对象。
  • 回收已不可访问的对象。

譬如:(出自 javascript 高程)

1
2
3
4
5
6
7
当变量进入环境时,例如,在函数中声明一个变量,就将这个变量标记为“进入环境”。
从逻辑上讲,永远不能释放进入环境的变量所占用的内存,因为只要执行流进入相应的环境,就可能会用到它们。
而当变量离开环境时,则将其标记为“离开环境”。
垃圾回收器在运行的时候会给存储在内存中的所有变量都加上标记(当然,可以使用任何标记方式)。
然后,它会去掉环境中的变量以及被环境中的变量引用的变量的标记(闭包,也就是说在环境中的以及相关引用的变量会被去除标记)。
而在此之后再被加上标记的变量将被视为准备删除的变量,原因是环境中的变量已经无法访问到这些变量了。
最后,垃圾回收器完成内存清除工作,销毁那些带标记的值并回收它们所占用的内存空间。

关于引用计数,简单点理解:跟踪记录每个值被引用的次数,当一个值被引用时,次数+1,减持时-1,下次垃圾回收器会回收次数为 0 的值的内存(当然了,容易出循环引用的 bug)

GC 的缺陷

和其他语言一样,javascript 的GC策略也无法避免一个问题: GC 时,停止响应其他操作,这是为了安全考虑。而 Javascript 的GC在 100ms 甚至以上。

对一般的应用还好,但对于 JS 游戏,动画对连贯性要求比较高的应用,就麻烦了。这就是引擎需要优化的点: 避免 GC 造成的长时间停止响应。

GC 优化策略

这里介绍常用到的:分代回收(Generation GC)

目的是通过区分“临时”与“持久”对象:

  • 多回收“临时对象”区(young generation
  • 少回收“持久对象”区(tenured generation
  • 减少每次需遍历的对象,从而减少每次 GC 的耗时。

像 node v8 引擎就是采用的分代回收。

更多 JavaScript 垃圾回收查阅

其它

可以提到跨域

譬如发出网络请求时,会用 AJAX,如果接口跨域,就会遇到跨域问题

可以参考:

ajax 跨域,这应该是最全的解决方案了

可以提到 web 安全

譬如浏览器在解析 HTML 时,有 XSSAuditor,可以延伸到 web 安全相关领域

可以参考:

AJAX 请求真的不安全么?谈谈 Web 安全与 AJAX 的关系。

更多

  • 如可以提到 viewport 概念,讲讲物理像素,逻辑像素,CSS 像素等概念查阅
  • 如熟悉 Hybrid 开发的话可以提及一下 Hybrid 相关内容以及优化。
---- 本文结束,感谢您的阅读 ----