口试中经常会被问到这个题目吧，唉，我最最先被问到的时刻也就能够也许说一些流程。被问得多了，本身就想去找找这个题目的周全回复，因而乎搜了许多材料和网上的文章，依据那些文章写一个总结。

写得不好，或许有看法的直接喷，不必走流程。也迎接大佬指导

起首这不是小题目，能把内里的历程说清楚真的很贫苦，然后下面我把这些知识点，按流程的情势总结的：

1. 从阅读器吸收url到开启收集请求线程
2. 开启收集线程到发出一个完全的http请求
3. 从效劳器吸收到请求到对应背景吸收到请求
4. 背景和前台的http交互
5. http的缓存题目
6. 阅读器吸收到http数据包后的剖析流程
7. CSS的可视化花样模子
8. JS引擎剖析历程
9. 跨域、web平安、hybrid等等

1. 从阅读器吸收url到开启收集请求线程

多历程的阅读器

阅读器是多历程的，有一个主控历程，以及每一个tab页面都邑新开一个历程（某些状况下多个tab齐集并历程）。

历程能够包括主控历程，插件历程，GPU，tab页（阅读器内核）等等。

1. Browser历程：阅读器的主历程（担任谐和、主控），只需一个
2. 第三方插件历程：每种范例的插件对应一个历程，仅当运用该插件时才竖立
3. GPU历程：最多一个，用于3D绘制
4. 阅读器衬着历程（内核）：默许每一个Tab页面一个历程，互不影响，掌握页面衬着，剧本实行，事宜处置惩罚等（有时刻会优化，如多个空缺tab齐集并成一个历程）

多线程的阅读器内核

每一个tab页面能够看做是阅读器内核历程，然后这个历程是多线程的，它有几大类子线程：

1. GUI衬着线程
2. JS引擎线程
3. 事宜触发线程
4. 定时器触发线程
5. http异步收集请求线程

剖析URL

输入URL后，会举行剖析（URL的实质就是一致资本定位符）

URL平常包括几大部份：

1. protocol，协定头，比方有http，ftp，https等
2. host，主机域名或IP地点
3. port，端口号
4. path，目次途径
5. query，即查询参数
6. fragment，即 #后的hash值，平经常使用来定位到某个位置

收集请求都是零丁的线程

每次收集请求时都须要拓荒零丁的线程举行，比方假如URL剖析到http协定，就会新建一个收集线程去处置惩罚资本下载。

因而阅读器会依据剖析出得协定，拓荒一个收集线程，前去请求资本。

2. 开启收集线程到发出一个完全的http请求

DNS查询取得IP

假如输入的是域名，须要举行dns剖析成IP，大抵流程：

假如阅读器有缓存，直接运用阅读器缓存，不然运用本机缓存，再没有的话就是用host
假如当地没有，就向dns域名效劳器查询（固然，中心能够还会经由路由，也有缓存等），查询到对应的IP
注重，域名查询时有多是经由了CDN调理器的（假如有cdn存储功用的话）。

而且，须要晓得dns剖析是很耗时的，因而假如剖析域名过量，会让首屏加载变得过慢，能够斟酌 dns-prefetch优化。
这一块能够深切睁开，细致请去网上搜刮，这里就不占篇幅了（网上能够看到很细致的解答）。

tcp/ip请求

http的实质就是 tcp/ip请求。
须要相识三次握手划定规矩竖立衔接以及断开衔接时的四次挥手。
tcp将http长报文划分为短报文，经由过程三次握手与效劳端竖立衔接，举行牢靠传输。

三次握手：
1.客户端给效劳器发确实是当前效劳器
2.效劳器给客户端回应，我是你要接见的当前效劳器
3.客户端回应，我是客户端

四次挥手：
1.提议者：封闭主动传输信息的通道，只能吸收信息
2.接受者：收到通道封闭的信息
3.接受者：也封闭主动传输信息的通道
4.提议者：吸收到数据，封闭通道，两边没法通讯

tcp/ip的并发限定

阅读器对统一域名下并发的tcp衔接是有限定的（2-10个不等）。
而且在http1.0中每每一个资本下载就须要对应一个tcp/ip请求。
所以针对这个瓶颈，又涌现了许多的资本优化计划。（感兴趣的朋侪请自行搜刮，材料许多）

get和post的辨别

