Cookie + Session 登录
HTTP 是一种无状态的协议,客户端每次发送请求时,首先要和服务器端建立一个连接,在请求完成后又会断开这个连接。这种方式可以节省传输时占用的连接资源,但同时也存在一个问题:每次请求都是独立的
,服务器端无法判断本次请求和上一次请求是否来自同一个用户,进而也就无法判断用户的登录状态。
为了解决 HTTP 无状态的问题,Lou Montulli 在 1994 年的时候,推出了 Cookie
。
Cookie 是服务器端发送给客户端的一段特殊信息,这些信息以文本的方式存放在客户端,客户端每次向服务器端发送请求时都会带上这些特殊信息。
有了 Cookie
之后,服务器端就能够获取到客户端传递过来的信息了,如果需要对信息进行验证,还需要通过 Session
。
客户端请求服务端,服务端会为这次请求开辟一块内存空间,这个便是 Session 对象。
有了 Cookie
和 Session
之后,我们就可以进行登录认证了。
Cookie + Session 实现流程
Cookie + Session
的登录方式是最经典的一种登录方式,现在仍然有大量的企业在使用。
用户首次登录时:
- 用户访问
a.com/pageA
,并输入密码登录。 - 服务器验证密码无误后,会创建
SessionId
,并将它保存起来。 - 服务器端响应这个
HTTP
请求,并通过Set-Cookie
头信息,将SessionId
写入Cookie
中。
服务器端的 SessionId 可能存放在很多地方,例如:内存、文件、数据库等。
第一次登录完成之后,后续的访问就可以直接使用Cookie
进行身份验证了:
- 用户访问
a.com/pageB
页面时,会自动带上第一次登录时写入的Cookie
。 - 服务器端比对
Cookie
中的SessionId
和保存在服务器端的SessionId
是否一致。 - 如果一致,则身份验证成功。
Cookie + Session 存在的问题
虽然我们使用Cookie + Session
的方式完成了登录验证,但仍然存在一些问题:
- 由于服务器端需要对接大量的客户端,也就需要存放大量的
SessionId
,这样会导致服务器压力过大。 - 如果服务器端是一个集群,为了同步登录态,需要将
SessionId
同步到每一台机器上,无形中增加了服务器端维护成本。 - 由于
SessionId
存放在Cookie
中,所以无法避免CSRF
攻击。