强缓存是浏览器未向服务器发送HTTP请求直接使用浏览器本地缓存的资源（状态码 200 from cache）。

• Cache-Control
  • max-age：设置强缓存的相对时间
  • no-cache：浏览器不进行缓存（直接进行协商缓存）
  • no-store：浏览器和服务器都不进行缓存（不使用任何缓存，由服务器返回资源）
  • public/private：代理服务器和浏览器都可以缓存/只有浏览器可以缓存
• Expires（HTTP1.0使用 优先级低于Cache-Control）
  • 和Cache-Control不同，描述的是绝对时间

协商缓存是浏览器询问服务器所请求的文件是否存在更新，由服务器返回更新后的文件（状态码200）或者告知浏览器继续使用本地缓存（状态码304）。

• Etag和If-None-Match
  • 服务器向浏览器第一次返回资源时，在响应首部字段里增加Etag（和文件内容对应的唯一值，随内容改变而改变）
  • 浏览器记录Etag，在下次请求资源时在请求首部字段的If-None-Match填充Etag值
  • 如果If-None-Match值和服务器记录的Etag值不一致，则返回更新后文件，否则，使用浏览器缓存
• Last-Modified和If-Modified-Since
  • 和Etag和If-None-Match类似
  • 比对的是更新日期，存在极小的时间差

设置为display:flex的元素为容器，子元素自动成为flex容器的项目，float、clear和vertical-align属性失效。

• 容器
  • flex-direction
    • 定义主轴的方向（水平/垂直）
    • row || row-reverse || column || column-reverse
  • flex-wrap
    • 定义项目在主轴上如何换行
    • nowrap || wrap || wrap-reverse
  • flex-flow
    • flex-direction和flex-wrap的组合写法
  • justify-content
    • 定义项目在主轴上的对齐方式
    • flex-start || flex-end || center || space-between || space-around
  • align-items
    • 定义项目在垂直轴上的对齐方式
    • flex-start || flex-end || center || stretch || baseline
    • 当项目未定义垂直轴上的高度（或宽度时），默认为stretch
  • align-content
    • 定义多根主轴方向的轴线的在垂直轴上的对齐方式（只有一根轴线时无效）
    • flex-start || flex-end || center || space-between || space-around
• 项目
  • order
    • 值的大小代表项目的排列顺序（数值小的排在前面）
  • flex-grow
    • 定义项目的放大比例，默认值为0，表示即使容器有空余也不放大。
  • flex-shrink
    • 定义项目的缩小比例，默认值为1，表示容器容量不足时等比缩小。
  • flex-basis
    • 定义项目在主轴方向上所占比例，默认值为auto
  • flex
    • flex-grow、flex-shrink、flex-basis的缩写值，后两个属性为可选项，默认值为1 0 auto
    • 快捷值auto表示 1 1 auto
    • 快捷值none表示 0 0 auto
  • align-self
    • 值不为auto时覆盖容器的align-items
    • 可选值和align-items一致

第一阶段中，经过以下几个步骤获取到了服务器返回的指定资源：

1. DNS解析
2. 发送HTTP请求（HTTPS的话在2和3之间还有SSL连接的步骤）
3. TCP连接
4. 查询MAC地址
5. 服务器解析请求，返回网页资源

浏览器获取到网页资源之后进行渲染：

• 浏览器同时分别解析HTML文件和CSS文件得到DOM树和CSS树
• DOM树和CSS树构成渲染树
• 解析JS文件并执行

利用vue等框架构建的单页面应用，渲染页面的步骤略有不同：

• 请求并获取入口文件信息index.html
• 下载index.html内联的CSS文件和JS文件
• 执行JS文件渲染DOM树 完成页面展示

• 无特殊属性的script标签会阻塞HTML解析，解析到该标签时暂停HTML解析并发起请求以下载文件，脚本文件下载并解析完成会才会继续解析后面的HTML
• defer=延迟
  • 对应的脚本文件会和HTML解析同步发起请求，但会等HTML解析完再进行解析
  • 在DOMContentLoad事件前完成脚本解析
  • 和将无属性script标签放在body最下面的效果一致
  • 多个同样属性的标签会依次请求解析
