彻底弄懂session，cookie，token及附带负载均衡集群中的session解决方案

做一个合格的搬运工，结合一些资料整理下别人的笔记，发现总结的东西蛮正的，转载先保存自己目录害怕哪天突然报404！

其实看了一下很多方案，确实工作遇到较多的实现都是通过缓存实现session的分布式的共享。前笔者基于拍黄片、python总结了session共享方案

另行补充几种java实现session分布式共享的方案。

 

session，cookie和token究竟是什么

简述

我在写之前看了很多篇session，cookie的文章，有的人说先有了cookie，后有了session。也有人说先有session，后有cookie。感觉都没有讲的很清楚，泛泛而谈。希望本篇文章对大家有所帮助
注：本文需要读者有cookie，session，token的相关基础知识。

http是一个无状态协议

什么是无状态呢？就是说这一次请求和上一次请求是没有任何关系的，互不认识的，没有关联的。这种无状态的的好处是快速。坏处是假如我们想要把www.zhihu.com/login.html和www.zhihu.com/index.html关联起来，必须使用某些手段和工具

cookie和session

由于http的无状态性，为了使某个域名下的所有网页能够共享某些数据，session和cookie出现了。客户端访问服务器的流程如下

• 首先，客户端会发送一个http请求到服务器端。
• 服务器端接受客户端请求后，建立一个session，并发送一个http响应到客户端，这个响应头，其中就包含Set-Cookie头部。该头部包含了sessionId。Set-Cookie格式如下，具体请看Cookie详解
  Set-Cookie: value[; expires=date][; domain=domain][; path=path][; secure]
• 在客户端发起的第二次请求，假如服务器给了set-Cookie，浏览器会自动在请求头中添加cookie
• 服务器接收请求，分解cookie，验证信息，核对成功后返回response给客户端

注意

• cookie只是实现session的其中一种方案。虽然是最常用的，但并不是唯一的方法。禁用cookie后还有其他方法存储，比如放在url中
• 现在大多都是Session + Cookie，但是只用session不用cookie，或是只用cookie，不用session在理论上都可以保持会话状态。可是实际中因为多种原因，一般不会单独使用
• 用session只需要在客户端保存一个id，实际上大量数据都是保存在服务端。如果全部用cookie，数据量大的时候客户端是没有那么多空间的。
• 如果只用cookie不用session，那么账户信息全部保存在客户端，一旦被劫持，全部信息都会泄露。并且客户端数据量变大，网络传输的数据量也会变大

小结

简而言之, session 有如用户信息档案表, 里面包含了用户的认证信息和登录状态等信息. 而 cookie 就是用户通行证

token

token 也称作令牌，由uid+time+sign[+固定参数]
token 的认证方式类似于临时的证书签名, 并且是一种服务端无状态的认证方式, 非常适合于 REST API 的场景. 所谓无状态就是服务端并不会保存身份认证相关的数据。

组成

• uid: 用户唯一身份标识
• time: 当前时间的时间戳
• sign: 签名, 使用 hash/encrypt 压缩成定长的十六进制字符串，以防止第三方恶意拼接
• 固定参数(可选): 将一些常用的固定参数加入到 token 中是为了避免重复查库

存放

token在客户端一般存放于localStorage，cookie，或sessionStorage中。在服务器一般存于数据库中

token认证流程

token 的认证流程与cookie很相似

• 用户登录，成功后服务器返回Token给客户端。
• 客户端收到数据后保存在客户端
• 客户端再次访问服务器，将token放入headers中
• 服务器端采用filter过滤器校验。校验成功则返回请求数据，校验失败则返回错误码

token可以抵抗csrf，cookie+session不行

假如用户正在登陆银行网页，该网页未对csrf攻击进行防护。攻击者就可以注入一张图片，该图片src为http://www.bank.com/api/transfer?count=1000&to=Tom。倘若是session+cookie，用户打开网页的时候就已经转给Tom1000元了。因为session一旦建立，当前域页面以及该页面路径以下所有页面都共享cookie。在img请求的瞬间，cookie会被浏览器自动添加到请求头中。但token不同，开发者在每次发起请求时手动将 Token 添加到请求中。即打开页面请求img时，该请求头中没有token

分布式情况下的session和token

