鲁达 1.引言
Http协议在现今主流的IM系统中拥有无可替代的重要性（在IM系统中用HTTP发起的连接被大家简称为http短连接），但Http作为传统互联网信息交换技术，一些典型的概念比如：Session、Token，对于新手程序员来说很陌生。
非常多的文章都是动辄长篇大论、高屋建瓴地从底层协议再到上层分布式应用式的讲解，根本不适合初级程序员，这片文章的目的是以最白话地方式，通俗易懂的为你讲清HTTP协议中的Session和Token等概念，希望读完全文，您仍能满怀信心，继续义无反顾地跳入程序员这个职业深坑。程序员的世界，欢迎你。
2.互联网源起
1990年12月25日，罗伯特·卡里奥在CERN（即位于日内瓦的欧洲原子核研究会）和蒂姆·伯纳斯·李一起成功通过Internet实现了HTTP代理与服务器的第一次通讯（有关HTTP的详细介绍，请见《网络编程懒人入门(六)：深入浅出，全面理解HTTP协议》）。蒂姆·伯纳斯·李(Tim Berners-Lee)爵士作为万维网(World Wide Web，简称WWW或互联网)的发明者，被尊称为互联网之父。蒂姆·伯纳斯·李建立的第一个网站(也是世界上第一个网站)是http://info. cern. ch/，它于1991年8月6日上网(即北京时间8月7日)。
3.相关文章
《IM开发基础知识补课(四)：正确理解HTTP短连接中的Cookie、Session和Token》
《IM开发基础知识补课(一)：正确理解前置HTTP SSO单点登陆接口的原理》
《移动端IM登录时拉取数据如何作到省流量？》
《通俗易懂：基于集群的移动端IM接入层负载均衡方案分享》
《浅谈移动端IM的多点登陆和消息漫游原理》
《谈谈移动端 IM 开发中登录请求的优化》
4.美好的旧时光
我经常想象并怀念三十年前那原始而美好的互联网旧时光， 工作很轻松， 生活很悠闲。
上班的时候偶尔有些HTTP的请求发到我这里， 我简单的看一下， 取出相对应的html文档，图片，发回去就可以了， 然后就可以继续喝茶聊天。
我的创造者们对我很好， 他们制定的一个简单HTTP协议， 就是请求加响应， 尤其是我不用记住是谁刚刚发了HTTP请求， 每个请求对我来说都是全新的！
邮件服务器很羡慕我， 他说：老弟，你的生活太惬意了， 哪像我， 每次有人从客户端访问邮箱， 我都得专门给他建立一个会话， 来处理他发的消息， 你倒好， 完全不用管理会话。
这是由应用的特性决定的， 如果邮件服务器不管理会话， 那多个人之间的邮件消息就会完全混到一起了， 乱作一团了。
而30年前的Web 基本上就是文档的浏览而已， 既然是浏览，我作为一个服务器， 为什么要记住谁在一段时间里都浏览了什么文档呢？
5.是时候该Session出场了
但是好日子没持续多久， 很快大家就不满足于静态的Html 文档了， 交互式的Web应用开始兴起， 尤其是论坛， 在线购物等网站。
我马上就遇到了和邮件服务器一样的问题， 那就是必须管理会话，必须记住哪些人登录系统， 哪些人往自己的购物车中放了商品， 也就是说我必须把每个人区分开。
这对我来说是个不小的挑战， 由于HTTP协议的无状态特性， 我必须加点小手段，才能完成会话管理。
我想出的办法就是给大家发一个会话标识(session id), 说白了就是一个随机的字符串，每个人收到的都不一样， 每次大家向我发起HTTP请求的时候，把这个字符串给一并捎过来， 这样我就能区分开谁是谁了。
6.沉重的负担
大家都很高兴， 可是我就不爽了。
每个人只需要保存自己的session id，而我需要保存所有人的session id ！ 如果访问我的人多了， 就得由成千上万，甚至几十万个。
这对我来说是一个巨大的开销 ， 严重的限制了我的扩展能力， 比如说我用两个机器组成了一个集群， 小F通过机器A登录了系统， 那session id会保存在机器A上， 假设小F的下一次请求被转发到机器B怎么办？ 机器B可没有小F的 session id啊。
有时候我会采用一点小伎俩： session sticky ， 就是让小F的请求一直粘连在机器A上， 但是这也不管用， 要是机器A挂掉了， 还得转到机器B去。
那我只好做session 的复制了， 把session id 在两个机器之间搬来搬去， 快累死了。
后来有个叫Memcached的给我支了招： 把session id 集中存储到一个地方， 所有的机器都来访问这个地方的数据， 这样一来，就不用复制了， 但是增加了单点失败的可能性， 要是那个负责session 的机器挂了， 所有人都得重新登录一遍， 估计得被人骂死。
我也尝试把这个单点的机器也搞出集群，增加可靠性， 但不管如何， 这小小的session 对我来说是一个沉重的负担。
7.时间换空间：Token是个不错的方案
这几天的晚上我一直在思考， 我为什么要保存这可恶的session呢， 只让每个客户端去保存该多好？
可是如果我不保存这些session id , 我怎么验证客户端发给我的session id 的确是我生成的呢？ 如果我不去验证，我都不知道他们是不是合法登录的用户， 那些不怀好意的家伙们就可以伪造session id , 为所欲为了。
嗯，对了，关键点就是验证 ！
比如说， 小F已经登录了系统， 我给他发一个令牌(token)， 里边包含了小F的 user id， 下一次小F 再次通过Http 请求访问我的时候， 把这个token 通过Http header 带过来不就可以了。
不过这和session id没有本质区别啊， 任何人都可以可以伪造， 所以我得想点儿办法， 让别人伪造不了。
那就对数据做一个签名吧， 比如说我用HMAC-SHA256 算法，加上一个只有我才知道的密钥， 对数据做一个签名， 把这个签名和数据一起作为token ， 由于密钥别人不知道， 就无法伪造token了。
这个token 我不保存， 当小F把这个token 给我发过来的时候，我再用同样的HMAC-SHA256 算法和同样的密钥，对数据再计算一次签名， 和token 中的签名做个比较， 如果相同， 我就知道小F已经登录过了，并且可以直接取到小F的user id , 如果不相同， 数据部分肯定被人篡改过， 我就告诉发送者： 对不起，没有认证。
Token 中的数据是明文保存的（虽然我会用Base64做下编码， 但那不是加密）， 还是可以被别人看到的， 所以我不能在其中保存像密码这样的敏感信息。
当然， 如果一个人的token 被别人偷走了， 那我也没办法， 我也会认为小偷就是合法用户， 这其实和一个人的session id 被别人偷走是一样的。
这样一来， 我就不保存session id 了， 我只是生成token , 然后验证token ， 我用我的CPU计算时间获取了我的session 存储空间 ！
解除了session id这个负担， 可以说是无事一身轻， 我的机器集群现在可以轻松地做水平扩展， 用户访问量增大， 直接加机器就行。这种无状态的感觉实在是太好了！
为了帮助小伙伴们更好的学习Python，技术学派整理了Python的相关学习视频及学习路线图。
领取方式
关注“技术学派”后，评论转发文章，私信回复：Python学习