这个东西网上的材料也许多，这儿就也许形貌一下在tcp/ip层面的辨别，在http层面的辨别请读者自行搜刮：
get和post实质都是tcp/ip。
get会发作一个tcp数据包，post两个。

细致就是：

get请求时，阅读器会把 headers和 data一同发送出去，效劳器响应200（返回数据），
post请求时，阅读器先发送 headers，效劳器响应 100continue，阅读器再发送 data，效劳器响应200（返回数据）。

然后有读者能够之前相识过OSI的七层：物理层、 数据链路层、 收集层、 传输层、 会话层、 示意层、 运用层

这儿就不班门弄虎了，列一下内容，须要深切明白的读者请自行搜刮，盘算机收集相干的材料。

1.运用层(dns,http) DNS剖析成IP并发送http请求
2.传输层(tcp,udp) 竖立tcp衔接（三次握手）
3.收集层(IP,ARP) IP寻址
4.数据链路层(PPP) 封装成帧
5.物理层(运用物理介质传输比特流) 物理传输（然后传输的时刻经由过程双绞线，电磁波等种种介质）
6.示意层：重要处置惩罚两个通讯系统中交流信息的示意体式格局，包括数据花样交流，数据加密与解密，数据紧缩与终端范例转换等
7.会话层：它细致治理差别用户和历程之间的对话，如掌握上岸和注销历程

3. 从效劳器吸收到请求到对应背景吸收到请求

后端的操纵有点多，我这儿也就不秀本身知识面低下了，哈哈

负载平衡

关于大型的项目，由于并发接见量很大，所以每每一台效劳器是吃不消的，所以平常会有若干台效劳器构成一个集群，然后合营反向代办完成负载平衡。（听说如今node在微效劳的项目方面愈来愈猛，大并发也不在话下，正在研讨node，愿望背面能写一个心得）

简朴的说：用户提议的请求都指向调理效劳器（反向代办效劳器，比方安装了nginx掌握负载平衡），然后调理效劳器依据现实的调理算法，分派差别的请求给对应集群中的效劳器实行，然后调理器守候现实效劳器的HTTP响应，并将它反馈给用户。

背景的处置惩罚

平常背景都是布置到容器中的，所以平常为：

1.先是容器接受到请求（如tomcat容器）
2.然后对应容器中的背景递次吸收到请求（如java递次）
3.然后就是背景会有本身的一致处置惩罚，处置惩罚完后响应响应结果

归纳综合下：
1.平常有的后端是有一致的考证的，如平安阻拦，跨域考证
2.假如这一步不相符划定规矩，就直接返回了响应的http报文（如谢绝请求等）
3.然后当考证经由过程后，才会进入现实的背景代码，此时是递次吸收到请求，然后实行（比方查询数据库，大批盘算等等）
4.等递次实行终了后，就会返回一个http响应包（平常这一步也会经由多层封装）
5.然后就是将这个包从后端发送到前端，完成交互

4.背景和前台的http交互

前后端交互时，http报文作为信息的载体。

http报文构造
报文平常包括了： 通用头部， 请求/响应头部， 请求/响应体。学过盘算机收集的读者应超等熟习。

通用头部
这也是开辟人员见过的最多的信息，包括以下：

Request Url: 请求的web效劳器地点
Request Method: 请求体式格局（Get、POST、OPTIONS、PUT、HEAD、DELETE、CONNECT、TRACE）
Status Code: 请求的返回状况码，如200代表胜利
Remote Address: 请求的长途效劳器地点（会转为IP）
比方，在跨域谢绝时，多是method为 options，状况码为 404/405等（固然，现实上能够的组合有许多）。

个中，Method的话平常分为两批次：

HTTP1.0定义了三种请求要领： GET, POST 和 HEAD要领。
HTTP1.1新增了五种请求要领：OPTIONS, PUT, DELETE, TRACE 和 CONNECT 要领。

置信晓得RESTFUL的读者应当很熟习，如今在前端后端开辟运用频仍的也就是get,post,put,delete，也是我们熟知的四大操纵"增编削查"。

状况码：这是举行要乞降回应的症结信息，官方有最全的状况码信息，这儿就列几个罕见的：

200——表明该请求被胜利地完成，所请求的资本发送回客户端
304——自从上次请求后，请求的网页未修正过，请客户端运用当地缓存
400——客户端请求有错（比方能够是平安模块阻拦）
401——请求未经受权
403——制止接见（比方能够是未登录时制止）
404——资本未找到
500——效劳器内部毛病
503——效劳不可用

