1.http是无状态的

• 很久之前，网站的作用是只是用来文档浏览，http请求不需要记录当前用户在网站的访问状态等信息。

• http协议是无状态的，自然可以满足上述需求。

• 随着网络发展，尤其是交互式网络的兴起，如何用户的访问信息称为了必须解决的问题。

2.cookie

2.1.起源

• 1994年，网景通讯的员工Lou Montulli为了解决一个购物车功能，将"Magic Cookies"的概念应用到了网络通信中。
• "Magic Cookies"的概念逐步发展，并最终成为了所有浏览器实现cookies的参考依据。

2.2.cookie是什么

• cookie本身是由服务器产生的，生成之后发送给浏览器，并保存在浏览器。
• cookie就是浏览器存储本地目录的一小段文本。
• cookie是以key-value形式存储的。
• cookie大小有限制，为了保证cookie不占用太多磁盘空间，每个cookie大小一般不超过4KB。
• cookie默认在会话结束后直接销毁，此种cookie称之为会话cookie。
• cookie可以设置过期时间，此种cookie称之为持久cookie。

2.3.cookie的生命周期

2.4.cookie的不足

• 每个cookie容量有限，大小一般不超过4KB。
• 因为cookie由浏览器存储在本地目录，所以不方便记录敏感信息，如密码等。
• cookie不支持跨域访问。
• cookie不支持手机端方案。

3.session

3.1.session是什么

• session是由服务器产生的，存储在服务端等。

• session的存储形式多种多样，可以是文件、数据库、缓存等，这需要靠程序如何设计。

• session也是以key-value形式存储的。

• session是没有大小限制的，这比cookie灵活很多，不过将过多的东西放在其中也并不是明智的做法。

• session也有过期时间的概念，默认为30分钟，可以通过tomcat、web.xml等方式进行配置。

• session可以主动通过invalidate()方法进行销毁。

• session通过session_id识别，如果请求持有正确的session_id，则服务器认为此请求处于session_id代表的会话中。

3.2.session的生命周期

3.3.几种session架构

3.3.1.单点服务与集群服务

• 如果只有一个服务器，则session只能存储于这个服务器中，则服务器必定可以通过用户传递的session_id判断会话状态。

• 如果服务是由集群构成的，例如有两台服务器A和B。用户首次创建的session可能存储于服务器A上。用户再次访问的请求，可能负载均衡到了服务器B上，这时找不到对应的session。这种情况如何解决？

3.3.2.session会话保持

• session会话保持又叫做粘滞会话(sticky sessions)，是负载均衡的一种机制，使得同一session下的请求都发生在同一个服务上。

3.3.3.session复制

• session会话保持的缺陷：如果某个服务节点挂掉，则此服务上的所有会话都会失效。

• session复制：使得所有服务节点之间，相互复制持有的session，这样只要不是所有节点挂掉，则总能找到对应的session。
  

3.3.4.session缓存

• session复制的缺陷：因为session中的信息是动态的，所以保证各节点上session的一致性、准确性、容灾性是个复杂的问题。

• session缓存：将服务节点上的session抽离出来，单独存放在一个缓存服务上，所有节点共同访问一份session。

3.3.5.session缓存集群

• session缓存的缺陷：如果唯一的缓存服务挂了，则全网站的所有会话都会失效。

• session缓存集群：将缓存服务做成集群，提高可用性。

3.4.session的不足

• session大小不限制，存储在服务端，本身是对资源的一种负担。
• 如何保证session的高可用、准确性，优势对整体架构的一种负担。
• 频繁的创建、查询、验证session，会对服务器造成很大的压力。
• session是有状态的。

4.token

4.1.token是什么

• token是一种轻量级的用户验证方式。
• token是无状态的。
• token允许跨域访问。
• token是服务端生成的一个字符串，保存在客户端（可以放在cookie中），作为请求服务的验证令牌。
• token无需存放在服务端，这样服务端无需存放用户信息。
• token对服务端压力极小`，因为服务端只需存储秘钥，并支持生成token的算法，无需存储token。
• token最简单的构造：用户唯一的身份标识(辨识用户) + 时间戳(用于过期校验) + 签名(防止第三方恶意冒充)。
• token无法主动过期，只能等待它达到过期时间后才会失效。
• token的产生：首次请求时，服务器对请求参数（如账号、密码）验证通过，则根据用户标识，加上服务的密钥，通过生成算法，生成token。
• token的验证：再次请求时，携带此token，则服务端再次根据用户标识，生成token，根据两个token是否一致且未过期来判定用户是否已授权。

4.2.token的生命周期

4.3.token的不足

• token无法主动过期，只能等待它达到过期时间后才会失效。
• token本身比session_id要大，会消耗更多的流量与贷款。

cs