Cookie和Session知识快速入门

---

前言

网络上很多Cookie和Session的基础知识，看得眼花缭乱。为此方便今后自己回顾，本文着重记录我认为比较基础的知识点。

---

Cookie和Session基础知识

Cookie:储存在用户本地终端上的数据，是网站为了识别用户和跟踪会话而存储在用户本地终端中的文本数据；换句话说，Cookie会被保存在你电脑的本地磁盘上。
Cookie存储类型是字符串，容量小。

哪么什么是Session呢？
我先举个例子并用上Cookie

场景:当我们打开浏览器输入http://www.xxx.com时，根据DNS协议(域名和IP地址相互映射的一个分布式数据库)，浏览器会跳转对应IP地址的云服务器的80端口并被转发给了Tomcat服务器。
假设服务器采用的是传统的Web应用Cookie-Session机制，且用户从来没有访问过该网址。

1. 对于浏览器，在跳转前会发送一个http协议的请求报文给服务器，经过一系列操作后，服务器会发送http协议的响应报文给浏览器。（为什么叫请求报文，因为这是浏览器主动发送的请求。）
   请求报文的请求头有一个名为Cookie的字段，该字段存储Cookie的值，但是第一次访问服务器时没有该Cookie字段。
   响应报文的响应头有一个名为Set-Cookie的字段，该字段也是存储Cookie的值。
   两个字段都存储Cookie的值，但是服务器和浏览器对Cookie的值响应操作是不一样的。

2. 对于服务端来说，它会为每个第一次连接服务器的浏览器创建唯一的一个SessionID并保存在服务器中，服务器再将SessionID保存在响应报头的Set-Cookie（还有其他方式：url重写、隐藏表单域，这里以相应报文字段Set-Cookie举例）字段，最后将响应报文返回给浏览器。

3. 浏览器收到响应报文后，会把Set-Cookie的值保存在本地，以便赋给之后请求报头的Cookie字段。这样浏览器存储了独一无二的SessionID，服务器也有对应的记录。
   以上流程如图：
   
   理清楚Cookie在浏览器与服务器间的大概流程后。我们就发现在服务端生成了SessionID。假设有多个用户打开浏览器同时连接上了服务器，那么服务器就会同时保存多个SessionID。这些SessionID被存放在Session中进行统一管理(Session存放的数据类型是键值对形式，key中保存唯一的SessionID，value保存用户信息等值)。因此只要浏览器携带了对应的SessionID的值，服务器就能根据SessionID拿出对应的值。
   这也就是Session的作用：在服务器端根据SessionID存储不同用户保存的不同信息。
   Cookie和Session对比：
   空间：cookie存储的数据不超过3K。session存储在服务器上可以任意存储数据。
   生命周期：cookie的生命周期默认是浏览器关闭的时候就消亡了(可以由开发人员设置)，session的生命周期是间隔的，从创建时开始计时如在30min内没有访问session，那么session生命周期就被销毁。

   升华：
   Cookie在不同域名是不共享的，在相同域名共享。
   如果Session是有状态的，那么我们最好使Session无状态。

   什么是有状态？简单说：不同服务与用户的状态有着密切关系。
   复杂的说：假设在同一个云服务下里部署了两个Tomcat服务器A和B。假设服务器A保存了SessionID，浏览器也存储了对应的SessionID。
   此时浏览器访问服务器B，B收到Cookie的值SessionID，但是B服务器并没有保存对应的SessionID值，因此服务器B会认为浏览器是第一次访问，重新生成一个SessionID的值，并赋给当前服务器会话的SessionID。假设浏览器向B发起的是购买操作，且Session存的值是用户信息。
   此时因为B没有拿到A对应SessionID的值，因此会认为B没有用户信息从而触发不同的执行方式让浏览器回到登录页面重新登录。对比下来，A有用户信息执行是用户想要的操作，B没有同步用户信息于是直接返回登录页面，两者的行为不同。这就是有状态。)

   总结：有状态的服务需要在多个节点之间同步并维护用户状态，而无状态的服务不需要维护用户状态

   Session有三种方式解决无状态

   1. Session Replication：将Session对象保存在其他服务器上
   2. Session Sticky:让中间件如Nginx负载均衡，让指定客户端访问指定应用服务中
   3. 独立Session服务器：将所有Session保存在同一个redis之中，每次所有服务器都去访问这个redis

总结

Session完全依赖Cookie进行SessionID的交互。如果Cookie被禁用了，Session也将无法使用。所以一旦浏览器开启了隐私模式，Cookie将会被限制甚至禁用，这点需要注意。
如果单机就不必考虑Session服务器问题，如果是微服务就必须考虑Session状态问题 不同的服务器可能略微不同，这里只做一个大致分析

常见疑问：
有人主张使用JWT代替Session：看了很多说法，总结下来JWT不见得比Session安全，还要浪费更多内存。JWT更适合当做一次性令牌使用，而不是保存用户信息。综上了解Session还是有充足的必要。