其他的请读者自行去搜刮官方引见。

关于状况码：
数字1开首的示意：请求已吸收，继承处置惩罚
数字2开首的示意：请求胜利，已被效劳器胜利处置惩罚
数字3开首的示意：须要客户端采用进一步的操纵才完成请求
数字4开首的示意：客户端看起来能够发作了毛病，阻碍了效劳器的处置惩罚
数字5开首的：示意效劳器在处置惩罚请求的历程当中有毛病或许异常状况发作，也有多是效劳器意想到以当前的软硬件资本没法完成对请求的处置惩罚

请求/响应头部

要乞降响应头部也是剖析经经常使用到的。经常使用的请求头部（部份）：

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：效劳端返回的实体内容的范例
Date：数据从效劳器发送的时候
Cache-Control：关照阅读器或其他客户，什么环境能够平安的缓存文档
Last-Modified：请求资本的末了修正时候
Expires：应当在什么时刻以为文档已由期,从而不再缓存它
Max-age：客户端的当地资本应当缓存若干秒，开启了Cache-Control后有用
ETag：请求变量的实体标签的当前值
Set-Cookie：设置和页面关联的cookie，效劳器经由过程这个头部把cookie传给客户端
Keep-Alive：假如客户端有keep-alive，效劳端也会有响应（如timeout=38）
Server：效劳器的一些相干信息

请求头部和响应头部是有对应关联的：比方
1.请求头部的 Accept要和响应头部的 Content-Type婚配，不然会报错。
2.跨域请求时，请求头部的 Origin要婚配响应头部的 Access-Control-Allow-Origin，不然会报跨域毛病。
3.在运用缓存时，请求头部的 If-Modified-Since、 If-None-Match离别和响应头部的 Last-Modified、 ETag对应。

更多的对应关联请读者自行搜刮。

请求/响应实体

做http请求时，除了头部，另有音讯实体，平常来讲，请求实体中会将一些须要的参数都放入进入（用于post请求）。比方实体中能够放参数的序列化情势（ a=1&b=2这类），或许直接放表单对象（ FormData对象，上传时能够混合参数以及文件），等等。

而平常响应实体中，就是放效劳端须要传给客户端的内容。平常如今的接口请求时，实体中就是关于的信息的json花样。

cookie以及优化

cookie是阅读器的一种当地存储体式格局，平经常使用来协助客户端和效劳端通讯的，经常使用来举行身份校验，连系效劳端的session运用。

经常使用的场景以下：

用户上岸后，效劳端会天生一个session，session中有关于用户的信息（如用户名、暗码等），然后会有一个sessionid（相称因而效劳端的这个session对应的key），然后效劳端在登录页面中写入cookie，值就是:jsessionid=xxx，然后阅读器当地就有这个cookie了，今后接见同域名下的页面时，自动带上cookie，自动磨练，在有用时候内无需二次上岸。

平常来讲，cookie是不许可寄存敏感信息的（万万不要明文存储用户名、暗码），由于异常不平安，假如一定要强行存储，起首，一定要在cookie中设置 httponly（如许就没法经由过程js操纵了）。

别的，由于在同域名的资本请求时，阅读器会默许带上当地的cookie，针对这类状况，在某些场景下是须要优化的。

比方以下场景：

客户端在域名A下有cookie（这个能够是上岸时由效劳端写入的）
然后在域名A下有一个页面，页面中有许多依靠的静态资本（都是域名A的，比方有20个静态资本）
此时就有一个题目，页面加载，请求这些静态资本时，阅读器会默许带上cookie
也就是说，这20个静态资本的http请求，每一个都得带上cookie，而现实上静态资本并不须要cookie考证
此时就造成了较为严峻的糟蹋，而且也下降了接见速率（由于内容更多了）

固然了，针对这类场景，是有优化计划的（多域名拆分）。细致做法就是：

将静态资本分组，离别放到差别的子域名下
而子域名请求时，是不会带上父级域名的cookie的，所以就防备了糟蹋

说到了多域名拆分，这里再提一个题目，那就是：

在挪动端，假如请求的域名数过量，会下降请求速率（由于域名整套剖析流程是很消耗时候的，而且挪动端平常带宽都比不上pc）
此时就须要用到一种优化计划： dns-prefetch（让阅读器空闲时提早剖析dns域名，不过也请合理运用，勿滥用）