• async=异步
  • 脚本文件的下载不阻塞HTML解析的主流程
  • 在load事件前完成脚本解析
  • 多个同样属性的标签根据下载完成的顺序进行解析
  • 类似异步加载的图片、视频等

• 全局守卫（对所有路由均有效）
  • beforeEach
  • beforeResolve（所有组件内路由和异步组件被解析之后）
  • afterEach（不接受next函数 不改变导航本身）
• 路由守卫（配置路由时可直接定义）
  • beforeEnter
• 组件守卫（单个路由组件独立的守卫，类似组件的生命周期）
  • beforeRouteEnter（不能访问组件实例）
  • beforeRouteUpdate
  • beforeRouteLeave

执行顺序：

1. 触发导航
2. 全局前置守卫beforeEach
3. 路由守卫beforeEnter
4. 解析异步路由组件
5. 组件beforeRouteEnter
6. beforeResolve
7. 导航被确认
8. 全局后置守卫afterEach
9. 组件生命周期beforeCreate→created
10. 组件生命周期beforeMount→mounted
11. beforeRouteEnter的异步函数next()
12. 触发离开当前路由操作→beforeRouteLeave

Attention：

• beforeEach的执行顺序先于main.js中初始化的app组件的生命周期（如mounted）

• 多行模式（m标志）
  • ^和$会匹配每行的头尾（由\n或\r分割），而不是整个字符串的头尾
• \s会匹配换行符和回车符
• 相关方法
  • RegExp方法
    • test: boolean
    • exec
      • 返回一个结果数组
  • String方法
    • match
      • 没有g标志，只返回第一个完整匹配及捕获组
      • 有g标志，返回所有的匹配项
    • matchAll
      • 返回一个包含所有匹配正则表达式的结果及分组捕获组的迭代器。
    • replace
    • search
      • 类似test，用于判断是否存在匹配项
    • split

HTTP请求包括：

• 请求方法（常用GET POST）
• 请求内容
• 协议版本号
• 请求首部字段（可选）
• 请求主体（可选）

HTTP响应包括：

• 协议版本号
• 状态码
• 状态码对应的原因短语
• 响应首部字段（可选）
• 响应主体（可选）

HTTP协议是不保存状态的，即服务器和客户端均不保存通讯结果。
为了应对需要记录用户登录等场景时，使用Cookie机制：

• 验证用户登录成功后，服务器返回的响应首部字段中增加Set-Cookie字段
• 客户端取出Set-Cookies字段后加在接下来的请求首部字段的Cookie中
• 服务端识别请求首部字段的Cookie，确认用户登录状态返回响应

Cookie包含：

• NAME=content（关键内容）
• expires=date （过期时间）
• HttpOnly （不可通过JavaScript访问，避免XSS攻击）
• Secure （仅在HTTPS协议中使用）
• path （可适用的文件目录 默认是文档所在目录）
• domain （可适用的域名 默认是生成Cookie的域名）

这道经典面试题考察的方面很广，我将整个过程分为两个阶段来叙述。
第一阶段：从URL输入到浏览器获取页面资源
第二阶段：获取页面资源后渲染页面

• URL是能够定位到互联网中唯一资源的标识符

TCP/IP四层模型：

• 应用层

  • DNS 将域名解析为IP地址
    • DNS缓存：浏览器缓存> 系统缓存 >路由器缓存>IPS服务器缓存>根域名服务器缓存>顶级域名服务器缓存>主域名服务器缓存
    • CDN的原理是将资源分发到多台服务器上，DNS根据客户端的位置、服务器的负载量等解析出相应最合适的服务器IP，将不同的用户引导到不同的服务器上，起到负载均衡
  • HTTP 互联网上所有服务器遵循的传递资源的协议
    • HTTPS=HTTP + SSL「后续讲解」

• 传输层

  • TCP（三步握手）分割报文追加序号
    • 客户端→服务器 【SYN】
    • 服务器→客户端【SYN/ACK】
    • 客户端→服务器【ACK】

• 网络层

  • ARP 将IP地址解析为MAC地址
  • IP 将TCP分割后的数据包加上MAC地址转发给链路层

