【前端面试】浏览器_前端面试浏览器

浏览器内核

内核主要分成两部分：

• 渲染引擎
  职责是渲染，即在浏览器窗口中显示所请求的内容。
  默认情况下，渲染引擎可以显示html、xml文档及图片，它也可以借助插件显示其他类型数据，例如使用PDF阅读器插件，可以显示PDF格式。
• JS引擎
  解析和执行JavaScript来实现网页的动态效果。

最初，浏览器中渲染引擎和JS引擎的区分不是很明确，逐渐的，JS引擎越来越独立，内核倾向于只渲染引擎。

常见的浏览器内核：

• Trident
  IE浏览器的内核，但是这个内核对真正的网页标准支持不是很好，并且微软长时间不更新Trident内核，导致Trident内核和W3C标准脱节；并且Trident内核存在大量Bug以及安全问题没有得到解决，用户逐渐放弃浏览器。
• Gecko
  Firefox和Flock采用的内核。功能庆大、丰富，能够支持很多复杂的网页效果以及浏览器扩展接口，但是也会消耗很多资源，例如内存等。
• Presto
  Opera曾经采用，该内核被称为公认的浏览网页速度最快的内核。
  由于先天优势的存在，在处理JS脚本等脚本语言时，比其他内核快3倍左右，但是缺点也很明显，为了追求更快的速度，从而丢失了一些网页的兼容性。
• Webkit
  Safari采用Webkit内核。
  优点是网页浏览速度较快，不及Presto，但是胜于Gecko和Trident内核；
  缺点是网页代码的兼容性较低，对于编写不标准的网页不友好，可能无法正确显示。
  Webkit内核的前身是KDE小组的KHTML引擎，Webkit是KHTML的一个开源分支。
• Blink
  由谷歌在Chromiun项目中研发，内置于Chrome浏览器之中。
  Blink内核也是Webkit的一个分支，目前Blink引擎是谷歌公司与Opera共同研发，Opera弃用了Presto内核，加入谷歌阵营。

常见浏览器的内核：

• IE： Trident内核，也称为IE内核
• Chrome：统称为Chromiun内核或Chrome内核，以前是Webkit内核，现在是Blink内核
• Firefox：Gecko内核，俗称Firefox内核
• Safari：Webkit内核
• Opera：最初是自有的Presto，后来加入谷歌大军，从Webkit然后到Blink内核
• 360、猎豹：IE + Chrome双内核
• 搜狗、傲游、QQ：Trident（兼容模式）+ Webkit（高速模式）
• 百度、世界之窗：IE内核

浏览器的标签页是进程还是线程

当浏览器打开两个标签页，对应的是两个进程。
每个标签页都会在浏览器中独立运行，有自己的渲染进程、JavaScript引擎等。

浏览器的标准模式和怪异模式

标准模式：浏览器按照W3C标准解析执行代码
怪异模式：浏览器根据自己的方式解析执行代码，因为不同浏览器解析执行方式不太一样，所以叫怪异模式。
区别：
1. 在怪异模式下，盒模型为怪异盒模型；而在标准模式下为标准盒模型
2. 图片元素的垂直对齐方式对于行内元素和table-cell元素，在标准模式下vertical-align属性默认值是baseline，而在怪异模式下，table单元格中的图片的vertical-align属性默认值是bottom，因此在图片底部会有几像素的空间。
3. 元素中的字体css中font的属性都是可以继承的，怪异模式下，对于table元素，字体的某些元素不能从其他封装元素继承中得到，特别是font-size属性。
4. 内联元素的尺寸，标准模式下，non-replaced inline元素无法自定义大写，怪异模式下，定义元素的宽高会影响元素的尺寸。
5. 元素的百分比高度，当一个元素使用百分比高度时，在标准模式下，高度取决于内容变化，在怪异模式下，百分比会被准确应用。
6. 元素溢出的处理标准模式下，overflow取值默认值为visible，在怪异模式下，这个溢出会被当做扩展box对待，就是元素的大小由内容决定，溢出不会被裁剪，元素框自动调整，包含溢出内容。

浏览器缓存机制

缓存分为两种：强缓存和协商缓存，根据响应的header内容来决定。

1. 强缓存