gzip紧缩

起首，明白 gzip是一种紧缩花样，须要阅读器支撑才有用（不过平常如今阅读器都支撑），而且gzip紧缩效力很好（高达70%摆布）。然后gzip平常是由 apache、 tomcat等web效劳器开启。

固然效劳器除了gzip外，也还会有别的紧缩花样（如deflate，没有gzip高效，且不盛行），所以平常只须要在效劳器上开启了gzip紧缩，然后以后的请求就都是基于gzip紧缩花样的，异常随意马虎。

长衔接与短衔接

起首看 tcp/ip层面的定义：

长衔接：一个tcp/ip衔接上能够一连发送多个数据包，在tcp衔接坚持时代，假如没有数据包发送，须要两边发检测包以保持此衔接，平常须要本身做在线保持（类似于心跳包）
短衔接：通讯两边有数据交互时，就竖立一个tcp衔接，数据发送完成后，则断开此tcp衔接

然后在http层面：

http1.0中，默许运用的是短衔接，也就是说，阅读器没举行一次http操纵，就竖立一次衔接，使命完毕就中缀衔接，比方每一个静态资本请求时都是一个零丁的衔接
http1.1起，默许运用长衔接，运用长衔接会有这一行 Connection:keep-alive，在长衔接的状况下，当一个网页翻开完成后，客户端和效劳端之间用于传输http的tcp衔接不会封闭，假如客户端再次接见这个效劳器的页面，会继承运用这一条已竖立的衔接

注重： keep-alive不会永久坚持，它有一个持续时候，平常在效劳器中设置（如apache），别的长衔接须要客户端和效劳器都支撑时才有用。

http 2.0

http2.0不是https，它相称因而http的下一代范例（比方https的请求能够是http2.0范例的）。然后简述下http2.0与http1.1的显著差别点：

http1.1中，每请求一个资本，都是须要开启一个tcp/ip衔接的，所以对应的结果是，每一个资本对应一个tcp/ip请求，由于tcp/ip本身有并发数限定，所以当资本一多，速率就显著慢下来
http2.0中，一个tcp/ip请求能够请求多个资本，也就是说，只需一次tcp/ip请求，就能够够请求若干个资本，支解成更小的帧请求，速率显著提拔。

所以，假如http2.0周全运用，许多http1.1中的优化计划就无需用到了（比方打包成精灵图，静态资本多域名拆分等）。
然后简述下http2.0的一些特征：

多路复用（即一个tcp/ip衔接能够请求多个资本）
首部紧缩（http头部紧缩，削减体积）
二进制分帧（在运用层跟传送层之间增加了一个二进制分帧层，革新传输机能，完成低耽误和高吞吐量）
效劳器端推送（效劳端能够对客户端的一个请求发出多个响应，能够主动关照客户端）
请求优先级（假如流被给予了优先级，它就会基于这个优先级来处置惩罚，由效劳器决议须要若干资本来处置惩罚该请求。）

https

https就是平安版本的http，比方一些付出等操纵基础都是基于https的，由于http请求的平安系数太低了。

简朴来看，https与http的辨别就是： 在请求前，会竖立ssl链接，确保接下来的通讯都是加密的，没法被随意马虎截取剖析

平常来讲，假如要将网站升级成https，须要后端支撑（后端须要请求证书等），然后https的开支也比http要大（由于须要分外竖立平安链接以及加密等），所以平常来讲http2.0合营https的体验更佳（由于http2.0更快了）

平常来讲，重要关注的就是SSL/TLS的握手流程：

1.阅读器请求竖立SSL链接，并向效劳端发送一个随机数–Client random和客户端支撑的加密要领，比方RSA加密，此时是明文传输。
2.效劳端从中选出一组加密算法与Hash算法，复兴一个随机数–Server random，并将本身的身份信息以证书的情势发还给阅读器 （证书里包括了网站地点，非对称加密的公钥，以及证书颁布机构等信息）
3.阅读器收到效劳端的证书后
    考证证书的正当性（颁布机构是不是正当，证书中包括的网址是不是和正在接见的一样），假如证书信托，则阅读器会显现一个小锁头，不然会有提醒
    用户吸收证书后（不论信不信托），阅读会临盆新的随机数–Premaster secret，然后证书中的公钥以及指定的加密要领加密 Premastersecret，发送给效劳器。
    运用Client random、Server random和Premaster secret经由过程一定的算法天生HTTP链接数据传输的对称加密key- session key
    运用约定好的HASH算法盘算握手音讯，并运用天生的 session key对音讯举行加密，末了将之前天生的一切信息发送给效劳端。
