共计 2960 个字符，预计需要花费 8 分钟才能阅读完成。
一、cookie
起源：
Cookie 的本职工作并非本地存储，而是“维持状态”。
因为 HTTP 协定是无状态的，HTTP 协定本身不对申请和响应之间的通信状态进行保留，艰深来说，服务器不晓得用户上一次做了什么，这重大妨碍了交互式 Web 应用程序的实现。在典型的网上购物场景中，用户浏览了几个页面，买了一盒饼干和两瓶饮料。最初结帐时，因为 HTTP 的无状态性，不通过额定的伎俩，服务器并不知道用户到底买了什么，于是就诞生了 Cookie。它就是用来绕开 HTTP 的无状态性的“额定伎俩”之一。服务器能够设置或读取 Cookies 中蕴含信息，借此保护用户跟服务器会话中的状态。
在方才的购物场景中，当用户选购了第一项商品，服务器在向用户发送网页的同时，还发送了一段 Cookie，记录着那项商品的信息。当用户拜访另一个页面，浏览器会把 Cookie 发送给服务器，于是服务器晓得他之前选购了什么。用户持续选购饮料，服务器就在原来那段 Cookie 里追加新的商品信息。结帐时，服务器读取发送来的 Cookie 就行了。
原理：
第一次拜访网站的时候，浏览器发出请求，服务器响应申请后，会在响应头外面增加一个 Set-Cookie 选项，将 cookie 放入到响应申请中，在浏览器第二次发申请的时候，会通过 Cookie 申请头部将 Cookie 信息发送给服务器，服务端会分别用户身份，另外，Cookie 的过期工夫、域、门路、有效期、实用站点都能够依据须要来指定。
Cookie 的生成形式次要有两种：
- 生成形式一：http response header 中的 set-cookie
- 生成形式二：js 中能够通过 document.cookie 能够读写 cookie，以键值对的模式展现
利用场景：
cookie 指某些网站为了分别用户身份而贮存在用户本地终端上的数据 (通常通过加密)。cookie 是服务端生成，客户端进行保护和存储。通过 cookie, 能够让服务器晓得申请是起源哪个客户端，就能够进行客户端状态的保护，比方登陆后刷新，申请头就会携带登陆时 response header 中的 set-cookie,Web 服务器接到申请时也能读出 cookie 的值，依据 cookie 值的内容就能够判断和复原一些用户的信息状态。
典型的利用场景有：
- 记住明码，下次主动登录。
- 购物车性能。
- 记录用户浏览数据，进行商品（广告）举荐。
缺点：
Cookie 不够大
Cookie 的大小限度在 4KB 左右，对于简单的存储需要来说是不够用的。
过多的 Cookie 会带来微小的性能节约
cookie 是用来保护用户信息的，而域名 (domain) 下所有申请都会携带 cookie，但对于动态文件的申请，携带 cookie 信息基本没有用，此时能够通过 cdn（存储动态文件的）的域名和主站的域名离开来解决。
因为在 HTTP 申请中的 Cookie 是明文传递的，所以安全性成问题，除非用 HTTPS。
CSRF(跨站申请伪造)攻打，这个也好解决，很多框架都屏蔽这个问题
有的客户端不反对 cookie，须要手动设置，比方小程序
浏览器对 cookie 有限度，不能手动设置 cookie，对于混合嵌套的开发有问题，比方小程序跳转 H5 页面，不能携带 cookie
浏览器对单个 cookie 保留的数据不能超过 4K，很多浏览器都限度一个站点最多保留 20 个 cookie
Cookie 与平安
HttpOnly 不反对读写，浏览器不容许脚本操作 document.cookie 去更改 cookie，
所以为防止跨域脚本 (XSS) 攻打，通过 JavaScript 的 Document.cookie API 无法访问带有 HttpOnly 标记的 Cookie，它们只应该发送给服务端。如果蕴含服务端 Session 信息的 Cookie 不想被客户端 JavaScript 脚本调用，那么就应该为其设置 HttpOnly 标记。
标记为 Secure 的 Cookie 只应通过被 HTTPS 协定加密过的申请发送给服务端。但即使设置了 Secure 标记，敏感信息也不应该通过 Cookie 传输，因为 Cookie 有其固有的不安全性，Secure 标记也无奈提供的确的平安保障。
二、Web Storage
起源：
了补救 Cookie 的局限性，让“业余的人做业余的事件”，Web Storage 呈现了。
HTML5 中新增了本地存储的解决方案 —-Web Storage，它分成两类：sessionStorage 和 localStorage。这样有了 WebStorage 后，cookie 能只做它应该做的事件了——作为客户端与服务器交互的通道，放弃客户端状态。
- 共同点：都是保留在浏览器端，且都遵循同源策略。
- 不同点：在于生命周期与作用域的不同
作用域：localStorage 只有在雷同的协定、雷同的主机名、雷同的端口下，就能读取 / 批改到同一份 localStorage 数据。sessionStorage 比 localStorage 更严苛一点，除了协定、主机名、端口外，还要求在同一窗口（也就是浏览器的标签页）下
sessionStorage 保留的数据用于浏览器的一次会话，当会话完结（通常是该窗口敞开），数据被清空；sessionStorage 特地的一点在于， 即使是雷同域名下的两个页面，只有它们不在同一个浏览器窗口中关上，那么它们的 sessionStorage 内容便无奈共享；localStorage 在所有同源窗口中都是共享的；cookie 也是在所有同源窗口中都是共享的。除了保留期限的长短不同，SessionStorage 的属性和办法与 LocalStorage 齐全一样。
三、indexDB
参考网址：
深刻理解浏览器存储 – 从 cookie 到 WebStorage、IndexedDB
四、session
起源：
1 cookie 是一个十分具体的货色，指的就是浏览器外面存储的一种数据，仅仅是浏览器实现的一种数据存储性能。
2 因为 cookie 是存在用户端，而且它自身存储的尺寸大小也无限，最要害是用户能够是可见的，并能够随便的批改，很不平安。那如何又要平安，又能够不便的全局读取信息呢？于是，这个时候，一种新的存储会话机制：session 诞生了。session 信息存在于服务器端，所以也就很好的解决了平安问题。
原理：
利用场景：
五、token
起源：
session 呈现之后
原理：
参考网址；
彻底了解 cookie session token
token、cookie 和 session 三者的问题和解决方案
总结：
cookie->webstorage->indexDB 是因为能存储数据的大小
cookie->session
1 cookie 是存储在客户端的，有大小，跨平台，跨网站的限度，不平安。
session->token
1 session 是由服务器生成的，服务器生成 sessionid，有多少个用户服务器须要保留多少个 sessionid, 服务器压力较大
token 只须要验证令牌是否正确，而后拿到用户的 userid 去操作
说说你对缓存的了解
浅谈 http 中的 Cache-Control
缓存地址解说：
前端根底进阶 浏览器的缓存机制
HTTP 的缓存 和浏览器的本地存储
cdn 缓存了解：
CDN 缓存
CDN 详解
cdn 优化：
性能优化小册 – 进步网页响应速度：优化你的 CDN 性能
CDN 小结
用了 CDN 缓存，就会跳过强缓存和协商缓存吗？
CDN 的应用场景和操作细节
