前端面试中的缓存问题

cookie，localstorage，sessionstorage

基础部分

cookie:

大小4KB；数据保存在客户端，同源共享。即使不需要也要在http请求中携带，在浏览器和服务器之间传递。有有效期的说法：一般由服务器生成，可设置失效时间。如果在浏览器端生成Cookie，默认是关闭浏览器后失效。如果浏览器使用的是cookie，那么所有的数据都保存在浏览器端。使用 cookie被攻击的可能性比较大。

localstorage:

大小5M；被同源策略限制，仅在客户端中保存，不参与服务端的通信。存储的数据是永久性的，除非用户人为删除否则会一直存在。
在同一个浏览器内，同源文档之间共享 localStorage 数据，可以互相读取、覆盖。

sessionstorage:

大小5M；被同源策略限制，仅在客户端中保存，不参与服务端的通信。一旦窗口或者标签页被关闭，那么所有通过 sessionStorage 存储的数据也会被删除。只有同一浏览器、同一窗口的同源文档才能共享数据。保存为key和value的键值对，其中value一定要是字符串的数据类型

进阶部分

甩完基础部分之后呢，就会被面试官挖深度了，尤其是cookie部分，经常会被问到很深。

cookie

cookie和session

由于HTTP协议是无状态的协议，所以服务端需要记录用户的状态时，就需要用某种机制来识具体的用户，这个机制就是Session。用唯一的一个标识session来标记用户，这个session是保存在服务端的。保存的方法通常有：内存、数据库、文件等。
那么有了这个session，如何识别呢？就需要保sessionId保存在cookie中。
因此可以看出：
session：用来跟踪会话状态，保存在服务端，安全性更高。因为 session id 的存在，通常要借助 cookie 实现。
cookie：是客户端保存用户信息的一种机制，用来记录用户的一些信息，也是实现Session的一种方式。

cookie中存放的数据

在最初了解cookie的时候，曾经看到有介绍说在cookie中存储用户名和密码，方便用户之后登陆，然而，真的是可以的嘛？安全性问题怎么解决呢？
此外，在建立一次会话也就是session时，常用cookie来传递SessionID。用户注册之后，服务器会设置http响应头Set-Cookie把SessionID随机数传递到浏览器。浏览器得到cookie之后，每次上传到服务器都要带上cookie。服务器识别cookie，可以得到用户的信息，用户不需要每次都登陆。（这也是每次 请求都要携带cookie的原因之一）所以如果浏览器禁用cookie的话，session的使用也会受到影响。

cookie生成过程

Web客户端通过浏览器向 Web服务器发送连接请求；Web 服务器接收到请求后，根据用户端提供的信息产生一个 Set-Cookies Head，并将生成的Set-Cookies Header通过 Response Header存放在 HTTP 报文中回传给 Web 客户端，建立一次会话连接；Web 客户端收到 HTTP 应答报文后，如果要继续已建立的这次会话，则将 Cookies 的内容从 HTTP 报文中取出，形成一个 Cookies文本文件储存在客户端计算机的硬盘中或保存 在客户端计算机的内存中。
在写入时，Cookie由三元组【名字name，域名domain，路径path】确定，所以会出现重名，即cookie不唯一。例如：
Set-Cookie: user2=bbb; domain=www.bank.com; path=/;

cookie常用参数

key，value对应保存
max_age; expires 设置过期时间
path，domain，用于匹配
secure，httponly，解决安全问题

cookie植入请求过程

cookie是放在请求头中的，client把cookie通过HTTP Request 中的“Cookie: header”发送给server。
能够发送cookie要求：本地有缓存的cookies，且能根据url来匹配cookie的domain，path属性；且cookie尚未过期

cookie在植入请求时，是如何选择匹配的cookie的

匹配原则：

一：domain向上匹配，一个页面可以为本域和任何父域设置cookie。
ex：当前页面为 http://www.bank.com
Set-Cookie: user1=aaa; domain=.bank.com; path=/; -------> domain不配陪，无法向下匹配

Set-Cookie: user2=bbb; domain=www.bank.com; path=/; -------> domain匹配

Set-Cookie: user3=ccc; domain=.www.bank.com; path=/; ------->domian匹配，向上（父域）匹配

Set-Cookie: user4=ddd; domain=other.bank.com；path=/; ------->domain不匹配
二：path向下匹配，一个页面可以为本路径和任何子路径设置cookie
ex：当页面为 http://www.bank.com ，path为/hello
Set-Cookie: user1=aaa; domain=www.bank.com; path=/; -------> path不向上匹配

Set-Cookie: user1=aaa; domain=www.bank.com; path=/hello; -------> path匹配

Set-Cookie: user2=bbb; domain=www.bank.com; path=/hello/world; -------> path向下（子路径）匹配

如何处理cookie的不唯一问题

由于cookie是不唯一的，那么当出现多个重名的cookie时，如何处理呢？
应该遵循的优先级为：优先path更长的，如果path相同，则优先更早创建的cookie

cookie在跨域时是如何携带cookie的

在解决跨域时，我们会采用很多解决跨域的方法。此处以cors为例。
cors默认不发cookie。如果要发cookie，客户端需要设置withCredentials 属性为 true（withCredentials属性会包含来自远程域的请求的任何cookie，但这些cookie依然遵循同源策略），需要服务端使用Access-Control-Allow-Credentials: true 字段来允许携带cookie。