4.效劳端收到阅读器的复兴
    运用已知的加解密体式格局与本身的私钥举行解密，猎取 Premastersecret
    和阅读器雷同划定规矩天生 session key
    运用 session key解密阅读器发来的握手音讯，并考证Hash是不是与阅读器发来的一致
    运用 session key加密一段握手音讯，发送给阅读器
5.阅读器解密并盘算握手音讯的HASH，假如与效劳端发来的HASH一致，此时握手历程完毕，

以后一切的https通讯数据将由之前阅读器天生的 session key并运用对称加密算法举行加密。

http的缓存

前后端的http交互中，运用缓存能很大程度上的提拔效力，而且基础上对机能有请求的前端项目都是必用缓存的。

强缓存与弱缓存
缓存能够简朴的划分红两种范例： 强缓存（ 200fromcache）与 协商缓存（ 304）
辨别以下：

强缓存（ 200fromcache）时，阅读器假如推断当地缓存未逾期，就直接运用，无需提议http请求
协商缓存（ 304）时，阅读器会向效劳端提议http请求，然后效劳端关照阅读器文件未转变，让阅读器运用当地缓存

关于协商缓存，运用 Ctrl+F5强制革新能够使得缓存无效。然则关于强缓存，在未逾期时，必需更新资本途径才提议新的请求（变动了途径相称因而另一个资本了，这也是前端工程化中经常使用到的技能）。

缓存头部简述
上述提到了强缓存和协商缓存，那它们是怎样辨别的呢？答案是经由过程差别的http头部掌握。
缓存中经常使用的几个头部：

If-None-Match/E-tag
If-Modified-Since/Last-Modified
Cache-Control/Max-Age
Prama/Expires

属于强缓存掌握的：

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

注重： Max-Age不是一个头部，它是 Cache-Control头部的值。

属于协商缓存掌握的：

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

能够看到，上述有提到 http1.1和 http1.0，这些差别的头部是属于差别http时代的。

头部的辨别
起首明白，http的生长是从http1.0到http1.1，而在http1.1中，出了一些新内容，弥补了http1.0的不足。

http1.0中的缓存掌握：

Pragma：严格来讲，它不属于特地的缓存掌握头部，然则它设置 no-cache时能够让当地强缓存失效（属于编译掌握，来完成特定的指令，重要是由于兼容http1.0，所以之前又被大批运用）
Expires：效劳端设置的，属于强缓存，用来掌握在划定的时候之前，阅读器不会发出请求，而是直接运用当地缓存，注重，Expires平常对应效劳器端时候，如 Expires：Fri,30Oct199814: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更准确，它是类似于指纹一样的东西，基于 FileEtagINodeMtimeSize天生，也就是说，只需文件变，指纹就会变，而且没有1s准确度的限定。

Max-Age比拟Expires？

Expires运用的是效劳器端的时候，然则有时刻会有如许一种状况-客户端时候和效劳端差别步。那如许，能够就会出题目了，造成了阅读器当地的缓存无用或许一向没法逾期，所以平常http1.1后不引荐运用 Expires。而 Max-Age运用的是客户端当地时候的盘算，因而不会有这个题目，因而引荐运用 Max-Age。

注重，假如同时启用了 Cache-Control与 Expires， Cache-Control优先级高。

E-tag比拟Last-Modified？

Last-Modified：
    表明效劳端的文件末了什么时候转变的
    它有一个缺点就是只能准确到1s，
    然后另有一个题目就是有的效劳端的文件会周期性的转变，致使缓存失效
E-tag：
    是一种指纹机制，代表文件相干指纹
    只需文件变才会变，也只需文件变就会变，
    也没有准确时候的限定，只需文件一遍，立马E-tag就不一样了
    假如同时带有 E-tag和 Last-Modified，效劳端会优先搜检 E-tag。

6. 阅读器吸收到http数据包后的剖析流程

衬着流程大抵以下：

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树。

Bytes → characters → tokens → nodes → DOM
假设有下面如许一个代码

<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>

阅读器的处置惩罚以下：

枚举个中的一些重点历程：

