Session和Cookie的主要作用在于完成用户与服务器之间的交互，他们有各自的优点和缺点，但是令人更加头疼的是，他们的优点居然和他们的使用场景是矛盾的！

Cookie

到底什么是Cookie?

Cookie是如何为我们服务的？

我们通常都是用这种方式来创建Cookie：

即使没有设置版本号，Tomcat也会在最后创建HTTP响应头的时候自动把Version的版本设置为1，这是Tomcat创建Set-Cookie的时序图：

在这里要注意几点：
1.当Cookie的属性项里出现Version为1的属性项时，构建HTTP响应头同样会把Version设置为1；

2. 当Name和Value的值出现一些Token字符的时候，构建返回头会把该Cookie的Version设置为1；

3. 创建Cookie的时候，Name必须与set-Cookie(或者是set-Cookie)的属性值一样；

4. Name和Value的值不能设置成ASSIC字符

Session

Session是干嘛的？

前面说过，Cookie可以让服务端跟踪客户端的访问，每次客户端的访问都需要返回一个Cookie，如果Cookie太多的话就会增加数据传输的负担，那这个负担由谁来抗下呢？

就是Session，它的出现就应了一句话:哪有什么岁月安好，只是有人替你负重前行；

再补充一点:同一个客户端与服务端交互的时候不需要每次都传回Cookie值，取而代之的是ID，这个ID是客户端第一次访问服务端的时候生成的，而且每个客户端都是唯一的，所以每个ID都是唯一的，就如同我们都有唯一的指纹一样，这个ID通常是Name为JSESIONID的一个Cookie;

关于Session工作原理的前期准备

Session是怎么干活的？

这是Session的恢复状态图:

%3CmxGraphModel%3E%3Croot%3E%3CmxCell%20id%3D%220%22%2F%3E%3CmxCell%20id%3D%221%22%20parent%3D%220%22%2F%3E%3CmxCell%20id%3D%222%22%20value%3D%22%26lt%3Bh2%26gt%3B%E6%A3%80%E6%9F%A5%E6%81%A2%E5%A4%8D%E7%9A%84session%E6%98%AF%E5%90%A6%E8%BF%87%E6%9C%9F%26lt%3B%2Fh2%26gt%3B%22%20style%3D%22rounded%3D1%3BwhiteSpace%3Dwrap%3Bhtml%3D1%3BfillColor%3D%23dae8fc%3BstrokeColor%3D%236c8ebf%3B%22%20vertex%3D%221%22%20parent%3D%221%22%3E%3CmxGeometry%20x%3D%22250%22%20y%3D%22190%22%20width%3D%22120%22%20height%3D%2260%22%20as%3D%22geometry%22%2F%3E%3C%2FmxCell%3E%3C%2Froot%3E%3C%2FmxGraphModel%3E“SESSIONS.ser

这是过期session状态图：

先来看一下都主要存在哪些问题：

1. 客户端Cookie存储限制。

2. Cookie管理混乱

3. 安全性也不是很好

那分布式Session框架都能解决什么呢，或者说他有哪些优点？

1. Session配置的统一管理

2. Cookie使用的监控和统一规范管理

3. Session存储的多元化

4. Session配置的动态修改

5. Session的key的定期修改

6. 有着很好的容灾机制，框架的稳定性比较好

7. 拥有对存储的监控以及报警支持

8. 拥有可扩展性，能够兼容更多的Session机制

9. 跟够解决跨域名Session与Cookie之间共享的问题

分布式Session框架是怎么干活的呢？一图胜千言

总结

这就是好基友Cookie和Session相爱相杀的故事，不是，使他们一起为人类的互联网世界做贡献的故事，很多技术的研发都是为了解决量的增长带来的问题，Cookie和Session就是其中之二，我忽然想起以为计算机先贤说过的就一句话，大致意思是互联网的神奇之处就在于，他其实视为千千万万的人服务的，然而却像是专门为你一个人服务似的，我想这离不开很多像Cookie和Session这样的技术的支持！