cookie安全问题

之前有提到过在cookie中存储用户名和密码会存在被窃听、篡改和冒充的风险。（同时也要注意即使是和服务端传输密码或者在服务端数据库日志等存储密码也要加密，否则数据泄漏，后果很严重。）所以需要怼cookie进行安全处理。

cookie欺骗：

攻击者登录的是受害者的身份
cookie在http协议中是明文传输的，并且直接附在http报文的前面，所以只要使用嗅探工具，获取http包，就可以分析并获得cookie的值（这个时候即使对cookie内容加密也没有作用，认为人家不需要看懂，只需要拿来放在请求里面就好了）。此后只要使用这个cookie的值加载请求中，就会被服务器当成用户。
即使加密cookie，使用https，也可能会被攻击者诱使用户访问http网站从而获取未加密的cookie。
因此可以使用cookie中的secure属性，设置为true时，表示创建的 Cookie 会被以安全的形式向服务器传输，也就是只能在 HTTPS 连接中被浏览器传递到服务器端进行会话验证，如果是 HTTP 连接则不会传递该cookie信息，所以不会被窃取到Cookie 的具体内容。
另一个是 HttpOnly属性，如果在Cookie中设置了"HttpOnly"属性，那么通过程序(JS脚本、Applet等)将无法读取到Cookie信息，这样能有效的防止XSS攻击。
区别：secure属性是防止信息在传递的过程中被监听捕获后信息泄漏，HttpOnly属性的目的是防止程序获取cookie后进行攻击。

cookie注入

认证为攻击者的攻击方式，受害者登录的是攻击者的身份。
要进行cookie注入，有两个必须条件： 1是程序对get和post方式提交的数据进行了过滤，但未对cookie方式提交的数据库进行过滤；2是在条件1的基础上还需要程序对提交数据获取方式是直接request(“xxx”)的方式，未指明使用request对象的具体方法进行获取。
原理：用户先是用https的方式访问bank.com，而后，我们让用户使用http的方式来访问non.bank.com，这时我们能得到一个cookie ，攻击者此时就可以将该明文cookie 替换成攻击者attack的cookie。在domain 向上匹配的同源策略下和cookie 优先级的情况下，访问non.bank.com时得到的cookie 会更优先，这时用户通过https访问bank.com时，就会使用attack优先级更高的cookie。

三者适用场景

cookie

保存用户登录状态；跟踪用户行为；定制页面（个性化设置）；创建购物车，例如淘宝网就使用cookie记录了用户曾经浏览过的商品，方便随时进行比较。

localstorage

localstorage适合保存长期使用的数据，例如一些游戏的本地数据等。

sessionstorage

sessionStorage 非常适合SPA(单页应用程序)，可以方便在各业务模块进行传值。例如存储表单数据等很好用。

缓存机制

缓存存储策略

cache-control
常用值：no-cache：不使用本地缓存，需要使用协商缓存；no-store：直接禁止浏览器缓存数据，每次下载完整资源；public：可以被所有用户缓存；private：只能被种段浏览器缓存，不允许中继（例如cdn）缓存服务器缓存。

强缓存

又称缓存过期策略，确认存储在本地的缓存数据是否已过期。直接在地址栏输入url

expire

在头部设置，一般适合静态资源。
局限性：需要保证客户端和服务器的时间相同，否则会出现过期未更新或者提前过期的情况。是http1.0的。

cache-control的max-age

表示缓存的最长有效期是多久。cache-control的优先级高于expires。是http1.1的。

协商缓存

又称缓存对比策略。F5/点击工具栏中的刷新按钮/右键菜单重新加载

last-modified

比较服务器和客户端的时间戳，若不一致，则需要重新更新缓存，若一致，则直接使用缓存。单位是s。如果一致，则直接回送304。若不一致，则服务器会发回该资源并返回200状态码。
使用If-Modified-Since,如果一致，则直接回送304。若不一致，则服务器会发回该资源并返回200状态码。
if-Unmodified-Since：服务端内容一直没有更新，才会处理请求，返回200状态码和请求资源；若更新，则应当返回412(Precondition Failed) 状态码给客户端

etag

用来解决某些服务器不能精确的得到文件的最后修改时间，也是通过比较服务器和客户端的Etag来判断是否要更新缓存。
使用If-Match,服务器如果匹配到了，则返回200状态码；若没有匹配到ETag，或者收到了“*”值而当前并没有该资源实体，则应当返回412(Precondition Failed) 状态码给客户端。
If-None-Match：服务端如果 ETag 没匹配上，则重发资源数据并返回200，否则返回304。

优先级

当与 If-None-Match 一同出现时，If-Modified-Since会被忽略掉，除非服务器不支持 If-None-Match

无缓存

Ctrl+F5要的是彻底的从Server拿一份新的资源过来

强缓存 && 协商缓存

强缓存：从缓存中取资源，但是如果有缓存的话就不经过服务器（即不发请求），直接从缓存中取。状态码200
协商缓存：从缓存中取资源，但是需要给服务器发请求来由服务器告知缓存是否可用，然后从缓存中取，状态码是304