Conversion转换：阅读器将取得的HTML内容（Bytes）基于他的编码转换为单个字符
Tokenizing分词：阅读器根据HTML范例标准将这些字符转换为差别的标记token。每一个token都有本身奇特的寄义以及划定规矩集
Lexing词法剖析：分词的结果是取得一堆的token，此时把他们转换为对象，这些对象离别定义他们的属性和划定规矩
DOM构建：由于HTML标记定义的就是差别标签之间的关联，这个关联就像是一个树形构造一样。比方：body对象的父节点就是HTML对象，然后段略p对象的父节点就是body对象

末了的DOM树以下：

天生CSS划定规矩
Bytes → characters → tokens → nodes → CSSOM
有以下css代码：

body { font-size: 16px }
p { font-weight: bold }
span { color: red}
p span { display: none }
img { float: right }

cssom树：

当DOM树和CSSOM都有了后，就要最先构建衬着树了。

然后从衬着树最先天生我们看到的html页面。
在这个历程当中又一个小题目，从新构建和衬着页面：

从新构建，也称为Reflow，即回流。平常意味着元素的内容、构造、位置或尺寸发作了变化，须要从新盘算款式和衬着树
衬着页面，也称为Repaint，即重绘。意味着元素发作的转变只是影响了元素的一些表面之类的时刻（比方，背景色，边框色彩，笔墨色彩等），此时只须要运用新款式绘制这个元素就能够够了

回流的本钱开支要高于重绘，而且一个节点的回流每每回致使子节点以及同级节点的回流，所以优化计划中平常都包括，只管防备回流。

什么会引起回流？
1.页面衬着初始化
2.DOM构造转变，比方删除了某个节点
3.render树变化，比方削减了padding
4.窗口resize
5.最庞杂的一种：猎取某些属性，激发还流

许多阅读器会对回流做优化，会比及数目充足时做一次批处置惩罚回流，然则除了render树的直接变化，当猎取一些属性时，阅读器为了取得准确的值也会触发还流，如许使得阅读器优化无效，包括：

1.offset(Top/Left/Width/Height)
2.scroll(Top/Left/Width/Height)
3.cilent(Top/Left/Width/Height)
4.width,height
5.调用了getComputedStyle()或许IE的currentStyle

回流一定陪伴偏重绘，重绘却能够零丁涌现。所以平常会有一些优化计划，如：

1.削减逐项变动款式，最好一次性变动style，或许将款式定义为class并一次性更新
2.防备轮回操纵dom，竖立一个documentFragment或div，在它上面运用一切DOM操纵，末了再把它增加到window.document
3.防备屡次读取offset等属性。没法防备则将它们缓存到变量
4.将庞杂的元素相对定位或牢固定位，使得它离开文档流，不然回流价值会很高

注重：转变字体大小会激发还流

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!'));

资本外链的下载

上面引见了html剖析，衬着流程。但现实上，在剖析html时，会碰到一些资本衔接，此时就须要举行零丁处置惩罚了。简朴起见，这里将碰到的静态资本分为一下几大类（未枚举一切）：

CSS款式资本
JS剧本资本
img图片类资本
碰到外链时的处置惩罚

当碰到上述的外链时，会零丁开启一个下载线程去下载资本（http1.1中是每一个资本的下载都要开启一个http请求，对应一个tcp/ip链接）。

碰到CSS款式资本

CSS资本的处置惩罚有几个特性：

CSS下载时异步，不会壅塞阅读器构建DOM树
然则会壅塞衬着，也就是在构建render时，会比及css下载剖析终了后才举行（这点与阅读器优化有关，防备css划定规矩不停转变，防备了反复的构建）

有破例， media query声明的CSS是不会壅塞衬着的

碰到JS剧本资本

JS剧本资本的处置惩罚有几个特性：

壅塞阅读器的剖析，也就是说发明一个外链剧本时，需守候剧本下载完成并实行后才会继承剖析HTML
阅读器的优化，平常当代阅读器有优化，在剧本壅塞时，也会继承下载别的资本（固然有并发上限），然则虽然剧本能够并行下载，剖析历程仍然是壅塞的，也就是说必需这个剧本实行终了后才会接下来的剖析，并行下载只是一种优化罢了
defer与async，一般的剧本是会壅塞阅读器剖析的，然则能够加上defer或async属性，如许剧本就变成异步了，能够比及剖析终了后再实行

注重，defer和async是有辨别的： defer是耽误实行，而async是异步实行。

简朴的说（不睁开）：