• 链路层

  • 服务器的链路层接收到客户端链路层发送的数据，再进行逐层解析，直到服务器的应用层接收到数据才算接收到客户端的请求，服务器再将客户端请求的数据逐层包装返回。

到此，第一阶段结束。

HTTP协议的缺点：

• 明文传输→其他服务器可以监听，信息泄露
• 没有确认返回来源的真实性→获得的response可能被篡改
• 没有确认response的完整性→response可能存在丢失

HTTP+加密+认证+完整性=HTTPS

• 对称加密：加密和解密的钥匙是同一把，客户端要用该秘钥加密时需要服务器通过网络传递，因此秘钥同样存在被窃听的可能，加密也可以用窃听到的秘钥进行解密。
• 非对称加密：使用一对公私钥来加密和解密，服务端将公钥通过网路传递给客户端，客户端使用公钥加密数据传递给客户端，客户端使用保存在本地的私钥解密，数据量大时，加解密速度慢。
• 混合加密方法：使用非对称加密来传递密文，用该密文对接下来服务器和客户端交换的数据进行对称加密。融合了两者的优点。

SSL使用的就是混合加密方法，步骤如下：

• 客户端将支持的加密组件等发送给服务端
• 服务端返回包含公钥的证书和服务端支持的加密组件（筛选了客户端也支持的加密组件）
• 证书中的公钥是提交至AC组织，并由AC组织的私钥进行加密后与证书同步绑定的，客户端可以通过浏览器提前内置的AC组件的公钥对其进行解密，得到服务器的公钥，并验证服务器的身份（防止中间人攻击）
• 客户端生成随机密码串，并使用公钥加密后发送给服务端
• 服务端使用本地私钥解密得到随机密码串，接下来的数据传输均通过该密码串进行加解密

• 是三/四步不是三/四次

• 三步握手的目的是服务端和客户端均能确认双方发送信息和接收信息的功能是正常的。

  ①客户端发送SYN至服务端（SYN=1 seq=x）：

  ​ 服务端确认自己的接收信息能力和客户端的发送信息能力是正常的。

  ②服务端发送SYN/ACK至客户端（SYN=1 ACK=1 seq=y ACKnum=x+1）：

  ​ 客户端确认自己和服务端的接收、发送信息能力均是正常的。

  ③客户端发送ACK至服务端（ACK=1 ACKnum=y+1）：

  ​ 服务端确认自己和服务端的接收、发送信息能力均是正常的。

• 四次挥手是由于双向的数据交换各需要两次通信。

  ①客户端发送FIN至服务端（FIN=1 seq=x）

  ②服务端发送ACK至客户端（ACK=1 ACKnum=x+1）：

  ​ 至此由客户端至服务端方向的通信关闭，服务端仍可以发送数据至客户端。

  ③服务端发送FIN至客户端（FIN=1 seq=y）：

  ​ 服务端之所以不能合并②③为一步，是因为数据是否已发送完毕是由上层应用层决定的，不能在接收到对方关闭连接的信号后就立刻关闭己方的连接。

  ④客户端发送ACK至服务端（ACK=1 ACKnum=y+1）

  ​

• TCP的报文是有序列号的，为了确保以正确的序列提供给上层协议，拿到大序列号的数据后会保持不提供给上层，直到缺失的小序列号报文被填满，因此TCP天然存在线头阻塞的问题。

• 0.9→1.0
  • 传输的内容从单纯的文本升级到图片、视频等
• 1.0→1.1
  • 升级前每次HTTP请求都要进行TCP连接、断开，升级后支持持久连接（TCP连接后不明确断开则持续连接）、管道传输（同时发送多个HTTP请求）
• 1.1→2.0
  • 虽然支持同时发送多个请求，但升级前服务器只能按顺序单线程处理多个请求，一旦某个请求耗时较长，会阻塞其他请求（线头阻塞），升级后支持多路复用。
  • 请求头部压缩
    • 服务器和客户端维护动态字典，只需要传输请求头对应的索引。
  • 服务端推送（server push）
    • 客户端请求index.html，服务端会解析index.html里引用的其他文件，在客户端还没发起相关请求前，将对应资源和index.html一起返回。