• 原理：
  在浏览器内置数据库中缓存每次请求中 “可以被缓存”（ 受到一些关键字的管控）的静态资源如 image, css, js 文件
  当第二次请求被缓存过的资源时候，会通过校验两个字段 Expires 和 Cache-Control 的max-age字段（注意，Expires 是 http1.0 的产物， Cache-Control 则是 http1.1 的产物。 两者同时存在， 或者只存在其中之一， 都可以触发强制缓存。
  当满足字段约束的情况下， 浏览器就不会向服务器发送请求而是直接从服务器返回数据， 同时其状态码为 200。

• 相关字段有：如果cache-control与expires同时存在的话，cache-control的优先级高于expires。

  属性	作用
  Expires	响应过期的日期和时间
  Cache-Control	指定请求和响应遵循的缓存机制

  强制缓存主要取决于两个字段 Expires 和 Cache-Control 中的 max-age 字段， 在两个响应头都存在的情况下， 其流程如图
  
  当两个字段同时存在得到时候， Cache-Control 中的 max-age 字段字段优先级会稍微高一点， 当 Cache-Control 中的 max-age 字段校验成功，会直接返回浏览器内置数据库的缓存， 失效时才会将决策权传递给 Expires 字段判断。
  这样设计的原因，大概是因为 Expires 字段在设计时存在了这么一个缺陷——Expires字段返回的是服务器的时间， 而非客户端的本机时间。 当存在时差， 或者客户修改本地时间的情况下 Expires 字段会存在失效的可能性。
  max-age在http 1.1 协议中添加，是相对时间即客户端获取到这个文件多少秒后失效， 其判别权力全权交由浏览器， 这会相对更准确些。

3. 协商缓存
   相关字段有Last-Modified/If-Modified-Since，Etag/If-None-Match。

• ETag 是一个用于映射 web 资源的映射 token，这个 token 应该满足唯一对应到一 个web服务器上的静态资源（具体实现通常是提取文件相关信息进行hash和base64编码等操作）
• Last-Modified 则通常是文件最后更新的日期时间戳
  
  浏览器首次向服务器请求数据 A， 服务器正常返回数据，同时在响应头中放入 ETag 和 Last-Modified 两个新字段。
  当浏览器第二次向服务器请求数据 A 时， 浏览器会自动地在请求头附上 If-None-Match 和 If-Modified-Since 两个字段（分别对应的是 ETag 和 Last-Modified 的值，两两相等）， 然后由服务器端进行校验， 校验通过的话（表明数据有效）， 服务器会直接返回 状态码 304 ，且不携带响应体的报文段， 这相当于告诉浏览器：当前缓存有效， 可以直接使用！ 校验失败则会和首次请求一样， 返回状态码为200且携带数据响应体的报文段， 同时这个响应头会带上新的ETag 和Last-Modified， 为下一次协商缓存做好铺垫 。

注意， 在不用框架的情况下， 协商缓存需要由后端开发人员手动实现，因此 ETag 和 Last-Modified 两个字段的优先级取决于开发者， 但是 Last-Modified 这个字段可以记录的时间戳精确度是有一定限制的，如果连续多次数据更新在精确度范围外， 会产生精确度丢失， 因此通常会让ETag 的优先级高于 Last-Modified 字段（类似于Cache-control中max-age一样， 属于是后续改进协议的一个新字段， 因此优先级一般会高点）

3. 强缓存协商缓存并存的情况
   默认情况下， 浏览器会优先考量强制缓存的情况， 当强制缓存生效的情况下， 请求并不会到达服务器， 因此也就不会触发协商缓存。 当强制缓存失效的时候， 浏览器便会将请求传递到服务器， 于是服务器又会开始校验 If-Modified-Since 和 If-None-math 两个字段， 重复上述协商缓存的一个执行流程

浏览器输入网址到页面渲染全过程

原文章地址
根据文章整理：

1. URL输入
   首先，检查输入的URL是否合法
   如果合法，判断url是否完整，如果不完整，浏览器可能会对地址进行猜测，补全地址的前缀或者后缀
   如果不合法，将输入内容作为搜索条件，使用用户设置的默认搜索引擎来进行搜索

2. DNS 解析
   域名找到对应的 IP 地址的过程，这个过程需要依赖一个服务系统，这个系统将域名和 IP 一一映射，DNS可以看做是个数据库，记录了很多URL和对应的IP地址。
   DNS解析域名过程：找缓存、找本机的hosts文件、找DNS服务器
   （1）用户在浏览器输入域名，操作系统会检查 浏览器缓存和操作系统缓存（本地的host文件） 中是否有这个网址记录，有，则从记录里找到对应的IP，完整域名解析
   （2）没有，则接着检查本地DNS（网络配置中的"DNS服务器地址"了。操作系统会把这个域名发送给这个本地DNS服务器）是否缓存该网址记录，有，则返回解析结果，完成域名解析
   （3）还没有，则本地DNS服务器会发送查询报文到根DNS服务器，根DNS服务器收到请求后，返回顶级DNS服务器地址（它是国际顶级域名服务器，如.com、.cn、.org等，全球只有13台左右），（根服务器发出请求，进行递归查询（DNS服务器先问根域名服务器.com域名服务器的IP地址，然后再问.com域名服务器，依次类推））。

