本片文章主要讲述浏览器的存储方法以及这些方法的优缺点都有哪些不同。主要从以下几点进行说明：
- cookie
- webStorage
- indexedDB
在开篇之前，需要先说明一下同源策略。
同源策略是浏览器的一个安全策略，不同源的客户端脚本在没有明确授权的情况下，不能读写对方资源。同源判断的依据是：协议、域名、端口号必须相同。如果没有同源策略的话，很容易导致XSS和CSRF攻击。
cookie
cooick产生的背景是因为，HTTP是无状态协议，在没有cooick之前，HTTP的请求头是没有任何状态标记的，这就导致一个问题，服务器本次收到的请求不知道发起请求的客户端有没有登陆过或者购买过其他产品，这就对服务端处理请求产生了不小的麻烦。因此呢，需要客户端在发起请求的时候，携带一些必要的信息供服务器进行判断发起请求的客户端的当前状态，这些信息基本都是经过加密的。这个时候，就产生了一种方案：
- 客户端在第一次请求的时候，服务器会在响应头中添加一个字段
set-cookie， - 当客户端收到响应之后，会去解析响应头，如果存在
set-cookie字段的话，就在浏览器中写入set-cookie中的数据。写入的时候，会与当前域名作为绑定。 - 在客户端发起下一次请求的时候，就会将与该域名绑定的
cookie设置到请求头的cookie字段中(必须符合同源策略并且，路径信息需要相同)。
cooike的数据结构长下面这样：
| 属性名 | 释意 |
|---|---|
| name | 设置的cookie名称 |
| value | 设置的cookie值 |
| Domain | 域名信息，标识这个cookie属于哪个域名。在发送请求的时候会判断此字段与当前请求的地址是否同源 |
| Path | 路径信息。如果同源的话，接下来就会判断路径是否一样。 例如：/a/：可以匹配 /a/b; /a/b/c，/a就只能匹配www.xxxx.com/a; |
| Expires | 过期时间 |
| Size | 大小 |
| HttpOnly | 仅仅传递，不能通过脚本读取。防止XSS攻击 |
| Secure | 仅仅在https请求中携带 |
| sameSite | 跨站点时，是否可以携带cookie，用来防范：CSRF攻击 |
| Priority | 优先级，chrome的提案，定义了三种优先级，Low/Medium/High，当cookie数量超出时，低优先级的cookie会被优先清除 |
cooike在存储的过程中，受限于大小，只能存储4kb左右。会存在过期时间，不能作为持久化存储。如果没有进行相应的安全防护可能导致XSS攻击以及CSRF攻击。
webStorage
因为cookie的存储的不足，因此产生了webStorage。
webStorage又分为localStorage与sessionStorage这两个，这两个相比于cookie，在可存储的大小上，有了质的提升，可以存储4M左右的数据。并且localStorage与sessionStorage跟cookie一样，也必须满足同源策略才能根据key值获取到相应的value。
localStorage与sessionStorage发送的时候，也不会携带到的请求头中去，防止一些安全问题的产生，因不会放到请求头中，因此也减少了不必要的流量开销。
但localStorage与sessionStorage之间又有些不同，不同之处在于localStorage在页面关闭的时候，数据不会被清除。并且可以跨页面使用。所谓的跨页面使用指的是：你在浏览器里打开了两个窗口，一个访问的是http://www.baidu.com/a.html，另一个访问的是http://www.baidu.com/b.html，那么因为协议，域名，端口号都一致，符合同源策略。就可以都访问存储在http://www.baidu.com下的localStorage数据。但是sessionStorage只能是在当期那页面有效，并且当页面退出的时候，相应存储的数据也会被清理掉。
indexedDB
阮一峰老师的博客已经讲解的很详细了。链接地址👀：浏览器数据库 IndexedDB 入门教程
