浏览器介绍

Question

常见的浏览器内核有哪些?

浏览器/RunTime	内核（渲染引擎）	JavaScript 引擎
Chrome	webkit->blink	V8
FireFox	Gecko	SpiderMonkey
Safari	Webkit	JavaScriptCore
Edge	EdgeHTML	Chakra(for JavaScript)
IE	Trident	JScript（IE3.0-IE8.0）
Opera	Presto->blink	Linear A（4.0-6.1）/ Linear B（7.0-9.2）/ Futhark（9.5-10.2）/ Carakan（10.5-）
Node.js	-	V8

浏览器的主要组成部分是什么？

1. 「用户界面」 - 包括地址栏、前进/后退按钮、书签菜单等。
2. 「浏览器引擎」 - 在用户界面和呈现引擎之间传送指令。
3. 「呈现引擎」 - 负责显示请求的内容。如果请求的内容是 HTML，它就负责解析 HTML 和 CSS 内容，并将解析后的内容显示在屏幕上。
4. 「网络」 - 用于网络调用，比如 HTTP 请求。
5. 「用户界面后端」 -用于绘制基本的窗口小部件，比如组合框和窗口。
6. 「JavaScript 解释器」 - 用于解析和执行 JavaScript 代码。
7. 「数据存储」 - 这是持久层。浏览器需要在硬盘上保存各种数据，例如 Cookie。新的 HTML 规范 (HTML5) 定义了“网络数据库”，这是一个完整（但是轻便）的浏览器内数据库。

值得注意的是，和大多数浏览器不同，Chrome 浏览器的每个标签页都分别对应一个呈现引擎实例。每个标签页都是一个独立的进程。

区分普通显示屏和高清屏

当 devicePixelRatio 值等于 1 时（也就是最小值），那么它普通显示屏。

当 devicePixelRatio 值大于 1(通常是 1.5、2.0)，那么它就是高清显示屏。

不同像素的图利用媒体查询结合 devicePixelRatio 可以区分普通显示屏和高清显示屏

给出了如下 CSS 设计方案：

.css{/* 普通显示屏（设备像素比例小于等于 1.3) 使用 1 倍的图 */ 
    background-image: url(img_1x.png);
}
@media only screen and (-webkit-min-device-pixel-ratio:1.5){
.css{/* 高清显示屏（设备像素比例大于等于 1.5) 使用 2 倍图  */
    background-image: url(img_2x.png);
  }
}

服务端用 nginx 对图片进行处理

使用更小更快更强，新一代图片格式 WebP，在实测中，webp 格式比 jpg 格式减小约 20%。这对优化用户体验，减少 CDN 带宽消耗有很好的效果。

如何判断呢？

我想到一个解决的方案，就是通过 User-Agent 信息，可以拿到你的浏览器信息，通过对你的浏览器分类，支持 webp 放在白名单里，不支持的则为黑名单。判断为白名单，则直接调用，返回 webp 格式图片；反之，则显示原图。

axios 与 ajax 的区别及优缺点

区别：

axios 是通过 Promise 实现对 ajax 技术的一种封装，就像 jquery 对 ajax 的封装一样，简单来说就是 ajax 技术实现了局部数据的刷新，axios 实现了对 ajax 的封装

优缺点：

• ajax：
• 本身是针对 MVC 编程，不符合前端 MVVM 的浪潮
• 基于原生 XHR 开发，XHR 本身的架构不清晰，已经有了 fetch 的替代方案，jquery 整个项目太大，单纯使用 ajax 却要引入整个 jquery 非常不合理（采取个性化打包方案又不能享受 cdn 服务）
• ajax 不支持浏览器的 back 按钮
• 安全问题 ajax 暴露了与服务器交互的细节
• 对搜索引擎的支持比较弱
• 破坏程序的异常机制
• 不容易调试
• axios：
• 从 node.js 创建 http 请求
• 支持 Promise API
• 客户端防止 CSRF（网站恶意利用）
• 提供了一些并发请求的接口

说一说 Cookie、localStorage、sessionStorage

Cookie

Cookie 的存在也不是为了解决通讯协议无状态的问题，只是 为了解决客户端与服务端会话状态的问题，这个状态是指后端服务的状态而非通讯协议的状态 。

Cookie 设置

1. 客户端发送 HTTP 请求到服务器
2. 当服务器收到 HTTP 请求时，在响应头里面添加一个 Set-Cookie 字段
3. 浏览器收到响应后 保存下 Cookie
4. 之后对该服务器每一次请求中都通过 Cookie 字段将 Cookie 信息发送给服务器。

