记录下Cookie与Session

 

HTTP 是无状态的，服务端收到两个请求时，它并不能知道这两个请求之间有什么关系（比如是否是由同一个客户端发出，这也是最重要的）。

为了解决这个问题，浏览器引入了 Cookie 了机制，
即首次请求服务端后，由服务端返回一个 Set-Cookie 响应标头，浏览器收到后会自动存储（也可以是接口形式返回，前端由 JS 来操作写入 Cookie）；
下次给发送同域请求时，会在请求标头中携带刚才存储的值。
服务端收到 Cookie 后就可以依此判断这个请求由谁发出的了。

这么做有两个弊端。
一是 Cookie 携带的信息过多的话，影响带宽；
二是 HTTP 几乎是明文传输的，Cookie 中如果有敏感信息的话容易被窃取或篡改。

那么能不能 Cookie 只发送一个 固定的编号，
而这个编号所代表的真实 Cookie 信息只存储在服务端上？
因此引入了 Session。
所以说，Session 是 Cookie 的子集，二者是被包含和包含的关系。

在 Cookie 中，服务端需要知道浏览器是否重启了吗？不需要。
它只知道某个请求带没带 Cookie、带的这个 Cookie 是不是有效的。
如果没带，那么这个请求对于服务端来说就是首次请求。

那么作为 Cookie 子集的 Session，它需要吗？答案不言而喻。(不需要,请求的时候没有携带SessionID,也是视为首次请求)

P.S. Cookie 的提出只是为了缓解 HTTP 无状态的问题，除此之外还有其他方案可以实现。
比如每个请求携带固定的查询字符串、或者是添加 Authorization 请求标头（如 JWT）等等。
只不过 Cookie 是浏览器天然支持而已。

 

后端不知道浏览器重启，后端只知道请求带没带 sessionId
如果没有额外配置，保存 sessionId 的 cookie 的默认有效期是 session，就是浏览器关闭就删除
所以这里的逻辑是

1：浏览器关闭，保存 sessionId 的 cookie 被删除:
2：浏览器再次请求，后端找不到 cookie 里的 sessionId
3：后端重新生成 session 和 sessionId，并把 sessionId 设置到浏览器的 cookie 里

 

session.sessionid 是服务器生成的只要session不过期它就有效并且是唯一的。
每个用户有唯一的session.SessionId，这是只读的属性