Cookie、Session、localStorage、sessionStorage详谈

发展历史

在这些存储方式发明之前，项目中普遍存在一个问题：各个页面之间无法很好的共用某些信息，比如普通网站的登录信息、购物网站的购物车信息等等。这是因为浏览器打开网页时使用的是无状态的http协议，即两次页面请求之间是没有任何关联的，我在登录页面登录了，跳转去首页之后怎么获取我的登录状态呢？前端用一个全局变量判断吧，不安全；每次进新页面都发请求判断吧，又太耗费服务端资源。

为了解决这个问题，第一个客户端存储方案：Cookie 诞生了。Cookie可以在浏览器端储存少量的数据内容，并具有同源特性，即在同一域名下的页面都可以使用，可以说解决了燃眉之急。但它的缺点也很明显：最多只能储存4KB的数据内容，而且通过浏览器控制台可以随意更改Cookie中的数据内容，安全性也不高。

于是乎，一个几乎完美的代替方案——Session诞生了。Session是服务端存储方案，由于服务端和客户端是一对多的关系，因此需要一个身份标识来判断信息是哪个客户端的，这个身份标识就是session_id。整个流程以用户登录为例：
1.用户登录，向服务端发送请求。
2.服务端收到请求并验证通过后，向客户端返回加密后的session_id。
3.客户端拿到后，将其存入cookie，以后每次请求都带上它。
4.服务端收到请求后，将其解密并匹配session_id就可以判断出用户的登录状态了。
session的好处在于安全性很高，黑客要去cookie里拿session_id，还要想办法解密，解密了也不一定有用，因为session_id得用户登录了才有用，而且每次登录都是不一样的。

再后来，为了解决Cookie可保存数据大小不够以及占用网络带宽等问题，HTML5推出了localStorage和sessionStorage两种本地存储方式，统称为webStorage，它们与Cookie一样存储在浏览器上并且不会附在网络请求里。

区别与使用场景

Cookie：储存在客户端，最多只能存4KB的数据，请求时附带在header中，通常用来保存一些不敏感信息，比如用户上次浏览位置，页面状态或者是加密过的session_id。

Session：储存在服务端，通过cookie保存服务端为每个登录用户分配的session_id来实现用户的自动登录、登录状态判断、购物车商品信息记录等功能，大小无限制但太大会增加服务端负担，安全性很高。

localStorage：储存在客户端，最多可储存5MB的数据，并且是永久储存，除非用户手动删除，不然下次进入页面还是存在。

sessionStorage： 储存在客户端，最多可储存5MB的数据，属于临时存储，一旦网页关闭数据就会清空。