关于 Session

session 其实只是一种存储手段，跟 cookies 的关系只能说是 手机和原装电池的关系。

在 HTTP 请求报文中

1. 使用额外的header
2. 在参数中添加特定字段
3. 在请求体中添加特定数据结构

就最终效果而言，都可以达到和 cookies 同样的作用。当然这里 session 的概念也就被扩展了

---

由于之后可能会有从一个网站登陆，登陆状态在指定网站依然起效的情况，所以可能会涉及到相关问题的处理

在现在单一网站的情况下，一般是通过session来存储一个用户的登陆状态。在整个后台操作过程中，系统依靠判断session中这个标志状态来识别当前用户

经常和session一起使用的就是python中的装饰器了，在有权限控制的路由中，

@app.route("/manager/test")
@env_check(allowance='manager')
def xxx():
	return ""

装饰器的核心就是这个session

然而如果我有多台服务器，或者多台虚拟主机的时候，就需要session共享来实现这一步了

网上关于session共享倒是搜索到了很多

session多服务器共享的方案梳理

上面介绍的方案无论是用memcached还是普通的非内存数据库（最好还是内存数据库），都是将session保存到数据库，这样大家都可以来操作一个session数据库，这也是在有学长第一次问道我该如何解决session共享问题时候的想法之一。但保存下session，最终其实是在维持一个session，如果用户数量不多的话还好，然而当用户数量急剧增加的时候，这就意味着要同时维持一个相当大的内存数据库，对于内存大小的要求不用说了，对数据库的搜索以及更新速度也有了更高的要求，然而我平时对于数据库基本上只是小型的应用，所以他们的性能什么的也不是很清楚，但是这个数据一定是很难想象的

以上方案对于内存的需求可能会越来越大，对于后期的维护来说可能也会变得困难，或者使用性能会逐渐低下，所以，在现在能够使用session的浏览器上，将数据存储到cookie应该是比较好的选择

将通过该浏览器进行登录后的数据加密的存储到cookie（现在的浏览器应该都是默认允许cookie的了吧，不然使用session也会成为一个问题），这样用户在验证个人信息的时候的大部分消耗应该在cookie的加密解密上或者再进一步读取服务器上有关用户的信息上了，就现有浏览器支持的cookie的个数以及大约4K的字符量来看的话，可以存储的信息真的很多了

这样的好处在于，即使服务器重启，内存数据库丢失，用户也不用重新登录，服务器内存压力也会降低，当然缺点也就来自于客户端的cookie了，cookie中存储不下太多东西，存在被盗取cookie后发生的一系列问题（session有被盗取的风险么，应该有，或者说和cookie一样的风险），好吧，还有破解cookie加密的问题，不过，，，大体看来，并没有太大问题。

下一个大型网站的时候就可以进行测试了捏～～～

六 4 15 17:23:38 CST 2017

现在服务器所使用的Session策略就是用加密的Cookies代替Session，同时会在加密的Cookies中存储验证是同一用户的关键字，比如用户的请求时间，IP等其他信息

虽然其实如果用Cookies来取代Session的话，可能带来的问题就是每一次HTTP请求都会变得十分臃肿，所以最好用加密的Cookies来保存尽量少的关键数据，在数据库中保存好与这条Cookies相关的数据，这样足以代替Session了的感觉