一分钟理解Session和Cookie的关系

假设一个场景：在 Session 中保存一个变量，用户每请求一次变量增加 1，然后把最新的值以 HTML 的方式返回给客户端。用户第一次请求，Web 服务器（或者应用服务器，如 Tomcat）返回数字 1，那么此时 HTTP 传输已经结束，TCP 经历四次挥手，连接关闭。

当页面再次刷新时（TCP 重新连接，客户端是新的端口）服务器端是如何知道用户对应的 Session 的？

此时关闭浏览器 Session 是否会释放？

总所周知 HTTP 是无状态的协议，它的状态管理机制是后来增补上去的，被记录在rfc6265（HTTP State Management Mechanism）。具体方法很简单：

服务器端->客户端增加一个新的返回头部“Set-Cookie”，通过它设置一个 Key/Value 结构的数据；客户端负责保存这个数据。

客户端->服务器端增加一个新的请求头部“Cookie”，把保存的 Cookie（Key/Value 结构）提交给服务器端。

这个机制就是 Cookie，Session 机制是建立在 Cookie 机制之上的。对于 JavaEE 而言：用户请求的业务逻辑中出现 Session 操作，并且本次请求没有 JSESSIONID 的头部被传递过来，服务器端会通过 Set-Cookie 设置上一个新的当用户再次请求，Cookie 中包含了 JSESSIONID，服务器端会依据此判断出用户所属的 Session

所以回到开始的两个问题：

服务器端通过读取 Http 头部 Cookie 部分 JSESSIONID 找到用户所属的 Session

关闭浏览器只是 JSESSIONID 这个 Cookie 被删除；服务器端的 Session 不会被删除。删除时间是通过配置的

有一种网络攻击方法叫 Cookie/Session 欺骗，比如某管理员用户登录到系统了，如果我们趁他不在电脑旁边的时候把他的 JSESSIONID 复制走；然后打开浏览器访问相同的网址，通过浏览器设置上 JSESSIONID，再次刷新，你会发现已经登录成功了。也就是说服务器端其实只认 JSESSIONID，它甚至无法区分究竟有多少管理员“同时在线”。

我的第一个线上课程在gitchat上线了，希望喜欢我的新朋友、老朋友多多支持；只要9.9元你不但能搞清楚区块链是什么，而且能开发基于区块链的应用。无论是茶余饭后吹牛，还是真刀真枪混饭吃，这个课程你都值得拥有。