我们已经知道session时有状态的，一般存于服务器内存或硬盘中，当服务器采用分布式或集群时，session就会面对负载均衡问题。

• 负载均衡多服务器的情况，不好确认当前用户是否登录，因为多服务器不共享session。这个问题也可以将session存在一个服务器中来解决，但是就不能完全达到负载均衡的效果。

而token是无状态的，token字符串里就保存了所有的用户信息

• 客户端登陆传递信息给服务端，服务端收到后把用户信息加密（token）传给客户端，客户端将token存放于localStroage等容器中。客户端每次访问都传递token，服务端解密token，就知道这个用户是谁了。通过cpu加解密，服务端就不需要存储session占用存储空间，就很好的解决负载均衡多服务器的问题了。这个方法叫做JWT(Json Web Token)

总结

• session存储于服务器，可以理解为一个状态列表，拥有一个唯一识别符号sessionId，通常存放于cookie中。服务器收到cookie后解析出sessionId，再去session列表中查找，才能找到相应session。依赖cookie
• cookie类似一个令牌，装有sessionId，存储在客户端，浏览器通常会自动添加。
• token也类似一个令牌，无状态，用户信息都被加密到token中，服务器收到token后解密就可知道是哪个用户。需要开发者手动添加。
• jwt只是一个跨域认证的方案

 

 

负载均衡集群中的session解决方案

前言

在我们给Web站点使用负载均衡之后，必须面临的一个重要问题就是Session的处理办法，无论是PHP、Python、Ruby还是Java，只要使用服务器保存Session，在做负载均衡时都需要考虑Session的问题。

 

分享目录：

1. 问题在哪里？如何处理？

2. 会话保持（案例：Nginx、Haproxy）

3. 会话复制（案例：Tomcat）

4. 会话共享（案例：Memcached、Redis）

 

---

问题在哪里？

从用户端来解释，就是当一个用户第一次访问被负载均衡代理到后端服务器A并登录后，服务器A上保留了用户的登录信息；当用户再次发送请求时，根据负载均衡策略可能被代理到后端不同的服务器，例如服务器B，由于这台服务器B没有用户的登录信息，所以导致用户需要重新登录。这对用户来说是不可忍受的。所以，在实施负载均衡的时候，我们必须考虑Session的问题。

在负载均衡中，针对Session的处理，我们一般有以下几种方法：

• • Session 保持

  • Session 复制

  • Session 共享

 

1、会话保持

---

Session保持（会话保持）是我们见到最多的名词之一，通过会话保持，负载均衡进行请求分发的时候保证每个客户端固定的访问到后端的同一台应用服务器。会话保持方案在所有的负载均衡都有对应的实现。而且这是在负载均衡这一层就可以解决Session问题。

Nginx 做负载均衡的Session保持

对于Nginx可以选用Session保持的方法实行负载均衡，nginx的upstream目前支持5种方式的分配方式，其中有两种比较通用的Session解决方法，ip_hash和url_hash。注意：后者不是官方模块，需要额外安装。

ip_hash（）

每个请求按访问ip的hash结果分配，这样每个访客固定访问一个后端服务器，达到了Session保持的方法。

例：

upstream bakend {
   ip_hash;
   server192.168.0.11:80;
   server192.168.0.12:80;
 }

Haproxy做负载均衡的Session保持

    Haproxy作为一个优秀的反向代理和负载均衡软件，也提供了多种Session保持的方法，下面列举了两种最常用的：

源地址 Hash（不支持负载均衡）

haroxy 将用户IP经过hash计算后指定到固定的真实服务器上（类似于nginx 的ip hash 指令）

配置指令:balancesource

使用cookie 进行识别 （很明显这种不安全的操作并不可靠）

也就是Haproxy在用户第一次访问的后在用户浏览器插入了一个Cookie，用户下一次访问的时候浏览器就会带上这个Cookie给Haproxy，Haproxy进行识别。

配置指令:cookie  SESSION_COOKIE  insert indirect nocache

配置例子如下：

cookie SERVERID insert indirect nocache
server web01 192.168.56.11:8080 check cookie web01
server web02 192.168.56.12:8080 check cookie web02

会话保持的缺点：

会话保持看似解决了Session同步的问题，但是却带来的一些其它方面的问题：

• 负载不均衡了：由于使用了Session保持，很显然就无法保证负载绝对的均衡。

