|
session
http是无状态的，一次请求结束，连接断开，下次服务器再收到请求，它就不知道这个请求是哪个用户发过来的。当然它知道是哪个客户端地址发过来的。
前提
- 浏览器输入url 进入页面 发起请求到后端拉页面信息
- 服务器会在服务端创建一个Session对象，并存储在服务端维护的map中
- 并把Session对象的id通过Cookie的方式写入到客户端浏览器，浏览器会把Session的id写入到本地的Cookie中
- 之后，每次浏览器向服务器发送请求，都会读取本地的cookie中的内容,并在请求的时候带上对应的cookie
- 通过Session机制，使得服务器能够识别出不同的浏览器以及同一浏览器的多次请求。
- session长时间不请求，服务端断开会话
session把用户的登录凭证直接存到服务器
- 只有在用户登录认证成功之后，并且往sesssion对象里面放入了用户登录成功的凭证，才能用来管理会话。
- . 只要拿到用户的session对象，看它里面有没有登录成功的凭证，就能判断这个用户是否已经登录。当用户主动退出的时候，会把它的session对象里的登录凭证清掉。
- 这种方式将会话信息存储在web服务器里面，所以在用户同时在线量比较多时，这些会话信息会占据比较多的内存；
- 分布式部署的时候，因为session是由单个服务器创建的，但是处理用户请求的服务器不一定是那个创建session的服务器，这样他就拿不到之前已经放入到session中的登录凭证之类的信息了
- 多个应用要共享session时，除了以上问题，还会遇到跨域问题，因为不同的应用可能部署的主机不一样，需要在各个应用做好cookie跨域的处理。
cookies 把用户的登录凭证直接存到客户端
- 把用户的登录凭证直接存到客户端的方案，当用户登录成功之后，把登录凭证写到cookie里面，并给cookie设置有效期，后续请求直接验证存有登录凭证的cookie是否存在以及凭证是否有效，即可判断用户的登录状态
- 服务端把上一步创建好的登录凭证，先对它做数字签名，然后再用对称加密算法做加密处理，将签名、加密后的字串，写入cookie。
- cookie的名字必须固定（如ticket），因为后面再获取的时候，还得根据这个名字来获取cookie值。这一步添加数字签名的目的是防止登录凭证里的信息被篡改，因为一旦信息被篡改，那么下一步做签名验证的时候肯定会失败。做加密的目的，是防止cookie被别人截取的时候，无法轻易读到其中的用户信息。
- 用户登录后发起后续请求，服务端根据上一步存登录凭证的cookie名字，获取到相关的cookie值。然后先做解密处理，再做数字签名的认证，就可以拿到原始存入的登录凭证了。然后判断凭证是否过期，如果过期，就需要用户再重新登录；如果未过期，则允许请求继续。
- 服务端只需要负责创建和验证登录cookie即可，无需保持用户的状态信息
- cookie有大小限制，存储不了太多数据
token
- 跟cookie的方式没有太多区别，只不过cookie里面写到cookie里面的ticket在这种方式下称为token，
- 这种方式不通过cookie进行token的传递，而是每次请求的时候，主动把token加到http header里面或者url后面，所以即使在native app里面也能使用它来调用我们通过web发布的api接口
- 这种方式用在web应用里也有跨域的问题，比如应用如果部署在a.com，api服务部署在b.com，从a.com里面发出ajax请求到b.com，默认情况下是会报跨域错误的，这种问题可以用CORS（跨域资源共享）的方式来快速解决
|