1.常见的浏览器内核有哪些？
Trident 内核：IE,MaxThon,TT,The World,360,搜狗浏览器等。[又称 MSHTML]
Gecko 内核：Netscape6 及以上版本，FF,MozillaSuite/SeaMonkey 等
Presto 内核：Opera7 及以上。 [Opera 内核原为：Presto，现为：Blink;]
Webkit 内核：Safari,Chrome 等。 [ Chrome 的：Blink（WebKit 的分支）]
2.介绍一下你对浏览器内核的理解？
主要分成两部分：渲染引擎(layout engineer或 Rendering Engine) 和 JS 引擎。
渲染引擎：负责取得网页的内容（HTML、 XML 、图像等等）、整理讯息（例如加入 CSS 等），以及计算网页的显示方式，然后会输出至显示器或打印机。浏览器的内核的不同对于网页的语法解释会有不同，所以渲染的效果也不相同。所有网页浏览器、电子邮件客户端以及其它需要编辑、显示网络内容的应用程序都需要内核。
JS引擎：解析和执行 javascript 来实现网页的动态效果。
最开始渲染引擎和JS引擎并没有区分的很明确，后来 JS 引擎越来越独立，内核就倾向于只指渲染引擎。
3.如何实现浏览器内多个标签页之间的通信?
WebSocket、 SharedWorker ；
也可以调用localstorage、 cookies 等本地存储方式；
localstorage另一个浏览上下文里被添加、修改或删除时，它都会触发一个事件，
我们通过监听事件，控制它的值来进行页面信息通信。
4.WebSocket如何兼容低浏览器？
Adobe Flash Socket、ActiveX HTMLFile(IE)、基于multipart编码发送XHR、基于长轮询的XHR
5.列举 IE 与其他浏览器不一样的特性？
a. IE 的排版引擎是 Trident （又称为 MSHTML）
b. Trident 内核曾经几乎与 W3C 标准脱节（2005 年）
c. Trident 内核的大量 Bug 等安全性问题没有得到及时解决
d. JS 方面，有很多独立的方法，例如绑定事件的 attachEvent、创建事件的 createEventObject 等
e. CSS 方面，也有自己独有的处理方式，例如设置透明，低版本 IE 中使用滤镜的方式
6..浏览器的渲染过程
1.解析HTML生成DOM树。
2.解析CSS生成CSSOM规则树。
3.将DOM树与CSSOM规则树合并在一起生成渲染树。
4.遍历渲染树开始布局，计算每个节点的位置大小信息。
5.将渲染树每个节点绘制到屏幕。
7.跨标签页的通讯方式有哪些?
(1) BroadCast Channel
(2) Service Worker
(3) LocalStorage + window.onstorage监听
(4) Shared Worker + 定时器轮询(setInterval)
(5) IndexedDB + 定时器轮询(setInterval)
(6) cookie + 定时器轮询(setInterval)
(7) window.open + window.postMessage
(8) Websocket
8.浏览器如何解析css选择器？
CSS选择器的解析是从右向左解析的。若从左向右的匹配，发现不符合规则，需要进行回溯，会损失很多性能。若从右向左匹配，先找到所有的最右节点，对于每一个节点，向上寻找其父节点直到找到根元素或满足条件的匹配规则，则结束这个分支的遍历。两种匹配规则的性能差别很大，是因为从右向左的匹配在第一步就筛选掉了大量的不符合条件的最右节点（叶子节点），而从左向右的匹配规则的性能都浪费在了失败的查找上面。 而在 CSS 解析完毕后，需要将解析的结果与 DOM Tree 的内容一起进行分析建立一棵 Render Tree，最终用来进行绘图。在建立 Render Tree 时（WebKit 中的「Attachment」过程），浏览器就要为每个 DOM Tree 中的元素根据 CSS 的解析结果（Style Rules）来确定生成怎样的 Render Tree。
9.浏览器的主要组成部分是什么？
- 用户界面: 用户界面主要包括：地址栏，后退/前进按钮，书签目录等；（除了从服务器请求到的网页窗口）
- 浏览器引擎： 用来查询及操作渲染引擎的接口；
- 渲染引擎：用来显示请求的html内容；（包括样式，图片，js）
- 网络：主要是来完成网络调用，例如http请求，它具有平台无关的接口，可以在不同平台上工作；
- UI后端：用来绘制类似组合选择框及对话框等基本组件，具有不特定于某个平台的通用接口，底层使用操作系统的用户接口。
- JS解释器 ：用来解释执行JS代码；
- 数据存储：属于持久层，浏览器需要在硬盘中保存类似cookie的各种数据，HTML5定义了web database技术，这是一种轻量级完整的客户端存储技术。
10.说说浏览器缓存机制
对于浏览器的缓存来讲，这些规则是在HTTP协议头部和HTML页面的Meta标签中定义的。他们分别从新鲜度和校验值两个维度来规定浏览器是否可以直接使用缓存中的副本，还是需要去源服务器获取新版本。
过期机制：指的是缓存副本的有效期。一个缓存的副本必须满足以下条件，浏览器会认为它是有效的，足够新的： 1.含有完整的过期时间控制头信息（HTTP协议报头），并且仍在有效期内 2.浏览器已经使用过这个缓存的副本，并且会在一个会话中已经检查过新鲜度(即服务器上的资源是否发生改变) 满足以上两种情况的一种，浏览器会直接从缓存中获取副本进行渲染
校验值（验证机制）：服务器返回资源的时候有时在控制头信息带上这个资源的实体标签Etag(Entity Tag),它可以用来作为浏览器再次请求过程中的校验标识，如果发现校验标识不匹配，说明资源已经被修改或者过期，浏览器需要重新获取资源内容。
11.说一下tcp三次握手
C发起请求连接S确认，也发起连接C确认我们再看看每次握手的作用：第一次握手：S只可以确认 自己可以接受C发送的报文段第二次握手：C可以确认 S收到了自己发送的报文段，并且可以确认 自己可以接受S发送的报文段第三次握手：S可以确认 C收到了自己发送的报文段
12.TCP和UDP的区别
(1）TCP是面向连接的，udp是无连接的即发送数据前不需要先建立链接。
(2)TCP提供可靠的服务。也就是说，通过TCP连接传送的数据，无差错，不丢失，不重复，且按序到达;UDP尽最大努力交付，即不保证可靠交付。 并且因为tcp可靠，面向连接，不会丢失数据因此适合大数据量的交换。
(3)TCP是面向字节流，UDP面向报文，并且网络出现拥塞不会使得发送速率降低（因此会出现丢包，对实时的应用比如IP电话和视频会议等）。
(4)TCP只能是1对1的，UDP支持1对1,1对多。
(5)TCP的首部较大为20字节，而UDP只有8字节。
(6)TCP是面向连接的可靠性传输，而UDP是不可靠的。
13.说一下http和https
https的SSL加密是在传输层实现的。
(1)http和https的基本概念
http: 超文本传输协议，是互联网上应用最为广泛的一种网络协议，是一个客户端和服务器端请求和应答的标准（TCP），用于从WWW服务器传输超文本到本地浏览器的传输协议，它可以使浏览器更加高效，使网络传输减少。
https: 是以安全为目标的HTTP通道，简单讲是HTTP的安全版，即HTTP下加入SSL层，HTTPS的安全基础是SSL，因此加密的详细内容就需要SSL。
https协议的主要作用是：建立一个信息安全通道，来确保数组的传输，确保网站的真实性。
(2)http和https的区别？
http传输的数据都是未加密的，也就是明文的，网景公司设置了SSL协议来对http协议传输的数据进行加密处理，简单来说https协议是由http和ssl协议构建的可进行加密传输和身份认证的网络协议，比http协议的安全性更高。
主要的区别如下：
Https协议需要ca证书，费用较高。
http是超文本传输协议，信息是明文传输，https则是具有安全性的ssl加密传输协议。
使用不同的链接方式，端口也不同，一般而言，http协议的端口为80，https的端口为443
http的连接很简单，是无状态的；HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，比http协议安全。
(3)https协议的工作原理
客户端在使用HTTPS方式与Web服务器通信时有以下几个步骤，如图所示。
客户使用https url访问服务器，则要求web 服务器建立ssl链接。
web服务器接收到客户端的请求之后，会将网站的证书（证书中包含了公钥），返回或者说传输给客户端。
客户端和web服务器端开始协商SSL链接的安全等级，也就是加密等级。
客户端浏览器通过双方协商一致的安全等级，建立会话密钥，然后通过网站的公钥来加密会话密钥，并传送给网站。
web服务器通过自己的私钥解密出会话密钥。
web服务器通过会话密钥加密与客户端之间的通信。
(4)https协议的优点
使用HTTPS协议可认证用户和服务器，确保数据发送到正确的客户机和服务器；
HTTPS协议是由SSL+HTTP协议构建的可进行加密传输、身份认证的网络协议，要比http协议安全，可防止数据在传输过程中不被窃取、改变，确保数据的完整性。
HTTPS是现行架构下最安全的解决方案，虽然不是绝对安全，但它大幅增加了中间人攻击的成本。
谷歌曾在2014年8月份调整搜索引擎算法，并称“比起同等HTTP网站，采用HTTPS加密的网站在搜索结果中的排名将会更高”。
(5)https协议的缺点
https握手阶段比较费时，会使页面加载时间延长50%，增加10%~20%的耗电。
https缓存不如http高效，会增加数据开销。
SSL证书也需要钱，功能越强大的证书费用越高。
SSL证书需要绑定IP，不能再同一个ip上绑定多个域名，ipv4资源支持不了这种消耗
14.你有哪些性能优化的方法？
（1）、减少http请求次数：CSS Sprites, JS、CSS源码压缩、图片大小控制合适；网页Gzip，CDN托管，data缓存 ，图片服务器。
（2）、前端模板 JS+数据，减少由于HTML标签导致的带宽浪费，前端用变量保存AJAX请求结果，每次操作本地变量，不用请求，减少请求次数
（3）、用innerHTML代替DOM操作，减少DOM操作次数，优化javascript性能。
（4）、当需要设置的样式很多时设置className而不是直接操作style。
（5）、少用全局变量、缓存DOM节点查找的结果。减少IO读取操作。
（6）、避免使用CSS Expression（css表达式)又称Dynamic properties(动态属性)。
（7）、图片预加载，将样式表放在顶部，将脚本放在底部 加上时间戳。
15.HTTP请求的方式，HEAD方式
head：类似于get请求，只不过返回的响应中没有具体的内容，用户获取报头
options：允许客户端查看服务器的性能，比如说服务器支持的请求方式等等。
16.表单提交中Get和Post方式的区别？
1.get参数通过url传递，post放在request body中。
2.get请求在url中传递的参数是有长度限制的，而post没有。
3.get比post更不安全，因为参数直接暴露在url中，所以不能用来传递敏感信息。
4.get请求只能进行url编码，而post支持多种编码方式
5.get请求会浏览器主动cache，而post支持多种编码方式。
6.get请求参数会被完整保留在浏览历史记录里，而post中的参数不会被保留。
7.GET和POST本质上就是TCP链接，并无差别。但是由于HTTP的规定和浏览器/服务器的限制，导致他们在应用过程中体现出一些不同。
8.GET产生一个TCP数据包；POST产生两个TCP数据包。
17.fetch发送2次请求的原因
因为你用fetch的post请求的时候，导致fetch 第一次发送了一个Options请求，询问服务器是否支持修改的请求头，如果服务器支持，则在第二次中发送真正的请求。
18.在地址栏里输入一个URL,到这个页面呈现出来，中间会发生什么？
这是一个必考的面试问题，
输入url后，首先需要找到这个url域名的服务器ip,为了寻找这个ip，浏览器首先会寻找缓存，查看缓存中是否有记录，缓存的查找记录为：浏览器缓存-》系统缓存-》路由器缓存，缓存中没有则查找系统的hosts文件中是否有记录，如果没有则查询DNS服务器，得到服务器的ip地址后，浏览器根据这个ip以及相应的端口号，构造一个http请求，这个请求报文会包括这次请求的信息，主要是请求方法，请求说明和请求附带的数据，并将这个http请求封装在一个tcp包中，这个tcp包会依次经过传输层，网络层，数据链路层，物理层到达服务器，服务器解析这个请求来作出响应，返回相应的html给浏览器，因为html是一个树形结构，浏览器根据这个html来构建DOM树，在dom树的构建过程中如果遇到JS脚本和外部JS连接，则会停止构建DOM树来执行和下载相应的代码，这会造成阻塞，这就是为什么推荐JS代码应该放在html代码的后面，之后根据外部央视，内部央视，内联样式构建一个CSS对象模型树CSSOM树，构建完成后和DOM树合并为渲染树，这里主要做的是排除非视觉节点，比如script，meta标签和排除display为none的节点，之后进行布局，布局主要是确定各个元素的位置和尺寸，之后是渲染页面，因为html文件中会含有图片，视频，音频等资源，在解析DOM的过程中，遇到这些都会进行并行下载，浏览器对每个域的并行下载数量有一定的限制，一般是4-6个，当然在这些所有的请求中我们还需要关注的就是缓存，缓存一般通过Cache-Control、Last-Modify、Expires等首部字段控制。 Cache-Control和Expires的区别在于Cache-Control使用相对时间，Expires使用的是基于服务器 端的绝对时间，因为存在时差问题，一般采用Cache-Control，在请求这些有设置了缓存的数据时，会先 查看是否过期，如果没有过期则直接使用本地缓存，过期则请求并在服务器校验文件是否修改，如果上一次 响应设置了ETag值会在这次请求的时候作为If-None-Match的值交给服务器校验，如果一致，继续校验 Last-Modified，没有设置ETag则直接验证Last-Modified，再决定是否返回304
19.说一下http2.0
首先补充一下，http和https的区别，相比于http,https是基于ssl加密的http协议
简要概括：http2.0是基于1999年发布的http1.0之后的首次更新。
- 提升访问速度（可以对于，请求资源所需时间更少，访问速度更快，相比http1.0）
- 允许多路复用：多路复用允许同时通过单一的HTTP/2连接发送多重请求-响应信息。改善了：在http1.1中，浏览器客户端在同一时间，针对同一域名下的请求有一定数量限制（连接数量），超过限制会被阻塞。
- 二进制分帧：HTTP2.0会将所有的传输信息分割为更小的信息或者帧，并对他们进行二进制编码
- 首部压缩
- 服务器端推送
20.补充400和401、403状态码
(1)400状态码：请求无效
产生原因：
前端提交数据的字段名称和字段类型与后台的实体没有保持一致
前端提交到后台的数据应该是json字符串类型，但是前端没有将对象JSON.stringify转化成字符串。
解决方法：
对照字段的名称，保持一致性
将obj对象通过JSON.stringify实现序列化
(2)401状态码：当前请求需要用户验证
(3)403状态码：服务器已经得到请求，但是拒绝执行
21.介绍知道的http返回的状态码
100 Continue 继续。客户端应继续其请求
101 Switching Protocols 切换协议。服务器根据客户端的请求切换协议。只能切换到更高级的协议，例如，切换到HTTP的新版本协议
200 OK 请求成功。一般用于GET与POST请求
201 Created 已创建。成功请求并创建了新的资源
202 Accepted 已接受。已经接受请求，但未处理完成
203 Non-Authoritative Information 非授权信息。请求成功。但返回的meta信息不在原始的服务器，而是一个副本
204 No Content 无内容。服务器成功处理，但未返回内容。在未更新网页的情况下，可确保浏览器继续显示当前文档
205 Reset Content 重置内容。服务器处理成功，用户终端（例如：浏览器）应重置文档视图。可通过此返回码清除浏览器的表单域
206 Partial Content 部分内容。服务器成功处理了部分GET请求
300 Multiple Choices 多种选择。请求的资源可包括多个位置，相应可返回一个资源特征与地址的列表用于用户终端（例如：浏览器）选择
301 Moved Permanently 永久移动。请求的资源已被永久的移动到新URI，返回信息会包括新的URI，浏览器会自动定向到新URI。今后任何新的请求都应使用新的URI代替
302 Found 临时移动。与301类似。但资源只是临时被移动。客户端应继续使用原有URI
303 See Other 查看其它地址。与301类似。使用GET和POST请求查看
304 Not Modified 未修改。所请求的资源未修改，服务器返回此状态码时，不会返回任何资源。客户端通常会缓存访问过的资源，通过提供一个头信息指出客户端希望只返回在指定日期之后修改的资源
305 Use Proxy 使用代理。所请求的资源必须通过代理访问
306 Unused 已经被废弃的HTTP状态码
307 Temporary Redirect 临时重定向。与302类似。使用GET请求重定向
400 Bad Request 客户端请求的语法错误，服务器无法理解
401 Unauthorized 请求要求用户的身份认证
402 Payment Required 保留，将来使用
403 Forbidden 服务器理解请求客户端的请求，但是拒绝执行此请求
404 Not Found 服务器无法根据客户端的请求找到资源（网页）。通过此代码，网站设计人员可设置"您所请求的资源无法找到"的个性页面
405 Method Not Allowed 客户端请求中的方法被禁止
406 Not Acceptable 服务器无法根据客户端请求的内容特性完成请求
407 Proxy Authentication Required 请求要求代理的身份认证，与401类似，但请求者应当使用代理进行授权
408 Request Time-out 服务器等待客户端发送的请求时间过长，超时
409 Conflict 服务器完成客户端的PUT请求是可能返回此代码，服务器处理请求时发生了冲突
410 Gone 客户端请求的资源已经不存在。410不同于404，如果资源以前有现在被永久删除了可使用410代码，网站设计人员可通过301代码指定资源的新位置
411 Length Required 服务器无法处理客户端发送的不带Content-Length的请求信息
412 Precondition Failed 客户端请求信息的先决条件错误
413 Request Entity Too Large 由于请求的实体过大，服务器无法处理，因此拒绝请求。为防止客户端的连续请求，服务器可能会关闭连接。如果只是服务器暂时无法处理，则会包含一个Retry-After的响应信息
414 Request-URI Too Large 请求的URI过长（URI通常为网址），服务器无法处理
415 Unsupported Media Type 服务器无法处理请求附带的媒体格式
416 Requested range not satisfiable 客户端请求的范围无效
417 Expectation Failed 服务器无法满足Expect的请求头信息
500 Internal Server Error 服务器内部错误，无法完成请求
501 Not Implemented 服务器不支持请求的功能，无法完成请求
502 Bad Gateway 作为网关或者代理工作的服务器尝试执行请求时，从远程服务器接收到了一个无效的响应
503 Service Unavailable 由于超载或系统维护，服务器暂时的无法处理客户端的请求。延时的长度可包含在服务器的Retry-After头信息中
504 Gateway Time-out 充当网关或代理的服务器，未及时从远端服务器获取请求
505 HTTP Version not supported 服务器不支持请求的HTTP协议的版本，无法完成处理
22.一句话概括RESTFUL
一种软件架构风格，提供了一组设计原则和约束条件。每一个对象都通过URL来表示，对象用户负责将状态信息打包进每一条信息内，客户端的无状态请求在头部包含方法信息，即get post put delete
23.Cookie如何防范XSS攻击?
XSS（跨站脚本攻击）是指攻击者在返回的HTML中嵌入javascript脚本，为了减轻这些攻击，需要在HTTP头部配上，set-cookie：
httponly-这个属性可以防止XSS,它会禁止javascript脚本来访问cookie。
secure - 这个属性告诉浏览器仅在请求为https的时候发送cookie。
24.说一下web worker
在HTML页面中，如果在执行脚本时，页面的状态是不可相应的，直到脚本执行完成后，页面才变成可相应。web worker是运行在后台的js，独立于其他脚本，不会影响页面你的性能。并且通过postMessage将结果回传到主线程。这样在进行复杂操作的时候，就不会阻塞主线程了。
如何创建web worker：
1.检测浏览器对于web worker的支持性
2.创建web worker文件（js，回传函数等）
3.创建web worker对象
25.WebSocket的实现和应用
(1)什么是WebSocket?
WebSocket是HTML5中的协议，支持持久连续，http协议不支持持久性连接。Http1.0和HTTP1.1都不支持持久性的链接，HTTP1.1中的keep-alive，将多个http请求合并为1个
(2)WebSocket是什么样的协议，具体有什么优点？
HTTP的生命周期通过Request来界定，也就是Request一个Response，那么在Http1.0协议中，这次Http请求就结束了。在Http1.1中进行了改进，是的有一个connection：Keep-alive，也就是说，在一个Http连接中，可以发送多个Request，接收多个Response。但是必须记住，在Http中一个Request只能对应有一个Response，而且这个Response是被动的，不能主动发起。
WebSocket是基于Http协议的，或者说借用了Http协议来完成一部分握手，在握手阶段与Http是相同的。我们来看一个websocket握手协议的实现，基本是2个属性，upgrade，connection。
26.说一下web Quality（无障碍）
能够被残障人士使用的网站才能称得上一个易用的（易访问的）网站。
残障人士指的是那些带有残疾或者身体不健康的用户。
使用alt属性：<img src="person.jpg" alt="this is a person"/>
有时候浏览器会无法显示图像。具体的原因有：用户关闭了图像显示、浏览器是不支持图形显示的迷你浏览器、浏览器是语音浏览器（供盲人和弱视人群使用）
如果您使用了alt 属性，那么浏览器至少可以显示或读出有关图像的描述。
27.一个图片url访问后直接下载怎样实现？
请求的返回头里面，用于浏览器解析的重要参数就是OSS的API文档里面的返回http头，决定用户下载行为的参数。
下载的情况下：
- x-oss-object-type:
Normal- x-oss-request-id:
598D5ED34F29D01FE2925F41- x-oss-storage-class:
Standard
28.HTTP支持的方法
GET, POST, HEAD, OPTIONS, PUT, DELETE, TRACE, CONNECT
29.常见的HTTP的头部
可以将http首部分为通用首部，请求首部，响应首部，实体首部
通用首部表示一些通用信息，比如date表示报文创建时间，
请求首部就是请求报文中独有的，如cookie，和缓存相关的如if-Modified-Since
响应首部就是响应报文中独有的，如set-cookie，和重定向相关的location，
实体首部用来描述实体部分，如allow用来描述可执行的请求方法，content-type描述主题类型，content-Encoding描述主体的编码方式
30.强，协商缓存
缓存分为两种：强缓存和协商缓存，根据响应的header内容来决定。
- 强缓存：从缓存取 200（from cache） 否，直接从缓存取
- 协商缓存： 从缓存取 304（not modified） 是，通过服务器来告知缓存是否可用
- 强缓存相关字段有expires，cache-control。如果cache-control与expires同时存在的话，cache-control的优先级高于expires。
- 协商缓存相关字段有Last-Modified/If-Modified-Since，Etag/If-None-Match
31.csrf和xss的网络攻击及防范
CSRF：跨站请求伪造，可以理解为攻击者盗用了用户的身份，以用户的名义发送了恶意请求，比如用户登录了一个网站后，立刻在另一个ｔａｂ页面访问量攻击者用来制造攻击的网站，这个网站要求访问刚刚登陆的网站，并发送了一个恶意请求，这时候CSRF就产生了，比如这个制造攻击的网站使用一张图片，但是这种图片的链接却是可以修改数据库的，这时候攻击者就可以以用户的名义操作这个数据库，防御方式的话：使用验证码，检查https头部的refer，使用token
XSS：跨站脚本攻击，是说攻击者通过注入恶意的脚本，在用户浏览网页的时候进行攻击，比如获取cookie，或者其他用户身份信息，可以分为存储型和反射型，存储型是攻击者输入一些数据并且存储到了数据库中，其他浏览者看到的时候进行攻击，反射型的话不存储在数据库中，往往表现为将攻击代码放在url地址的请求参数中，防御的话为cookie设置httpOnly属性，对用户的输入进行检查，进行特殊字符过滤
32.常用缓存策略的优劣对比
比较常见的缓存策略有Cache-Aside、Read-Though Cache、Write-Through Cache、Write-Around和Write-Back。
- Cache-Aside可以说时最常用的缓存策略。缓存位于一边，应用程序直接与缓存和数据库对话。应用程序首先检查缓存；如果在缓存中找到，表示已经命中缓存。数据被读取并返回给应用程序；如果在缓存中没有找到，则未命中缓存。应用程序必须做一些额外的工作，它需要查询数据库来读取数据，将数据返回给客户端，然后还要将数据存储在缓存中，这样对相同数据的后续读取可以命中缓存。该项策略适合读多的应用场景。使用Cache-aside的系统对缓存失效具有一定的弹性。如果缓存集群宕机，系统仍然可以通过直接访问数据库进行操作。另外，缓存中的数据模型可以与数据库中的数据模型不同。
- Read-though策略下的缓存与数据库保持一致。当缓存丢失时，它从数据库加载相应的数据，填充缓存并将其返回给应用程序。cache-aside和read-through策略都是延迟加载数据的，也就是说，只在第一次读取数据时才加载数据。对比read-through和cache-aside，它们的最大区别在于，在cache-aside中应用程序负责从数据库中获取数据并填充缓存。在read-through中，此逻辑通常由库或独立缓存提供程序支持，而且read-through cache中的数据模型不能与数据库中的数据模型不同。总的来讲，read-through缓存最适合于读量较大的工作负载。劣势是，当第一次请求数据时，它总是导致缓存丢失，并导致额外的数据加载到缓存的代价。
- 在这种缓存策略中，首先将数据写入缓存，然后写入数据库。缓存与数据库保持一致，写操作总是通过缓存到达主数据库。就其本身而言，write-through缓存似乎没有多大作用，实际上，它们引入了额外的写延迟，因为数据先写到缓存，然后写到主数据库。但是，当与read-through结合使用时，我们获得了read-through的所有好处，还获得了数据一致性保证，使我们不必使用缓存失效技术。DynamoDB Accelerator (DAX)是write-through / read-through cache的一个很好的例子。它与DynamoDB和应用程序内联。对DynamoDB的读写可以通过DAX完成。
- 这种缓存策略下，数据直接写入数据库，只有读取的数据才能进入缓存。Write-around可以与read-through结合使用，并在数据只写一次、读取次数较少或从不读的情况下提供良好的性能。例如，实时日志或聊天室消息。同样，这个模式也可以与cache-aside组合使用。
- 这种缓存策略下，应用程序将数据写入缓存，缓存会立即确认，并在延迟一段时间后将数据写入数据库。有时这种策略也被称为write-behind。Write-back缓存提高了写性能，对于写工作量大的工作负载非常有用。当与read-through相结合的时候，它对于混合工作负载非常有效，最近更新和访问的数据总是在缓存中可用。它对数据库故障具有很大程度上的弹性，可以容忍一些数据库的宕机。如果支持批处理或合并，则可以减少对数据库的总体写操作，这将减少负载并降低成本。一些开发人员使用Redis时，同时采用了cache-aside和write-back两种策略，以便更好地吸收峰值负载期间的峰值。这种缓存策略的优劣十分明显，它主要劣势是，如果缓存失效，数据可能会永久丢失。大多数关系[数据库存储]引擎的内部都默认启用了回写缓存。查询首先写入内存，最后刷新到磁盘。
