授权与认证——应用服务器集群的Session管理

事先声明一下，这一篇文章的目的有两个——

　　1.科普一下基本概念，了解一下曾经比较辉煌的Session管理，了解过去正是为了认知未来；

　　2.引出后续要讲的token知识，尤其是JWT的相关知识。

按照惯例，我应该先普及一些基础概念。

认证（Authentication）

1. 通俗地讲就是验证当前用户的身份，证明“你是你自己”（比如：你每天上下班打卡，都需要通过指纹打卡，当你的指纹和系统里录入的指纹相匹配时，就打卡成功）
2. 互联网中的认证：　　　　　

• • 用户名密码登录
  • 邮箱发送登录链接
  • 手机号接收验证码
  • 只要你能收到邮箱/验证码，就默认你是账号的主人

授权（Authorization）

• 用户授予第三方应用访问该用户某些资源的权限
  • 你在安装手机应用的时候，APP 会询问是否允许授予权限（访问相册、地理位置等权限）
  • 你在访问微信小程序时，当登录时，小程序会询问是否允许授予权限（获取昵称、头像、地区、性别等个人信息）
• 实现授权的方式有：cookie、session、token、OAuth
• 实际上，这里最有意思的是——权限控制，至于权限控制，我会在后面给大家详细详解，也是很让人头疼的地方，绝对不是以前那种权限的有无，更多涉及到权限粒度的划分和组合、分级管理等

什么是凭证（Credentials）

• 实现认证和授权的前提是需要一种媒介（证书） 来标记访问者的身份
  • 在战国时期，商鞅变法，发明了照身帖。照身帖由官府发放，是一块打磨光滑细密的竹板，上面刻有持有人的头像和籍贯信息。国人必须持有，如若没有就被认为是黑户，或者间谍之类的。
  • 在现实生活中，每个人都会有一张专属的居民身份证，是用于证明持有人身份的一种法定证件。通过身份证，我们可以办理手机卡/银行卡/个人贷款/交通出行等等，这就是认证的凭证。
  • 在互联网应用中，一般网站（如掘金）会有两种模式，游客模式和登录模式。游客模式下，可以正常浏览网站上面的文章，一旦想要点赞/收藏/分享文章，就需要登录或者注册账号。当用户登录成功后，服务器会给该用户使用的浏览器颁发一个令牌（token），这个令牌用来表明你的身份，每次浏览器发送请求时会带上这个令牌，就可以使用游客模式下无法使用的功能。

 Cookie的概念

• HTTP 是无状态的协议（对于事务处理没有记忆能力，每次客户端和服务端会话完成时，服务端不会保存任何会话信息）：每个请求都是完全独立的，服务端无法确认当前访问者的身份信息，无法分辨上一次的请求发送者和这一次的发送者是不是同一个人。所以服务器与浏览器为了进行会话跟踪（知道是谁在访问我），就必须主动的去维护一个状态，这个状态用于告知服务端前后两个请求是否来自同一浏览器。而这个状态需要通过 cookie 或者 session 去实现。
• cookie 存储在客户端： cookie 是服务器发送到用户浏览器并保存在本地的一小块数据，它会在浏览器下次向同一服务器再发起请求时被携带并发送到服务器上。
• cookie 是不可跨域的： 每个 cookie 都会绑定单一的域名，无法在别的域名下获取使用，一级域名和二级域名之间是允许共享使用的（靠的是 domain）。

cookie 重要的属性

属性	说明
name=value	键值对，设置 Cookie 的名称及相对应的值，都必须是字符串类型 - 如果值为 Unicode 字符，需要为字符编码。 - 如果值为二进制数据，则需要使用 BASE64 编码。
domain	指定 cookie 所属域名，默认是当前域名
path	指定 cookie 在哪个路径（路由）下生效，默认是 '/'。 如果设置为 /abc，则只有 /abc 下的路由可以访问到该 cookie，如：/abc/read。
maxAge	cookie 失效的时间，单位秒。如果为整数，则该 cookie 在 maxAge 秒后失效。如果为负数，该 cookie 为临时 cookie ，关闭浏览器即失效，浏览器也不会以任何形式保存该 cookie 。如果为 0，表示删除该 cookie 。默认为 -1。 - 比 expires 好用。
expires	过期时间，在设置的某个时间点后该 cookie 就会失效。 一般浏览器的 cookie 都是默认储存的，当关闭浏览器结束这个会话的时候，这个 cookie 也就会被删除
secure	该 cookie 是否仅被使用安全协议传输。安全协议有 HTTPS，SSL等，在网络上传输数据之前先将数据加密。默认为false。 当 secure 值为 true 时，cookie 在 HTTP 中是无效，在 HTTPS 中才有效。
httpOnly	如果给某个 cookie 设置了 httpOnly 属性，则无法通过 JS 脚本 读取到该 cookie 的信息，但还是能通过 Application 中手动修改 cookie，所以只是在一定程度上可以防止 XSS 攻击，不是绝对的安全

Session的概念

