cookie,session,Local-Storage,Cache-Control汇总

这里，我这几年的http高级知识做一个汇总：

首先是cookie

先上概念：某些网站为了辨别用户身份而存储在用户本地的终端数据。

举个例子，在登录的时候，每次用户登录都要输入一次密码账号，这样就很麻烦，我们设想弄一个凭证（cookie），它是由服务器发送到用户浏览器并保存在本地的一小块数据。当你第一次登陆成功以后，我们就把cookie发给你，浏览器保存下cookie,这样你第二次再来的时候，他就随着http请求一起发到了服务器上，这样就省去了第二次登录的操作。这样大大的节省了用户的操作与服务器的工作压力。

但是，随着技术的发展，cookie遇到了一些问题，第一，安全隐患，第二，存储问题

先说安全隐患，cookie只是一个凭证，既然你有凭证他也有凭证，那么你能用你的凭证去你的账号，你也能把凭证去他的号。由于cookie存在本地（客户端），所以你能随意改变你的cookie，这样岂不是还不如没有这个凭证？对此，我们想到了session。

说道session，要先提出一个概念，会话cookie和持久化cookie。当服务器发给我们cookie的时候，客户端会把cookie做一系列处理，最终分成两种cookie，一种叫持久化cookie，一种叫会话cookie，持久化cookie的值会存在本地，而会话cookie则会存在内存中，当会话结束（浏览器关闭）的时候，会话cookie就会消失。

话题扯回来，当发现这个安全隐患时，我们用session来给特定的用户指定特定的session，用于标识这个用户，并且跟踪用户。他保存在服务器中。当第一次创造session的时候，服务器会在http中告诉客户端，需要在cookie中记录一个sessionID，将这个ID存在会话cookie中，以后每次请求的时候把这个ID发送到服务器，然后服务器会在他的内存中寻找这个sessionID对应的cookie，这样就知道你是谁了。这样为什么说能够解决安全隐患呢？第一，session是存在服务器上的，你不可能知道其他人的sessionID是啥，所以改了也没软用。第二，sessionID是存在会话cookie上的，你一旦关闭了会话，他就会自动消失，而且session一般寿命只有三十分钟左右，超过这个时间自动失效。

对session来说，其实不用cookie而用URL来附上诸如sid=xxxx这样的参数，用来识别用户。这样做使得当你关闭了cookie，session依然能使用。

安全问题是解决了，那么对于存储呢？

首先提出来为啥要存储，在h5之前，由于http协议只规定了cookie能存储文件，于是诸如一些基本的网页效果，比如：第二次登录时显示欢迎回来字样，关闭网页广告后不再显示这类效果，全部都要存在cookie中，cookie一多，发个响应就会奇慢无比，这样网页就快不起来，于是h5提供了新的专门用来存储数据的地方：local-storage。

相比较于cookie的4k存量，local-storage提供了5mb的大小，专门用来存储这些不重要的数据，这些数据安置在本地，理论上永久有效。这样大大提高了协议发送的速度。

相对于local-storage，还有session-storage，两者的唯一区别是session-storage存在会话中，当会话结束时，他就结束了。

好了，我们似乎已经把cookie说的差不多了，但是对http的优化并不局限于此，我们设计Cache-Control来管理缓存的使用，如图，同样的网站：

用缓存

没用

如图所示，我们用缓存对那些并不更新的js,css做了一定的缓存，当第二次打开该网站的时候，我们就用缓存来替代，这样就大大节省了时间。

对缓存的处理，我们有Expires策略和Cache-Control两种方式，简单来说，Expires策略就是用ETags或者Last-Modifid给文件一个定义缓存结束的时间,写法如下：Last-Modified: Wed, 21 Oct 2015 07:28:00 GMT，这样时间一旦超过这个值，就会自动失效，但是这样有两个弊端，一：还需要服务器发送请求，二：如果客户端定义的时间错误，就会造成缓存失效。对此，h5引入了新的方法：Cache-Control,他直接设定了最大时间寿命Cache-Control: max-age=10000，这样既不需要再向服务器发送请求，也避免了客户端时间设置错误这个弊端，一举两得。

这次总结到此为止，下次再见