Cookie 指令

• Name/Value

  用 JavaScript 操作 Cookie 的时候注意对 Value 进行编码处理。

• Expires/Max-Age

  Max-Age 用于设置在 Cookie 失效之前需要经过的秒数;

  Expires 用于设置 Cookie 的过期时间;

  Set-Cookie: id=aad3fWa; Expires=Wed, 21 May 2020 07:28:00 GMT;
  

  • 当 Expires 属性缺省时，表示是会话性 Cookie。像上图 Expires 的值为 Session，表示的就是会话性 Cookie。
  • 会话性 Cookie 的时候，值保存在客户端内存中，并在用户关闭浏览器时失效。
  • 需要注意的是，有些浏览器提供了会话恢复功能，关闭浏览器，会话期 Cookie 会保留下来。
  • 与会话性 Cookie 相对的是持久性 Cookie，持久性 Cookies 会保存在用户的硬盘中，直至过期或者清除 Cookie。

Domain

​ Domain 指定了 Cookie 可以送达的主机名 。假如没有指定，那么默认值为当前文档访问地址中的主机部分（但是不包含子域名）。注意的是， 不能跨域设置 Cookie 。

Path

​ Path 指定了一个 URL 路径，这个路径必须出现在要请求的资源的路径中才可以发送 Cookie 首部 。比如设置 Path=/docs ， /docs/Web/ 下的资源会带 Cookie 首部， /test 则不会携带 Cookie 首部

「Domain 和 Path 标识共同定义了 Cookie 的作用域：即 Cookie 应该发送给哪些 URL。」

Secure

​ 标记为 Secure 的 Cookie 只应通过被 HTTPS 协议加密过的请求发送给服务端 。使用 HTTPS 安全协议，可以保护 Cookie 在浏览器和 Web 服务器间的传输过程中不被窃取和篡改。

HTTPOnly

设置 HTTPOnly 属性可以防止客户端脚本通过 document.cookie 等方式访问 Cookie，有助于避免 XSS 攻击。

SameSite

SameSite 属性可以 让 Cookie 在跨站请求时不会被发送，从而可以阻止跨站请求伪造攻击（CSRF） 。

对大部分 web 应用而言，Post 表单，iframe，AJAX，Image 这四种情况从以前的跨站会发送三方 Cookie，变成了不发送。

Cookie 的作用

Cookie 主要用于以下三个方面：

1. 会话状态管理 （如 用户登录状态、购物车、游戏分数 或其它需要记录的信息）
2. 个性化设置 （如 用户自定义设置、主题 等）
3. 浏览器行为跟踪 （如 跟踪分析用户行为 等）

Cookie 的缺点

从大小，安全，增加请求大小

• 容量缺陷 。Cookie 的体积上限只有 4KB ，只能用来存储少量的信息。
• 降低性能 ，Cookie 紧跟着域名，不管域名下的某个地址是否需要这个 Cookie，请求都会带上完整的 Cookie，请求数量增加，会造成巨大的浪费。
• 安全缺陷 ，Cookie 是以纯文本的形式在浏览器和服务器中传递，很容易被非法用户获取，当 HTTPOnly 为 false 时，Cookie 信息还可以直接通过 JS 脚本读取 。

localStorage 和 sessionStorage

在 web 本地存储场景上，cookie 的使用受到种种限制，最关键的就是存储容量太小和数据无法持久化存储。

分类	生命周期	存储容量	存储位置
cookie	默认保存在内存中，随浏览器关闭失效（如果设置过期时间，在到过期时间后失效）	4KB	保存在客户端，每次请求时都会带上
localStorage	理论上永久有效的，除非主动清除。	4.98MB（不同浏览器情况不同，safari 2.49M）	保存在客户端，不与服务端交互。节省网络流量
sessionStorage	仅在当前网页会话下有效，关闭页面或浏览器后会被清除。	4.98MB（部分浏览器没有限制）	同上

应用场景

• localStorage 适合持久化缓存数据 ，比如页面的默认偏好配置，如官网的 logo ，存储 Base64 格式的图片资源等；
• sessionStorage 适合一次性临时数据保存 ，存储本次浏览信息记录，这样子页面关闭的话，就不需要这些记录了，还有对表单信息进行维护，这样子页面刷新的话，也不会让表单信息丢失。