cookie的基本流程 :

1. 浏览器 -->服务器端

发送http请求

2. 服务器端

服务器进行cookie设置,也就是set-cookie,cookie中有名Name和值Value两个重要属性,服务器会把名和值属性里面的内容填充完整

3. 服务器 -->浏览器

服务器将cookie发给浏览器

4. 浏览器端

浏览器会保存从服务器传来的cookie,这样浏览器发送的每个请求都会自动附加上这个cookie即:cookie就是一种存储在浏览器的数据而已

打开浏览器可以直接看到保存了哪些cookie,也就是说将用户名和密码放在cookie是很不安全的,电脑被黑,在cookie的重要信息就会泄露,为了补充这一弊端,产生session会话

session会话 :

浏览器访问服务器就是会话的开始,比较模糊的是会话关闭的时间,因此每个网站对于与每个用户的会话都设定了时间以及唯一的ID,这里的ID就是session ID,时间是结束会话的时间,因为是服务器自己设定的,所以一般保存在数据库里面

有用户名为什么要多设置一个session ID?

访问服务器的过程:

浏览器 -->服务器端 : 使用用户名密码发送给服务器

服务器 : 核对账户密码正确性,认证成功,在服务器创建一个Session ID 和会话结束时间

服务器端 -->浏览器 : 服务器设置cookie , 把Session ID 和会话结束时间(cookie的有效期)发送给浏览器.

浏览器 : 浏览器拿到cookie后进行保存 注意 : 浏览器保存的不是账号密码,保存到是session ID(没有规律的字符串),浏览器保存了cookie以后,会利用cookie的核心特点(每个请求都会自动发送cookie到相应服务器那里),浏览器接下来的每次访问都会自动发送session ID给服务器,直到cookie的有效期失效后,浏览器一般就会自行删除这个cookie,那么在cookie失效之后,用户就需要重新输入账号密码了

注意 : Session ID通常是一串没有规律的字符串,被外来入侵时,黑客不能拿着session ID推断出用户的账号密码 . 服务器在发送cookie之前是会对这个含有session ID的cookie进行签名,一一旦session ID被修改,就会变成服务器识别不了的字符串.

互联网发展用户群体越来越大,如果服务器依旧使用基于cookie的session,在特定时间有大量用户访问服务器的时候,服务器就会面临可能需要存储大量Session ID在服务器里面,但是如果有多台服务器,一台服务其存储了Session ID,又会面临分享Session ID给其他服务器,因为可能出现服务其的超载,需要分配一些用户到其他服务器,其他服务器需要通用的Session ID才能避免用户再次输入用户名和密码,但是服务器这样分享也不方便,于是就让数据库存储SessionID,但是如果数据库崩溃了,又会影响服务器获取Session ID,各种原因和需求的前提下,就出现了一种叫JWT的技术,就是(json web token)

token基本流程:

首先用户第一次登录网页后:服务器生成一个JWT,服务器不需要保存这个JWT,只需要保存JWT签名的密文

服务器:

接着服务器把JWT发送给浏览器,可以让浏览器以cookie或者storage的形式进行存储

假设浏览器以cookie的形式保存下来,这样用户每次请求都会把这个JWT发给服务器,用户就不需要重新输入账号密码了,和session很类似,不同的是session存储在服务器端,token存储在用户那边

token的安全性:
JWT是由三部分组成的:

header部分:声明需要用什么算法生成标签

payload部分:是一些特定的数据,比如有效期之类的

signature

header和payload两部分的内容会经由Base64编码,(编码不是加密,很容易解码)

虽然JWT不保存在服务器这里,但是服务器需要爆粗一段密码,这段密码需要结合两段编码进行算法运算,最终得到签名信息,这里使用的算法就是刚刚header声明的算法,签名的信息也就是signature部分了,这样一个完整的JWT就可以发送给客户端了