3. 建立 TCP 连接
   浏览器获取到服务器的IP地址后，浏览器会用一个随机的端口号向服务器80端口发起TCP连接请求，这个请求到达服务器后，通过TCP三次握手建立TCP的连接。
   TCP 连接三次握手：
   
   （1）客户端发送SYN报文（SYN=1；seq=x）到服务器，并进入SYN_SENT状态，等待服务器确认
   （2）服务器收到SYN包，确认SYN，同时发送一个SYN包，即SYN+ACK包（SYN=1；ACK=1;seq=y;ack=x+1），此时服务器进入SYN_RECV状态
   第 2 次握手实际上是分两部分来完成的，即 SYN+ACK（请求和确认）报文。

    1. 服务器收到了客户端的请求，向客户端回复一个确认信息（ACK=x+1）。
    2. 服务器再向客户端发送一个 SYN 包（seq=y）建立连接的请求，此时服务器进入 SYN_RECV 状态
   1
   2

   （3） 客户端收到服务器的SYN+ACK包，向服务器发确认包ACK，（ACK=1;seq=x+1;ack=y+1）客户端和服务端进入Established状态，TCP连接建立成功

   SYN：同步序列编号
   SEQ 表示请求序列号
   ACK: 确认序列号，表示响应
   RST：连接重置 复位标志
   URG：紧急标志
   RSH：推标志，表示有DaTa数据传输
   FIN：结束标志
   1
   2
   3
   4
   5
   6
   7

   SYN建立连接 -> SYN+ACK 响应 -> PSH(TCP数据包传递) -> FIN关闭连接 -> RST连接重置

4. 发送 HTTP 请求
   TCP 连接建立完毕，发送 HTTP 请求。
   如果使用https，则会在TCP与HTTP之间多添加一层协议作为加密和认证的服务，https使用SSL/TLS协议，SSL协议的作用是，认证客户端和服务器，确保发送到正确的客服端和服务器，加密数据，防止数据中途被监听、篡改，维护数据的完整性。TLS协议的作用在于，用于在两个通信程序之间，提供保密性和数据完整性，tls协议有两层，tls记录协议和tls握手协议。

5. 网络响应
   HTTP 请求到达服务器，服务器进行对应的处理。最后要把数据传给浏览器，也就是返回网络响应。
   响应头包含服务器及其返回数据的信息，服务器生成数据的时间、返回的数据类型以及对即将写入的 Cookie 信息。
   如果请求头或响应头中包含 Connection: Keep-Alive，则表示建立持久连接，这样 TCP 连接会一直保持，之后请求统一站点的资源会复用该连接。

