http中cookie、session、token是啥子？
http是无状态的，每个请求间相互独立
也就是说我用第一个数据包进行登录，第二个数据包去请求服务器时，服务器无法确认我们是否已经登录。这时就需要一些新的技术来解决这个问题。
下面就以登录为例子来讲这个问题
cookie+session方案
既然我们需要让服务站知道我们已经登录了，那么可以让服务器保存我们的登录信息
session ID 1024100：A用户-已登录-登录时间12:00
session ID 1024101：B用户-已登录-登录时间10:00
然后让浏览器拿着ID作为身份标识符去请求服务器，服务器收到后拿出来对应ID的信息作为登录信息。这样就解决了这个问题，在每次请求中服务器通过浏览器提供的ID值去判断用户是否已经登录。
为了让浏览器在每次请求自动发送某个字段给服务器，我们使用了cookie这项技术
服务器把sessionID放进浏览器的cookie里面，这样每次请求的时候，浏览器就会自动发送cookie来验证身份
token方案
为什么需要token方案原因有2
-
提高性能（不使用session）
-
防御csrf（不使用cookie）
性能问题
前面说到，session的方案会将登录信息存放在服务器，这个存放是存放在内存中的，如果存放在数据库那么效率就太慢了。如果使用了多台服务器做负载均衡，A服务器又不能跑去B服务器的内存里面查这个session的内容，这样就会出现问题。
要是能把登录信息存放在浏览器（且保证该信息无法被篡改），那么服务器就只需要验证这些信息，而不是存放这些登录信息。这里就用到了签名技术。
服务器在用户登录成功后将登录信息进行签名，并返回给浏览器（称为token），浏览器下次请求的时候把token还回来，服务器只需要用私钥验证签名是否正确，如果正确那么信任此用户的登录信息。（虽然单台服务器上慢了，但是能省内存，而且可以做负载均衡）
CSRF
用户在访问一个网站时，会将cookie自动发送出去，此时容易出现CSRF问题。
如果我们把这个认证的信息token放在cookie中，一样会出现问题（一样会被自动发送出去）
所以我们干脆不能采用cookie的方案存放token，而是另外起一个字段
token的问题
我们知道token就是把信息签名发出去，那么这里又会出现问题（比如强制下线）
强制下线很好理解，token已经签名发出去了，这时候哪怕用户修改密码，token也是有效的。（session的话直接删除即可）或者说一个用户有违规操作，要踢他下线，单纯用token也是困难的。
那么可以使用token+redis的方案，redis存放一部分信息（比如用户是否有违规操作）
标签：http,登录,技术,会话,token,session,cookie,服务器,浏览器 From： https://www.cnblogs.com/Aixve/p/18010069