从koa-session源码解读session本质
前言
Session，又称为“会话控制”，存储特定用户会话所需的属性及配置信息。存于服务器，在整个用户会话中一直存在。
然而：
- session 到底是什么？
- session 是存在服务器内存里，还是web服务器原生支持？
- http请求是无状态的，为什么每次服务器能取到你的 session 呢？
- 关闭浏览器会过期吗？
本文将从 koa-session（koa官方维护的session中间件） 的源码详细解读 session 的机制原理。希望大家读完后，会对 session 的本质，以及 session 和 cookie 的区别有个更清晰的认识。
基础知识
相信大家都知道一些关于 cookie 和 session 的概念，最通常的解释是 cookie 存于浏览器，session 存于服务器。
cookie 是由浏览器支持，并且http请求会在请求头中携带 cookie 给服务器。也就是说，浏览器每次访问页面，服务器都能获取到这次访问者的 cookie 。
但对于 session 存在服务器哪里，以及服务器是通过什么对应到本次访问者的 session ，其实问过一些后端同学，解释得也都比较模糊。因为一般都是服务框架自带就有这功能，都是直接用。背后的原理是什么，并不一定会去关注。
如果我们使用过koa框架，就知道koa自身是无法使用 session 的，这就似乎说明了 session 并不是服务器原生支持，必须由 koa-session 中间件去支持实现。
那它到底是怎么个实现机制呢，接下来我们就进入源码解读。
源码解读
koa-session：https://github.com/koajs/session
建议感兴趣的同学可以下载代码先看一眼
解读过程中贴出的代码，部分有精简
koa-session结构
来看 koa-session 的目录结构，非常简单；主要逻辑集中在 context.js 。
├── index.js // 入口
├── lib
│ ├── context.js
│ ├── session.js
│ └── util.js
└── package.json
先给出一个 koa-session 主要模块的脑图，可以先看个大概：
屡一下流程
我们从 koa-session 的初始化，来一步步看下它的执行流程：
先看下 koa-sessin 的使用方法：
const session = require('koa-session');
const Koa = require('koa');
const app = new Koa();
app.keys = ['some secret hurr'];
const CONFIG = {
key: 'koa:sess', // 默认值，自定义cookie中的key
maxAge: 86400000
};
app.use(session(CONFIG, app)); // 初始化koa-session中间件
app.use(ctx => {
let n = ctx.session.views || 0; // 每次都可以取到当前用户的session
ctx.session.views = ++n;
ctx.body = n + ' views';
});
app.listen(3000);
初始化
初始化 koa-session 时，会要求传入一个app实例。
实际上，正是在初始化的时候，往 app.context 上挂载了session对象，并且 session 对象是由 lib/context.js 实例化而来，所以我们使用的 ctx.session 就是 koa-session 自己构造的一个类。
我们打开koa-session/index.js：
module.exports = function(opts, app) {
opts = formatOpts(opts); // 格式化配置项，设置一些默认值
extendContext(app.context, opts); // 划重点，给 app.ctx 定义了 session对象
return async function session(ctx, next) {
const sess = ctx[CONTEXT_SESSION];
if (sess.store) await sess.initFromExternal();
await next();
if (opts.autoCommit) {
await sess.commit();
}
};
};
通过内部的一次初始化，返回一个koa中间件函数。
一步一步的来看，formatOpts 是用来做一些默认参数处理，extendContext 的主要任务是对 ctx 做一个拦截器，如下：
function extendContext(context, opts) {
Object.defineProperties(context, {
[CONTEXT_SESSION]: {
get() {
if (this[_CONTEXT_SESSION]) return this[_CONTEXT_SESSION];
this[_CONTEXT_SESSION] = new ContextSession(this, opts);
return this[_CONTEXT_SESSION];
},
},
session: {
get() {
return this[CONTEXT_SESSION].get();
},
set(val) {
this[CONTEXT_SESSION].set(val);
},
configurable: true,
}
});
}
走到上面这段代码时，事实上就是给 app.context 下挂载了一个“私有”的 ContextSession 对象 ctx[CONTEXT_SESSION] ，有一些方法用来初始化它（如initFromExternal、initFromCookie）。然后又挂载了一个“公共”的 session 对象。
为什么说到“私有”、“公共”呢，这里比较细节。用到了 Symbol 类型，使得外部不可访问到 ctx[CONTEXT_SESSION] 。只通过 ctx.session 对外暴露了 (get/set) 方法。
再来看下 index.js 导出的中间件函数
return async function session(ctx, next) {
const sess = ctx[CONTEXT_SESSION];
if (sess.store) await sess.initFromExternal();
await next();
if (opts.autoCommit) {
await sess.commit();
}
};
这里，将 ctx[CONTEXT_SESSION] 实例赋值给了 sess ，然后根据是否有 opts.store ，调用了 sess.initFromExternal ，字面意思是每次经过中间件，都会去调一个外部的东西来初始化 session ，我们后面会提到。
接着看是执行了如下代码，也即执行我们的业务逻辑。
await next()
然后就是下面这个了，看样子应该是类似保存 session 的操作。
sess.commit();
经过上面的代码分析，我们看到了 koa-session 中间件的主流程以及保存操作。
那么 session 在什么时候被创建呢？回到上面提到的拦截器 extendContext ，它会在接到http请求的时候，从 ContextSession类 实例化出 session 对象。
也就是说，session 是中间件自己创建并管理的，并非由web服务器产生。
我们接着看核心功能 ContextSession 。
ContextSession类
先看构造函数：
constructor(ctx, opts) {
this.ctx = ctx;
this.app = ctx.app;
this.opts = Object.assign({}, opts);
this.store = this.opts.ContextStore ? new this.opts.ContextStore(ctx) : this.opts.store;
}
居然啥屁事都没干。往下看 get() 方法:
get() {
const session = this.session;
// already retrieved
if (session) return session;
// unset
if (session === false) return null;
// cookie session store
if (!this.store) this.initFromCookie();
return this.session;
}
噢，原来是一个单例模式（等到使用时候再生成对象，多次调用会直接使用第一次的对象）。
这里有个判断，是否传入了 opts.store 参数，如果没有则是用 initFromCookie() 来生成 session 对象。
那如果传了 opts.store 呢，又啥都不干吗，WTF？
显然不是，还记得初始化里提到的那句 initFromExternal 函数调用么。
if (sess.store) await sess.initFromExternal();
所以，这里是根据是否有 opts.store ，来选择两种方式不同的生成 session 方式。
问：store是什么呢？
答：store可以在
initFromExternal中看到，它其实是一个外部存储。问：什么外部存储，存哪里的？
答：同学莫急，先往后看。
initFromCookie
initFromCookie() {
const ctx = this.ctx;
const opts = this.opts;
const cookie = ctx.cookies.get(opts.key, opts);
if (!cookie) {
this.create();
return;
}
let json = opts.decode(cookie); // 打印json的话，会发现居然就是你的session对象！
if (!this.valid(json)) { // 判断cookie过期等
this.create();
return;
}
this.create(json);
}
在这里，我们发现了一个很重要的信息，session 居然是加密后直接存在 cookie 中的。
我们 console.log 一下 json 变量，来验证下：
initFromeExternal
async initFromExternal() {
const ctx = this.ctx;
const opts = this.opts;
let externalKey;
if (opts.externalKey) {
externalKey = opts.externalKey.get(ctx);
} else {
externalKey = ctx.cookies.get(opts.key, opts);
}
if (!externalKey) {
// create a new `externalKey`
this.create();
return;
}
const json = await this.store.get(externalKey, opts.maxAge, { rolling: opts.rolling });
if (!this.valid(json, externalKey)) {
// create a new `externalKey`
this.create();
return;
}
// create with original `externalKey`
this.create(json, externalKey);
}
可以看到 store.get() ，有一串信息是存在 store 中，可以 get 到的。
而且也是在不断地要求调用 create() 。
create
create()到底做了什么呢？
create(val, externalKey) {
if (this.store) this.externalKey = externalKey || this.opts.genid();
this.session = new Session(this, val);
}
它判断了 store ，如果有 store ，就会设置上 externalKey ，或者生成一个随机id。
基本可以看出，是在 sotre 中存储一些信息，并且可以通过 externalKey 去用来获取。
由此基本得出推断，session 并不是服务器原生支持，而是由web服务程序自己创建管理。
存放在哪里呢？不一定要在服务器，可以像 koa-session 一样骚气地放在 cookie 中！
接着看最后一个 Session 类。
Session类
老规矩，先看构造函数：
constructor(sessionContext, obj) {
this._sessCtx = sessionContext;
this._ctx = sessionContext.ctx;
if (!obj) {
this.isNew = true;
} else {
for (const k in obj) {
// restore maxAge from store
if (k === '_maxAge') this._ctx.sessionOptions.maxAge = obj._maxAge;
else if (k === '_session') this._ctx.sessionOptions.maxAge = 'session';
else this[k] = obj[k];
}
}
}
接收了 ContextSession 实例传来 sessionContext 和 obj ，其他没有做什么。
Session 类仅仅是用于存储 session 的值，以及_maxAge，并且提供了toJSON方法用来获取过滤了_maxAge等字段的，session对象的值。
session如何持久化保存
看完以上代码，我们大致知道了 session 可以从外部或者 cookie 中取值，那它是如何保存的呢，我们回到 koa-session/index.js 中提到的 commit 方法，可以看到：
await next();
if (opts.autoCommit) {
await sess.commit();
}
思路立马就清晰了，它是在中间件结束 next() 后，进行了一次 commit() 。
commit()方法，可以在 lib/context.js 中找到：
async commit() {
// ...省略n个判断，包括是否有变更，是否需要删除session等
await this.save(changed);
}
再来看save()方法：
async save(changed) {
const opts = this.opts;
const key = opts.key;
const externalKey = this.externalKey;
let json = this.session.toJSON();
// save to external store
if (externalKey) {
await this.store.set(externalKey, json, maxAge, {
changed,
rolling: opts.rolling,
});
if (opts.externalKey) {
opts.externalKey.set(this.ctx, externalKey);
} else {
this.ctx.cookies.set(key, externalKey, opts);
}
return;
}
json = opts.encode(json);
this.ctx.cookies.set(key, json, opts);
}
豁然开朗了，实际就是默认把数据 json ，塞进了 cookie ，即 cookie 来存储加密后的 session 信息。
然后，如果设置了外部 store ，会调用 store.set() 去保存 session 。具体的保存逻辑，保存到哪里，由 store 对象自己决定！
小结
koa-session 的做法说明了，session 仅仅是一个对象信息，可以存到 cookie ，也可以存到任何地方（如内存，数据库）。存到哪，可以开发者自己决定，只要实现一个 store 对象，提供 set，get 方法即可。
延伸扩展
通过以上源码分析，我们已经得到了我们文章开头那些疑问的答案。
koa-session 中还有哪些值得我们思考呢？
插件设计
不得不说，store 的插件式设计非常优秀。koa-session 不必关心数据具体是如何存储的，只要插件提供它所需的存取方法。
这种插件式架构，反转了模块间的依赖关系，使得 koa-session 非常容易扩展。
koa-session对安全的考虑
这种默认把用户信息存储在 cookie 中的方式，始终是不安全的。
所以，现在我们知道使用的时候要做一些其他措施了。比如实现自己的 store ，把 session 存到 redis 等。
这种session的登录方式，和token有什么区别呢
这其实要从 token 的使用方式来说了，用途会更灵活，这里就先不多说了。
后面会写一下各种登录策略的原理和比较，有兴趣的同学可以关注我一下。
总结
回顾下文章开头的几个问题，我们已经有了明确的答案。
- session 是一个概念，是一个数据对象，用来存储访问者的信息。
- session 的存储方式由开发者自己定义，可存于内存，redis，mysql，甚至是 cookie 中。
- 用户第一次访问的时候，我们就会给用户创建一个他的 session ，并在 cookie 中塞一个他的 “钥匙key” 。所以即使 http请求 是无状态的，但通过 cookie 我们就可以拿到访问者的 “钥匙key” ，便可以从所有访问者的 session 集合中取出对应访问者的 session。
- 关闭浏览器，服务端的 session 是不会马上过期的。session 中间件自己实现了一套管理方式，当访问间隔超过 maxAge 的时候，session 便会失效。
那么除了 koa-session 这种方式来实现用户登录，还有其他方法吗？
其实还有很多，可以存储 cookie 实现，也可以用 token 方式。另外关于登录还有单点登录，第三方登录等。如果大家有兴趣，可以在后面的文章继续给大家剖析。