6. 页面渲染
   数据到达浏览器后，浏览器解析并开始渲染数据。
   （1）构建 DOM 树
   浏览器无法直接理解 HTML 字符串，因此需要将HTML转换为DOM树。
   DOM 树本质上是一个以 document 为根节点的多叉树。这步主要是处理HTML标记构建DOM树。
   （2） 构建CSSOM树
   浏览器是无法直接识别 CSS 样式文本，需要渲染引擎将CSS文本转换为一个结构化的对象，即styleSheets。浏览器处理CSS标记并解析成树形结构的 CSSOM 树。
   （3） 生成布局树
   需要将DOM树和CSSOM树合并为一颗渲染树。
   通过浏览器的布局系统确定元素的位置，也就是要生成一棵布局树(Layout Tree)，注意，只包含可见元素（例如display: none 的元素不包含）。

    1. 遍历DOM 树节点，并添加到布局树中
    2. 计算布局树节点的坐标位置
   1
   2

   浏览器根据渲染树所体现的节点、各个节点的CSS定义以及他们的从属关系，计算出每个节点在屏幕中的位置。页面中元素布局时相对的，当页面元素位置、大小发生变化时，会导致其他节点联动，需要重新计算布局—>回流（reflow）
   （4）绘制（paint）
   便利渲染树，调用渲染器paint()方法在屏幕上绘制出节点（像素填充的过程）。
   该过程中也会出现回流或者不影响布局的css修改导致的屏幕局部重画—>重绘（repaint）。
   绘制过程是在多个层上完成的—>渲染层（renderlayer）
   （5）渲染成合成（composite）
   多个绘制后的渲染层按照恰当的重叠顺序进行合并，然后生成位图，最终通过显卡显示到屏幕上。
   渲染层合成？
   DOM 树中每个节点都会对应一个渲染对象（RenderObject），当它们的渲染对象处于相同的坐标空间（z 轴空间）时，就会形成一个 RenderLayers，也就是渲染层。
   渲染层保证页面元素以正确的顺序堆叠，这时候就会出现层合成（composite），从而正确处理透明元素和重叠元素的显示，对于有位置重叠的元素的页面，该过程尤其重要，因为一旦图层的合并顺序出错，将会导致元素显示异常。
   （6）显示器显示
   栅格化操作完成后，合成线程生成一个绘制命令，即"DrawQuad"，并发送给浏览器进程。 浏览器进程中的 viz 组件接收到该命令，根据命令把页面内容绘制到内存，也就是生成了页面，然后把这部分内存发送给显卡，从而展示在屏幕上。
   从浏览器的渲染过程中我们知道，页面 HTML 会被解析成 DOM 树，每个 HTML 元素对应了树结构上的一个 node 节点。而从 DOM 树转化到一个个的渲染层，并最终执行合并、绘制的过程，中间其实还存在一些过渡的数据结构，它们记录了 DOM 树到屏幕图形的转化原理，其本质也就是树结构到层结构的演化。

7. http请求结束，TCP断开连接
   四次挥手

   1. 第一次挥手： 客户端发送 FIN 报文，报文中指定一个序列号。此时客户端停止再发送数据，主动关闭TCP连接,处于 FIN_WAIT1（终止等待1） 状态。(FIN=1;seq=u)
   2. 第二次挥手：服务端收到 FIN 后，发送 ACK 报文，且把客户端的序列号值 +1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT 状态。（ACK=1，确认号ack=u+1，序号seq=v）
   3. 第三次挥手：如果服务端也想断开连接，和客户端的第一次挥手一样，发给 FIN 报文，且指定一个序列号。此时服务端处于 LAST_ACK 的状态。（FIN=1，ACK=1，序号seq=w，确认号ack=u+1）
   4. 第四次挥手：客户端收到 FIN 后，同样发送一个 ACK 报文作为应答，且把服务端的序列号值 +1 作为自己 ACK 报文的序列号值，此时客户端处于 TIME_WAIT 状态。需要过一段时间，以确保服务端收到自己的 ACK 报文后进入 CLOSED 状态，服务端收到 ACK 报文之后，关闭连接，处于 CLOSED 状态。(ACK=1，seq=u+1，ack=w+1）

webSocket（waiting…）

cookie、sessionStorage和localStorage(waiting…)

1. cookie是什么？
   cookie数据始终在同源的http请求中携带（即使不需要），即cookie在浏览器和服务器间来回传递。
   cookie数据还有路径（path）的概念，可以限制cookie只属于某个路径下。

   属性：

   • Domain，告诉浏览器允许访问cooki

2. sessionStorage是什么？

3. localStorage是什么？

4. 区别

• 生命周期
  Cookie：可设置失效时间，否则默认认为关闭浏览器后失效
  LocalStorage：除非被手动清除，否则永久保存
  SessionStorage：仅在当前网页会话下有效，关闭页面或浏览器后会被清除
• 存放数据
  Cookie：4k左右
  LocalStorage、SessionStorage：可以保存5M的信息
• http请求
  Cookie：每次都会携带在http头中，如果使用cookie保存过多数据会带来性能问题。
  LocalStorage、SessionStorage：仅在客户端即浏览器中保存，不参与和服务器的通信。
• 易用性
  Cookie：需要程序员自己封装，原生的cookie接口不友好
  LocalStorage、SessionStorage：既可采用原声接口，亦可再次封装
• 应用场景
  从安全性来说，因为每次http请求都会携带cookie信息，这样子浪费了带宽，所以cookie应该尽可能的少用，此外cookie还需要指定作用域，不可以跨域调用，限制很多，但是识别用户登陆来说，cookie还是比storage好用，其他情况下可以用storage，localStorage可以用来在页面传递参数，sessionStorage可以用来保存一些临时的数据，防止用户刷新页面后丢失了一些参数。