• 没有彻底解决问题：如果后端有服务器宕机，那么这台服务器的Session丢失，被分配到这台服务请求的用户还是需要重新登录。

 

---

2、会话复制

既然，我们的目标是所有服务器上都要保持用户的Session，那么将每个应用服务器中的Session信息复制到其它服务器节点上是不是就可以呢？这就是Session的第二中处理办法：会话复制。

 会话复制在Tomcat上得到了支持，它是基于IP组播（multicast）来完成Session的复制，Tomcat的会话复制分为两种：

• 全局会话复制：利用Delta Manager复制会话中的变更信息到集群中的所有其他节点。

• 非全局复制：使用Backup Manager进行复制，它会把Session复制给一个指定的备份节点。

    不过，这里我不准备来解释会话复制的Tomcat配置，如果有需求可以参考Tomcat官方文档，主要是因为会话复制不适合大的集群。根据笔者在生产的实践案例，当时是在集群超过6个节点之后就会出现各种问题，不推荐生产使用（同步可能会产生延迟）。

 

3、会话共享

---

既然会话保持和会话复制都不完美，那么我们为什么不把Session放在一个统一的地方呢，这样集群中的所有节点都在一个地方进行Session的存取就可以解决问题。

    Session存放到哪里？

对于Session来说，肯定是频繁使用的，虽然你可以把它存放在数据库中，但是真正生产环境中我更推荐存放在性能更快的分布式KV数据中，例如：Memcached和Redis。

 

PHP设置Session共享

如果你使用的是PHP那么恭喜你，配置非常的简单。PHP通过两行配置就可以把Session存放在Memcached或者Redis中，当然你要提前配置好他们。修改php.ini：

session.save_handler = memcache
session.save_path = "tcp://192.168.56.11:11211"

使用Redis存储Session

session.save_handler = redis
session.save_path ="tcp://localhost:6379"

提醒：别忘了给PHP安装memcache或者redis插件。

Tomcat设置Session共享

我们可以使用MSM（Memcached Session Manager）来实现同样把Session存放到Memcache中，GIthub地址如下：https://github.com/magro/memcached-session-manager目前支持Tomcat 6.x7.x和8.x的版本。

如果你想使用Redis，刚好也有开源的可以用，但是遗憾的是暂时不支持Tomcat 8.x的版本：https://github.com/jcoleman/tomcat-redis-session-manager

 

Django设置Session共享

在Django中Session是通过一个中间件管理的。如果要在应用程序中使用Session，需要在settings.py中的MIDDLEWARE_CLASSES变量中加入’django.contrib.sessions.middleware.SessionMiddleware’ 。Django的Session引擎可以将Session存放在三个地方，分别是：数据库、缓存、文件。

使用数据库保存Session（效率不高）

如果你想使用数据库支持的会话，你需要添加'django.contrib.sessions'到你的INSTALLED_APPS设置中。在配置完成之后，请运行manage.py migrate来安装保存会话数据的一张数据库表。

使用缓存保持Session

对于简单的缓存会话：

可以设置SESSION_ENGINE 为"django.contrib.sessions.backends.cache"。此时会话数据将直接存储在你的缓存中。然而，缓存数据将可能不会持久：如果缓存填满或者缓存服务器重启，缓存数据可能会被清理掉。

  若要持久的缓存数据：

可以设置SESSION_ENGINE为"django.contrib.sessions.backends.cached_db"。它的写操作使用缓存，对缓存的每次写入都将再写入到数据库。对于读取的会话，如果数据不在缓存中，则从数据库读取。两种会话的存储都非常快，但是简单的缓存更快，因为它放弃了持久性。大部分情况下，cached_db后端已经足够快，但是如果你需要榨干最后一点的性能，并且接受会话数据丢失的风险，那么你可使用cache而不是cached_db

使用文件保存Session

使用文件保存Session不再我们的讨论之类，因为很难进行共享，PHP默认也是将Session存放在/tmp目录下。

 

 

Cookie、Session、Token那点事儿
cookie,token验证的区别
有了cookie为什么需要session
CSRF Token的设计是否有其必要性
cookie,token,session三者的问题和解决方案
负载均衡集群中的session解决方案
JWT介绍
Json Web Token 入门教程