会话管理
只需要在网站登录一次，就能在较长一段时间内保持登录在线，避免用户反复登录。
HTTP 是无状态、无连接的，它如何记住用户？
HTTP 协议本身无法识别两次请求是否来自同一个用户，但是浏览器可以配合会话机制保存信息。
补充区分：页面二次加载变快，是浏览器缓存 机制的作用，和登录会话不是一回事。 HTTP 本身没有连接的概念，传输层面的连接由 TCP 负责，通过
Connection头部控制长 / 短连接。
为什么需要会话管理？
如果服务器无法记住用户身份，每次访问受保护资源都要重新登录，使用体验会非常糟糕。
这是怎么来实现的
HTTP 协议是无状态的，服务器不会记住上一次请求的用户信息。如果不做额外处理：用户登录成功后，再次发起新的资源请求时，服务器无法识别这个用户，会要求反复登录，无法维持登录状态。
Cookie 就是用来解决这个问题的：用户提交登录表单，服务器校验账号密码通过之后，在 HTTP 响应报文里通过Set-Cookie首部，把身份信息下发给浏览器；浏览器收到后把 Cookie 持久保存在本地。后续浏览器向服务器发起每一次请求时，都会自动在请求头带上这份 Cookie 数据；服务器拿到 Cookie 后，从中校验用户身份，以此识别用户，维持登录状态，不用每次请求都重新提交账号密码。
这个保存分为保存再内存中,或者是保存再某个文件中,用的较多的是保存在文件中,想要实现这个登录七天就要再次登录只需要再来设置一个cookie过期的时限就可以
但是一起上面的单纯使用cookie是用bug的,要是黑客再你的电脑里获得了中国cookie,就会实现盗号的功能,
基于此又有了session+cookie的方法来进行实现,就是把账号和密码不存储再客户端本地,反而是存储再服务端,
客户端先请求登录页面，服务器返回登录 HTML 页面。用户填写账号密码提交表单，服务器收到信息校验通过后，在服务端本地用结构体存储该用户的会话信息 ，并生成唯一标识 sessionId。 服务器通过响应头Set-Cookie，把这个 sessionId 返回给浏览器，浏览器将 sessionId 保存在 Cookie 里。 后续客户端再去请求受保护资源时，会自动在请求 Cookie 中带上 sessionId。服务器拿到 sessionId，在本地会话表中查找对应的用户信息，完成身份识别，不用每次都传递账号密码。
Session 方案解决了账号明文泄露的问题，不再把用户敏感信息存放在 Cookie 中。 但它依然存在安全隐患：如果黑客窃取到用户的 Session ID，就可以冒充该用户访问资源，实现盗号。
这类风险无法从根源上彻底杜绝，但我们可以在上层业务逻辑中增加风控检测：系统持续识别用户行为，例如登录地点频繁切换、短时间大量发送消息等异常行为。一旦判定风险，服务器可以主动销毁对应的 Session ID，强制会话失效。