在介绍本篇的主角之前, 我们先复习一下 Cookie
为了实现在游览器的持久性存储和安全性考虑, 游览器提供了一个机制—— Cookie , Cookie 的储存空间很有限, 不同的游览器Cookie空间上限也不同, 一般总上限是 4k 个字节左右 (例如 Firefox), 其储存也只是按照域名进行分块存储, 其次, Cookie 是以键值对的形式进行存储, 而且还只能存储字符串, 复杂的对象都存不了, 这也是游览器出于对用户电脑进行保护的手段。
Session
Cookie 最常见的使用场景就是保存用户的信息, 接下来我们来分析一下「重复登录一个网站」涉及到的 Cookie 和 Session
如果是第一次登录网站, 那肯定是没有 Cookie 的, 登录成功后, 服务器会为这个用户分配一个 id
然后根据这个 id 为「键」, 用户信息为「值」, 这个「值」也可以是游览器想要存储的其他信息, 于是我们称这个键值对就是「会话 Session」, 这个「值」就是 「HttpSession」, 可能有点快, 没事慢慢看。
而服务器用于储存用户信息的「值」本质上又是键值对, 例如 key = “name” value = “张翰”…, 于是服务器就可以通过"name"为 key 来获取用户信息
而每一个网站不可能只有一个用户吧, 故而服务器就会为这些登录的用户储存一个个会话 Session
因此 会话是存储在服务器中的, 并且储存空间不受限
这个 id 实际上是服务器随机生成的一个字符串, 随后, 服务器会将这个 id 写入响应的 Set-Cookie 字段中
然后游览器收到这个响应后, 就会把响应 Set-Cookie 字段中的这个 id 保存下来, 如下图
然后接下来再次访问这个网络, 游览器的请求中的 Cookie 就会带有这个 id 字符串
于是服务器在处理这个请求的时候, 就会根据这个 id 在「服务器中的 类 哈希表」中查找「键」为这个 id 的会话 Session, 并且验证身份信息, 如果游览器发送的请求不带这个 id, 或者服务器的会话中没有「键」为该 id 的会话, 那就会被要求重新登录。可能稍微有点乱, 可以搭配以下图解食用
至此, 我们捋一下这些关系
假设一个网站对应一个 webapp, 而 webapp 必然储存着大量用户的会话 Session, 存储的结构是类哈希表结构, 一个会话的Key 值是 服务器分配的 id, 即 sessionId, 这个Key对应的值是这个用户的个人信息, 也是以键值对的形式组织的
总结一下
Session 是一种可以记录客户端状态的机制, 服务器生成一个 id 给游览器, 当然这个 id 是唯一的, 游览器访问服务器的时候随带将 id 一起发送, Session 就可以根据这个 id 验证用户状态, 记录或者修改相关信息, 并且 Session 是存储在服务器上的, 而 Cookie 储存在游览器中的
关于 Cookie 和 Session
除了上述内容之外, 再补充几点
- Session 具有更高的安全性, 相反 Cookie 安全性较低
- 如果过多地依赖 Session, 相同时间段访问网站的用户过多, 会增加服务器的负担
- 如若要进一步提升安全性, 还可以为 sessionId 增加点空间和时间限制, 例如一段时间过后必须重新登录, 或者设备在不同地方登录需要重新登录, 这在生活中其实用的很广泛, 如 qq 邮箱, gitee …