async是异步实行，异步下载终了后就会实行，不确保实行递次，一定在 onload前，但不一定在 DOMContentLoaded事宜的前或后
defer是耽误实行，在阅读器看起来的结果像是将剧本放在了 body背面一样（虽然按范例应当是在 DOMContentLoaded事宜前，但现实上差别阅读器的优化结果不一样，也有能够在它背面）

碰到img图片类资本

碰到图片等资本时，直接就是异步下载，不会壅塞剖析，下载终了后直接用图片替代原有src的处所。

loaded和domcontentloaded

简朴的对照：

DOMContentLoaded 事宜触发时，仅当DOM加载完成，不包括款式表，图片(比方假如有async加载的剧本就不一定完成)
load 事宜触发时，页面上一切的DOM，款式表，剧本，图片都已加载完成了

7. CSS的可视化花样模子

html元素按什么划定规矩衬着，接下来提到的内容来发表

CSS中划定每一个元素都有本身的盒子模子（相称于划定了这个元素怎样显现）
然后可视化花样模子则是把这些盒子根据划定规矩摆放到页面上，也就是怎样规划
换句话说，盒子模子划定了怎样在页面里摆放盒子，盒子的相互作用等等

说到底： CSS的可视化花样模子就是划定了阅读器在页面中怎样处置惩罚文档树。
症结字：

包括块（Containing Block）
掌握框（Controlling Box）
BFC（Block Formatting Context）
IFC（Inline Formatting Context）
定位系统
浮动

CSS有三种定位机制： 一般流， 浮动， 相对定位

包括块（Containing Block）

一个元素的box的定位和尺寸，会与某一矩形框有关，这个框就称之为包括块。元素会为它的子孙元素竖立包括块，然则，并不是说元素的包括块就是它的父元素，元素的包括块与它的先人元素的款式等有关联。

比方：

根元素是最顶端的元素，它没有父节点，它的包括块就是初始包括块
static和relative的包括块由它近来的块级、单元格或许行内块先人元素的内容框（content）竖立
fixed的包括块是当前可视窗口
absolute的包括块由它近来的position 属性为 absolute、 relative或许 fixed的先人元素竖立
    假如其先人元素是行内元素，则包括块取决于其先人元素的 direction特征
    假如先人元素不是行内元素，那末包括块的地区应当是先人元素的内边距边境
    

掌握框（Controlling Box）

块级元素和块框以及行内元素和行框的相干观点
块框：

块级元素会天生一个块框（ BlockBox），块框会占有一整行，用来包括子box和天生的内容
块框同时也是一个块包括框（ ContainingBox），内里要么只包括块框，要么只包括行内框（不能混淆），假如块框内部有块级元素也有行内元素，那末行内元素会被匿名块框围困

假如一个块框在个中包括别的一个块框，那末我们强制它只能包括块框，因而别的文本内容天生出来的都是匿名块框（而不是匿名行内框）。

行内框：

一个行内元素天生一个行内框
行内元素能排在一行，许可摆布有别的元素

display的几个属性也能够影响差别框的天生：

block，元素天生一个块框
inline，元素发作一个或多个的行内框
inline-block，元素发作一个行内级块框，行内块框的内部会被看成块块来花样化，而此元素本身会被看成行内级框来花样化（这也是为何会发作 BFC）
none，不天生框，不再花样化构造中，固然了，另一个 visibility:hidden则会发作一个不可见的框

BFC（Block Formatting Context）

FC即花样高低文，它定义框内部的元素衬着划定规矩，比较笼统，比方：

FC像是一个大箱子，内里装有许多元素
箱子能够离隔内里的元素和表面的元素（所以外部并不会影响FC内部的衬着）
内部的划定规矩能够是：怎样定位，宽高盘算，margin摺叠等等
差别范例的框介入的FC范例差别，比方块级框对应BFC，行内框对应IFC。

注重，并不是说一切的框都邑发作FC，而是相符特定前提才会发作，只需发作了对应的FC后才会运用对应衬着划定规矩。

BFC划定规矩：

在块花样化高低文中，每一个元素左外边与包括块的左侧相打仗（关于从右到左的花样化，右外边打仗右侧），纵然存在浮动也是云云（所以浮动元素正常会直接切近它的包括块的左侧，与一般元素重合），除非这个元素也竖立了一个新的BFC。

总结几点BFC特性：

