今天完成的事情：

了解任务的运行过程

明天计划的事情：

动手做

暂无

收获：

关于为什么引入Cookie的解释：

HTTP无状态协议：意思是在HTTP这个级别，协议对于发送过的请求或者响应都不做持久化处理。

目的是：为了更快地处理大量事务，确保协议的可伸缩性。

可这样带来一个问题，举个例子，当你逛天猫或者京东时，跳到该站的其他页面后，就不能保持登录状态，这样很多信息就会看不了。

解决办法是，引入Cookie技术：Cookie技术通过在请求和响应报文中写入Cookie信息来控制客户端的状态。

举个例子：

笔者曾经常去的一家咖啡店有喝5杯咖啡免费赠一杯咖啡的优惠，然而一次性消费5杯咖啡的机会微乎其微，这时就需要某种方式来纪录某位顾客的消费数量。想象一下其实也无外乎下面的几种方案：

1、该店的店员很厉害，能记住每位顾客的消费数量，只要顾客一走进咖啡店，店员就知道该怎么对待了。这种做法就是协议本身支持状态。

2、发给顾客一张卡片，上面记录着消费的数量，一般还有个有效期限。每次消费时，如果顾客出示这张卡片，则此次消费就会与以前或以后的消费相联系起来。这种做法就是在客户端保持状态。（注：这种是Cookie，信息保存在客户这边）

3、发给顾客一张会员卡，除了卡号之外什么信息也不纪录，每次消费时，如果顾客出示该卡片，则店员在店里的纪录本上找到这个卡号对应的纪录添加一些消费信息。这种做法就是在服务器端保持状态。（注：这种是Session，信息保存在咖啡店（服务器）这边）

客户端第一次发送请求，服务器端生成Cookie（记住是向谁发送的），在响应中添加Cookie后返回。客户端第二次发送请求（此时客户端以保存有Cookie），服务器将传入过来的Cookie值对比服务器上的记录，最后得到之前的状态信息。

Session由来：

上面介绍了Cookie的相关知识，其中介绍了必须采用一种机制来唯一标识一个用户，同时记录该用户的状态。

于是就引入了第一种机制:Cookie机制;那么第二种就是Session机制。

Session机制：采用的是在服务器端保持Http状态信息的方案。结合可以看出两种机制最明显的区别就是cookie是存储子在客户端，

而Session是存储在服务器端。

## Session的定义即基本介绍

Session，有始有终的一系列动作/消息的意思，其实我们举一个小例子来说:比如我们一次打电话，从接起电话到你挂断电话的一系列过程可以称为一个Session。

Session在Web开发环境下的语义又有了新的扩展，它的含义是指一类用来在客户端与服务器端之间保持状态的解决方案。

有时候Session也用来指这种解决方案的存储结构。

1、用户向服务器发送用户名和密码。

2、服务器验证通过后，在当前对话（session）里面保存相关数据，比如用户角色、登录时间等等。

3、服务器向用户返回一个 session_id，写入用户的 Cookie。

5、服务器收到 session_id，找到前期保存的数据，由此得知用户的身份。

也就是说，如果浏览器禁用了 Cookie，Session 也会失效。Session也有另外一种方式可以应用，比如在 url 中传递 Session ID，简称： URL重写

就是把session id附加在URL路径的后面，附加的方式也有两种，一种是作为URL路径的附加信息，

简单了解Cookie和Session后，在来考虑任务的运行逻辑，过程。

Session这种模式的有问题，扩展性（scaling）不好。单机当然没有问题，如果是服务器集群，或者是跨域的服务导向架构，就要求 session 数据共享，每台服务器都能够读取 session。

举例来说，A 网站和 B 网站是同一家公司的关联服务。现在要求，用户只要在其中一个网站登录，再访问另一个网站就会自动登录，请问怎么实现？

一种解决方案是 session 数据持久化，写入数据库或别的持久层。各种服务收到请求后，都向持久层请求数据。这种方案的优点是架构清晰，缺点是工程量比较大。另外，持久层万一挂了，就会单点失败。

另一种方案是服务器索性不保存 session 数据了，所有数据都保存在客户端，每次请求都发回服务器。于是JWT （JSON Web Token）就应运而生了。