首先什么是session，字面意思是会话控制。个人理解就是就是一套可以识别用户的系统，为什么需要一套叫做session的东西来识别用户呢？这就得从http协议说起，http协议是基于TCP/IP协议的一层封装（为了让大家都容易理解一些，我都以直白的方式来说，尽量不扯太底层的东西）。用户在访问一个网站的时候，每一次请求页面之后都是断开连接的，既然是断开连接的，那么我下一次访问的时候服务器哥怎么知道是我再一次访问呢？最简单的方式，第一次我给一个凭证你，这个凭证记录着一些与身份相关的信息，第二次你访问的时候给我看这个凭证，我就知道你是之前的那个用户了。
凭证的交付
既然我们知道用`凭证`这一个办法可以识别用户，那么好了，我们就要想办法给用户一个凭证。怎么给也是一个技术活，一个最简单的办法：把凭证信息都放在cookie就行了，反正用户每次访问都会带着cookie访问的。
制作凭证
既然知道如何给用户凭证了，那么服务器哥就很开心啦（可以识别用户咯），赶紧就开始制作凭证，一开始就直接把用户信息直接放到cookie里面（姓名：小明，性别：男，年龄不详），这个时候把凭证给了小明，然后每一次小明都拿这个凭证给服务器哥看，然后就可以愉快的玩耍咯。
凭证的信任危机
一开始服务器哥非常相信用户，没想到有一天，某个用户竟然在凭证上伪造了内容，让服务器哥误认为他是某个用户（这个时候凭证是明文，该起来非常方便），然后被伪造的那个用户的信息泄漏了。。。信息无价呐，服务器哥怎么可能让这事情蔓延下去，所以服务器哥立马把凭证内容加密了（这个加密是可逆加密），这个时候用户拿到的是一堆看不懂的数据，不过服务器哥自己可以解密，用户也无法伪造凭证，这样子就解决了一下凭证的信任危机。（python的flask框架就是这样子处理的）
凭证内容保密问题
虽然服务器哥加密了凭证的内容，然而毕竟是可以解密的，假如有一些信息不希望用户看到的，但是为了方便又想写在凭证上面怎么办呢。这个时候，服务器哥想到给用户的凭证只记录一个唯一的编码，然后在自己这里放着用户凭证的具体数据，然后为这个数据关联编码就好了。
凭证保存问题
既然凭证信息放在服务器哥这里，那么又该怎么存放呢。服务器哥想了几套解决方案出来：
（1）基于文件的存储
（2）基于数据库的存储
（3）基于内存的存储
（4）基于memcached的存储
（5）基于redis的存储
基于文件的存储，我们只需要简单的以用户拿到的唯一编码作为文件名就好，具体信息放在文件里面（我之前写的paas系统就是用了这种方案：https://github.com/yubang/app/blob/master/middle/session.py）。这种方案有几个缺点，首先磁盘读写速度并不快，然后凭证的唯一编码有过期时间，随着时间的流失，废弃的文件也会越来越多，所以还要定时删除过期的文件。并且在多台服务器的时候，还要保持每台服务器都能读取到这些文件。
基于数据库的存储，这种方案跟基于文件差不多，比文件的优点是有多台服务器的时候，只要连着一台数据库就可以保证读取到这些数据。
基于内存的存储这方案主要优点是读写数据比较快，然而内存断电后数据都没了，并且程序之间内存独立了（不过linux系统有一个/dev/shm的目录是映射到内存的），并且多服务器时候读取数据也是一个问题，过期数据也要手动清除。
基于memcached这种方案其实跟内存差不多，然而memcached帮我们解决了除了断电数据丢失之外的大部分问题，在数据超过一定量时候删除一些数据，支持多台服务器来读取数据。
基于redis这种方案其实是拥有了memcached的优点，并且断电后数据还保存数据（哈哈，服务器哥再也不担心断电咯）
凭证交付难题
技术路总是困难重重的，服务器哥好不容易依靠cookie交付凭证，解决了各种安全问题。突然有一天，一个用户说我不使用cookie的（服务器哥哭晕了），用户又不能得罪的，怎么办呢？左想右想（技术总有替代方案的），终于找到几个办法：
（1）每次请求都在url附带上唯一编码（哈哈，好办法）【类似于我们平时调用第三方API】
（2）每次访问在headers附带上唯一编码（也是办法）
故事结局
不知不觉这个故事就说完了，最后就是服务器哥利用一张凭证成功记住了用户。
总的来说，session就是给每一个用户一个随机的唯一的编号，交付途径可以是cookie，url或者headers。而通过这个唯一的编码，映射到服务器存储的具体信息，保存方案各种各样有磁盘有内存。
题外话
技术是无味的，代码只是一堆字符，然而代码制作的产品却是令人振奋的，我只想以最简单有趣的话解说最无味的底层技术，如果喜欢的话，点赞是对我最好的支持。