内部 box在垂直方向，一个接一个的安排
box的垂直方向由 margin决议，属于统一个BFC的两个box间的margin会堆叠
BFC地区不会与 floatbox堆叠（可用于排版)
BFC就是页面上的一个断绝的自力容器，容器内里的子元素不会影响到表面的元素。反之也云云
盘算BFC的高度时，浮动元素也介入盘算（不会浮动坍塌）

怎样触发BFC？

根元素
float属性不为 none
position为 absolute或 fixed
display为 inline-block, flex, inline-flex， table， table-cell， table-caption
overflow不为 visible

这里提下， display:table，它本身不发作BFC，然则它会发作匿名框（包括 display:table-cell的框）。

IFC（Inline Formatting Context）

IFC即行内框发作的花样高低文。

IFC划定规矩

在行内花样化高低文中，框一个接一个地程度分列，出发点是包括块的顶部。程度方向上的 margin，border 和 padding 在框之间取得保存，框在垂直方向上能够以差别的体式格局对齐：它们的顶部或底部对齐，或依据个中笔墨的基线对齐。

行框

包括那些框的长方形地区，会构成一行，叫做行框。行框的宽度由它的包括块和个中的浮动元素决议，高度的一定由行高度盘算划定规矩决议。

行框的划定规矩：

假如几个行内框在程度方向没法放入一个行框内，它们能够分派在两个或多个垂直堆叠的行框中（即行内框的支解）
行框在堆叠时没有垂直方向上的支解且永不堆叠
行框的高度老是充足包容所包括的一切框。不过，它能够高于它包括的最高的框（比方，框对齐会引起基线对齐）
行框的左侧打仗到其包括块的左侧，右侧打仗到其包括块的右侧

连系补充下IFC划定规矩

浮动元素能够会处于包括块边沿和行框边沿之间，只管在雷同的行内花样化高低文中的行框一般具有雷同的宽度（包括块的宽度），它们能够会因浮动元素缩短了可用宽度，而在宽度上发作变化。

统一行内花样化高低文中的行框一般高度不一样（如，一行包括了一个高的图形，而别的行只包括文本），当一行中行内框宽度的总和小于包括它们的行框的宽，它们在程度方向上的对齐，取决于 text-align 特征。空的行内框应当被疏忽。

即不包括文本，保存空缺符，margin/padding/border非0的行内元素，以及其他通例流中的内容(比方，图片，inline blocks 和 inline tables)，而且不是以换行完毕的行框，必需被看成零高度行框看待。

总结：

行内元素老是会运用IFC衬着划定规矩
行内元素会运用IFC划定规矩衬着，比方 text-align能够用来居中等
块框内部，关于文本这类的匿名元素，会发作匿名行框围困，而行框内部就运用IFC衬着划定规矩
行内框内部，关于那些行内元素，一样运用IFC衬着划定规矩
别的， inline-block，会在元素外层发作IFC（所以这个元素是能够经由过程 text-align程度居中的），固然，它内部则根据BFC划定规矩衬着

比拟BFC划定规矩来讲，IFC能够越发笼统（由于没有那末条理清晰的划定规矩和触发前提），但总的来讲，它就是行内元素本身怎样显现以及在框内怎样摆放的衬着划定规矩，如许形貌应当更轻易明白。

关于css的一些别的划定规矩，人人能够去搜搜：

如通例流，浮动，相对定位等辨别
如浮动元素不包括在通例流中
如相对定位，相对定位， Fixed定位等辨别
如 z-index的分层显现机制等

8. JS引擎剖析历程

这个部份的内容请参考这儿：JS引擎剖析历程
直接略过了

9. 跨域、web平安

跨域

为何会跨域：

在阅读器同源战略限定下，向差别源（差别协定、差别域名或许差别端口）发送XHR请求，阅读器以为该请求不受信托，制止请求，细致表现为请求后不正常响应

举个栗子：

那要怎样搞呢？网上的处理办法也许多，这儿列一些：

1.jsonp
2.cors
3.document.domain
4.POSTmessage

想深切看的能够阅读一下这个 跨域的经常使用处理体式格局

web平安

这个东西，我们在口试的时刻一定会被问到xss进击的题目，人人自行搜刮把，这个题目的处理计划也超等多，官方文档也引见很细致，这儿就不整了

参考：参考文章

有大佬也总结过了很细致的内容，我照搬了点儿内容，勿喷，只是进修一下。