首先要问为什么为什么登录用『redis+session』，首先就得问他爹『为什么登录要用Session』！问他爹为什么用Session就得问他爷爷『为什么要有Session和Coookie』！问为什么要有他两就得问他曾爷爷『HTTP协议中的无状态补充——Session』！

为什么为什么为什么？！？！本文章今天就来抛砖引玉，串一串这几个东西：Redis+JWT、Session&Cookie、HTTP的无状态协议。究竟是道德的沦丧？还是人性的堕落？今夜本文为你一究到底！ 用Token替代Session

问题

刚才我们已经初略提出了我们问题的雏形，我们简单梳理一下我们的问题。

为什么我们要使用『redis+session登录验证』？ 因为Session受限与一个服务器进程

为什么我们要用『Session登录验证』？ 因为我们要实现用户登录状态的保持，避免重复登录

为什么我们要『使用Session来实现状态保持』？ 因为Session&Cookie实现了HTTP会话状态管理。补充了HTTP无连接特性下，状态保持的欠缺

为什么我们要『使用Session来实现状态保持』？

首先来回答第一个问题：为什么我们要『使用Session来实现状态保持』？

有因必有果，存在即合理。在计算机的世界中，每一项技术都是由人来选择、使用的，而这里面必然由它被选中的理由，而Session也如此。

背景

遥想天地之初，互联网的世界尚且还是一片荒漠，计算机处理能力低下，存储容量小，网速很慢。万维网的开宗老祖——蒂姆·伯纳斯·李（Tim Berners-Lee），在 1989 年，他发表了一篇论文，提出了在互联网上构建超链接文档系统的构想，在这篇论文里他确立了三项关键技术：

• URI：统一资源标识符，作为互联网上资源的唯一标识
• HTML：超文本标记语言，描述超文本文档
• HTTP：超文本传输协议，用来传输超文本

此文一出，顿觉Web天地宽，开天辟地了我们当今Web世界的技术。由于在早期的互联网中，大多数资源都还是静态的，而为了便于服务器和客户端处理，服务器响应之后，会立刻关闭连接。然而，这却为未来的互联网埋下了一场腥风血雨~

跟一条金鱼讨论人生，HTTP和无状态协议

随着互联网和计算机的发展，我们的网页渐渐变得丰富，甚至是万能了起来（你甚至可以在网页上运行一个OS......）。而在网页会话的状态上，我们也渐渐有了需求——在登录淘宝购物时，要先登录才让购物，如果按HTTP无状态的特性来说，我们几乎每一个动作都需要登录一次，太不现实了。

让金鱼拥有记忆，Session和Cookie

然鹅，魔高一丈，道高一尺！我们的卢姥爷—— 卢·蒙特利 于1994年发明了Cookie，后续引出了我们今天的所要讨论的Session，为HTTP协议的无状态连接提供了有状态的补充。

通过实现一个逻辑上的有状态（是的，逻辑上的有状态，与WebSocket这样的技术不同，如果说WebSocket是两人在房间里面谈话，那么 Cookie 就是两人相互写信，不过彼此记得之前的谈话），我们就可以避免反复重复传输一部分数据，比如说登录认证信息。

引用一下这两篇文章，对这部分内容讲解得很详细，由于本文重点不在这里，不过多篇幅讲解~~（虽然已经水了一大半）~~ https://zhuanlan.zhihu.com/p/99986478 https://www.cnblogs.com/cn-oldboy/p/12543519.html

抽象中的Session，Session与Cookie一个水果比香蕉好吃的故事

为什么Session要保留他模棱两可的诞生来头，其实是为了隐藏Session与Cookie不可告人的关系.....各位有所不知，这段经历早就美化过了......他真正的身份，就是......（后面忘了，总之就是卖钩子了）

言归正传，Cookie的出现是要早于Session的。先是发明了Cookie实现HTTP无状态的补充，而后在开发中，我们逐渐将Cookie从具体的实现抽象为前后端交互的一个概念——Session，而这也便是Session的身世，一个抽象的概念，名为 “会话”（或者说是一种机制）

Tomcat中的HttpSession，狸猫换太子的故事

所以说，如果之前问出 “Cookie和Session之间的区别？” 这个问题，实际上是不合理的。毕竟一个抽象概念和他的实现要怎么比较呢？准确地来说，我们的问题应该被描述成 “Cookie与Tomcat中Session的实现（HttpSession）的区别？”

简单地来说 Cookie & HttpSession 这个问题，他的实现是基于类似这样的一个过程：

• 浏览器第一次访问服务器，服务器会响应回来一个SessionID，来维护本次的会话
• 浏览器接收到响应回来的SessionID，放入到Cookie中，成功地在双方之间建立一个“Session”。注意，此Session非彼Session，是一个抽象意义上的逻辑的Session（一次会话），而不是一个具体的Session（Tomcat中的HttpSession）
• 然后在后续的双方通信，每次浏览器带上Cookie访问服务器。服务器读取Cookie中的SessionID，服务器就能根据SessionID查询到对应的HttpSession，继续两者之间逻辑上的会话（实际应用上就是不用再进行登录验证）

总而言之，这里我们不重在讲解Cookie与Session之间的区别，而是重在提出Session这个抽象的概念“会话”，与他具体的实现（Tomcat的HttpSession）区分开。而在这里，也郑重地提出一句话：Web一日尚存，Session永世不灭！

Session的变迁，从HttpSession到Redis + Session

计算机发展的洪流滚滚向前，历史的车轮无情地从Session&Cookie上碾过。当面对千家万户接入互联网的时候，数以万计的访问请求向我们的服务器袭来，面对这样的变遇，服务器的未来又该何去何从？

而历史告诉我们，服务器选择了分布式系统——通过组成服务器集群。但是，面对服务器集群，Session&Cookie的机制却犹如八十岁老太用手机一样束手无策——由于基于Tomcat的HttpSession与Cookie的机制，是基于一个进程中的，不能做到在多个进程，甚至是多台服务器上实现HttpSession的共享。

千呼万唤始出来，我们的Redis此时便派上用场了——通过Redis实现分布式系统下的服务器集群Session共享。

Tomcat中的HttpSession从本质上来看，也不过是我们Java进程中的一个数据结构，在内存上就是一组数据，所以从理论上来讲，我们可以把 HTTPSession 写入到 Redis 进行存储并统一管理。

由于本文章主要意在探讨原理，而且Redis+Session的实现在网上一搜一大把，在这里具体就不做讲解了。

讲完了Redis+Session，就到此为止了吗？不，我们还要谈谈他的另外一个兄弟——Token & JWT

登录验证从Session到Token，从有状态回到无状态

灵感戛然而止......