由于 HTTP 协议是无状态的，完成操作关闭浏览器后，客户端和服务端的连接就断开了，所以我们必须要有一种机制来保证客户端和服务端之间会话的连续性，也称为认证，最常见的应用场景就是保持用户的登录态。

最基本的认证方式，就是使用 Sesson-cookie。

以保持用户登录态为例，Sesson-Cookie 认证的具体步骤如下：

1）客户端（浏览器）： 向服务器发送登录信息（用户名和密码）来请求登录校验；

2）服务端： 验证登录信息，验证通过后服务器（比如 Tomcat）会自动为此次请求开辟一块内存空间（一个 session 对象），可以手动将用户信息（比如登录保持时间是否过期）存在 Session 对象中。然后，服务器会自动为这个 Sesson 对象生成一个唯一的标识 sessionID ，并在 HTTP 响应头（Header）的 Set-Cookie：JSESSIONID=XXXXXXX 中设置这个 seesionID。

所以说，Session 的实现是依赖于 Cookie 的

3）客户端： 收到服务端的响应后会解析响应头，从而根据 set-Cookie 将 sessonId 保存在本地 Cookie 中，这样，客户端（浏览器）在下次 HTTP 请求时请求头会自动附上该域名下的 Cookie 信息；

4）服务端： 接收客户端请求时会去解析请求头 Cookie 中的 sessonId，然后根据这个 sessonId 去找 Sesson 对象，从而获取到用户信息；

可以通过拦截器在每次请求前尝试获取 Sesson 对象：Session 存活期间，我们认为客户端一直处于活跃状态（用户处于登录态），一旦 Session 超期过时，那么就可以认为客户端已经停止和服务器进行交互了（用户退出登录）。

如果遇到禁用 Cookie 的情况，一般的做法就是把这个 sessionID 放到 URL 参数中。这也是经常在面试中会被问到的问题。

可能会有同学问为啥不直接把数据全部存在 Cookie 中，还整个 Session 出来然后把 sessionID 存在 Cookie 中的？

Cookie 长度的限制：首先，最基本的，Cookie 是有长度限制的，这限制了它能存储的数据的长度

性能影响：Cookie 确实和 Session 一样可以让服务端程序跟踪每个客户端的访问，但是每次客户端的访问都必须传回这些 Cookie，那如果 Cookie 中存储的数据比较多的话，这无疑增加了客户端与服务端之间的数据传输量，增加了服务器的压力。

安全性：Session 数据其实是属于服务端的数据，而 Cookie 属于客户端，把本应在 Session 中存储的数据放到客户端 Cookie，使得服务端数据延伸到了外部网络及客户端，显然是存在安全性上的问题的。当然我们可以对这些数据做加密，不过从技术来讲物理上不接触才是最安全的。

登录：

拦截器：每次请求前去找 Sesson 对象，从而获取到用户信息

可以看出来，在一次会话当中，两个请求获取到的 Session 对象实际上是同一个对象。

上面已经提到，服务器是根据 cookie 中的 sessionID 来找到 Session 对象的，但以上代码中我们只是手动将用户数据设置到了 Session 中，并没有出现任何关于 Cookie 的代码（将 SessionId 设置到 Cookie 中）

很明显，这些肯定都是服务器（比如 Tomcat）自动完成的了。在第一次获取 Session 即调用 request.getSession() 的时候，服务器会自动创建一个 Session 对象（Session 是一个集合，并且是一个 Map 集合），并且存入服务器的 Session 集合中以 SessionId 为标识键，也就是说根据 SessionId 即可取到对应 Session 的引用。同时也会创建一个键名为 JSESSIONID 的 Cookie 并且返回给浏览器，该 Cookie 的值即为 SessionId。

这个存储着 SessionId 的 Cookie 会跟着请求上传到服务器，所以说，在同一会话当中，不管哪个请求拿到的都是同一个 Session 对象。

这种机制在单体应用时代应用非常广泛，但是，随着分布式时代的到来，Session 的缺点也逐渐暴露出来。

举个例子，比如我们有多个服务器，客户端 1 向服务器发送了一个请求，由于负载均衡的存在，该请求被转发给了服务器 A，于是服务器 A 创建并存储了这个 Session