• session 是另一种记录服务器和客户端会话状态的机制
• session 是基于 cookie 实现的，session 存储在服务器端，sessionId 会被存储到客户端的cookie 中

• session 认证流程：
  • 用户第一次请求服务器的时候，服务器根据用户提交的相关信息，创建对应的 Session
  • 请求返回时将此 Session 的唯一标识信息 SessionID 返回给浏览器
  • 浏览器接收到服务器返回的 SessionID 信息后，会将此信息存入到 Cookie 中，同时 Cookie 记录此 SessionID 属于哪个域名
  • 当用户第二次访问服务器的时候，请求会自动判断此域名下是否存在 Cookie 信息，如果存在自动将 Cookie 信息也发送给服务端，服务端会从 Cookie 中获取 SessionID，再根据 SessionID 查找对应的 Session 信息，如果没有找到说明用户没有登录或者登录失效，如果找到 Session 证明用户已经登录可执行后面操作。

根据以上流程可知，SessionID 是连接 Cookie 和 Session 的一道桥梁，大部分系统也是根据此原理来验证用户登录状态。

Cookie 和 Session 的区别

• 安全性： Session 比 Cookie 安全，Session 是存储在服务器端的，Cookie 是存储在客户端的。
• 存取值的类型不同：Cookie 只支持存字符串数据，想要设置其他类型的数据，需要将其转换成字符串，Session 可以存任意数据类型。
• 有效期不同： Cookie 可设置为长时间保持，比如我们经常使用的默认登录功能，Session 一般失效时间较短，客户端关闭（默认情况下）或者 Session 超时都会失效。
• 存储大小不同： 单个 Cookie 保存的数据不能超过 4K，Session 可存储数据远高于 Cookie，但是当访问量过多，会占用过多的服务器资源。

应用服务器的高可用架构设计主要基于服务无状态这一特性，但是事实上，业务总是有状态的。

在交易类的电子商务网站，需要有购物车记录用户的购买信息，用户每次购买请求都是向购物车中增加商品；

在社交类的网站中，需要记录用户的当前登录状态。

Web应用中将这些多次请求修改使用的上下文对象称作会话（Session），单机情况下，Session 可由部署在服务器上的Web容器管理。在集群环境下，由于负载均衡服务器可能会将请求分发到集群中任何一台应用服务器上，所以保证每次请求依然能够获得正确的Session 比单机时要复杂的多。

集群环境下，Session 管理的主要手段有以下几种：

Session 复制
Session 绑定（会话粘滞）

cookie记录Session
Session 服务器
接下来，我们逐一进行介绍。

一、Session 复制
在服务器之间进行 Session 同步操作，每个服务器都有所有用户的 Session 信息，因此用户可以向任何一个服务器进行请求。

缺点：

　　占用过多内存
　　同步过程占用网络带宽以及服务器处理器时间
二、Session 绑定
Session 绑定（Sticky Session），又叫会话粘滞。需要配置负载均衡器，使得一个用户的所有请求都路由到同一个服务器，这样就可以把用户的 Session 存放在该服务器中。（这时负载均衡服务器必须工作在HTTP协议层上，比如反向代理负载均衡）

缺点：

　　当服务器宕机时，将丢失该服务器上的所有 Session。

三、Cookie记录Session
浏览器Cookie记录Session。

　　优点：简单易用，支持应用服务器线性伸缩
　　缺点：受Cookie大小限制，能记录的信息有限；每次请求响应都要传输Cookie，影响性能；用户关闭Cookie，访问不正常

四、Session 服务器

　　可用性搞、伸缩性好、性能不错，对信息大小又没有限制的服务器集群Session管理方案——Session服务器。利用独立部署的Session服务器（集群）统一管理Session，应用服务器每次读写Session时，都访问Session服务器。

　　这种解决方案事实上是将应用服务器的状态分离，分为无状态的应用服务器和有状态的Session 服务器，然后针对这两种服务器的不同特性分别设计其架构。

优点： 为了使得大型网站具有伸缩性，集群中的应用服务器通常需要保持无状态，那么应用服务器不能存储用户的会话信息。Session Server 将用户的会话信息单独进行存储，从而保证了应用服务器的无状态。

　　缺点： 需要去实现存取 Session 的代码。

 　　这里重点要了解第四种——Session服务器，对于有状态的Session服务器，一种比较简单的方法是利用分布式缓存、数据库等、在这些工具的基础上开发组件，使其符合Session的存储和访问要求。如果业务场景对Session管理有比较高的要求，比如利用Session服务集成单点登录（SSO）、用户服务等功能，则需要开发专门的Session服务管理平台。

　　授权和认证的知识太多了，我也只是选取我们实际项目中比较典型的应用去阐述自己的心得体会罢了，在后面的文章中我会重点讲解单点登录（SSO），我之所以专门来讲解Session管理，就是为了后续更好的讲解单点登录。

　　实际上，现在的授权与认证技术比较流行的是JWT，这就涉及到token的相关知识了，token的知识也很多，放到后续单独一篇文章去讲解了。