1. 由来
long long ago……，在以前浏览器只是用来查看文档的，并没有其它增删改的之类的操作。后来万恶的产品经理提出了各种奇葩的需求，为了解决产品经理的特殊需求，引入了cookie和session的概念，用来保存HTTP的请求状态。
（PS：比如你增加一个东西，我可以记录cookie或session。你删除一个东西我也可以删除一个cookie或者session。而cookie是存储在你本地，session是存储在服务器上的）
2. 奇葩需求
用户所做的操作配置，换了另外一台电脑能继续使用原来的配置
3. 方案一
把用户的所有配置信息都存储在cookie里，用户在换电脑后，重新复制以前的cookie到现在电脑上的浏览器里。
4. 发现问题
第一种方案虽然也可行，但是数据存在用户这里太多了，容易丢，或者被篡改，而且操作也很麻烦，用户体验不友好。
5. 方案二
把用户配置信息存储到服务器上，生成一个唯一ID（sessionID）给用户，用户下次使用这个唯一ID可以直接来服务器上拿数据。
6. 发现问题
然后你可能就会发现了，其实其他人也是可以拿这个唯一的ID进行冒充。比如你在取钱的路上，被劫匪打劫了银行卡，顺便还劫了个色。然后拿着你的银行卡就可以取钱了，不管是不是你本人。
7. 解决问题
所以为了保护你在取钱的路上不被打劫，所以银行（服务器）需要一队武装部队进行护送你（HTTPS），银行要配备武装部队，你需要去服务商那拿个个证书（不要以为可以免费请到武装部队，所以还是资金的问题），但是这个问题被摒弃了。
8. 最终方案
目前先使用方案二，因为帮别人保管，比让用户保管好的多。传输一个cookie给服务器上，获取session信息。比传输多个cookie好的多。
9. 行动需求
session保证唯一。（我不管你怎么实现，反正你给我保证唯一就行）
10. 存储方案
前期需求，先存储在内存，省时省力，还不需要另外花钱买配置。二次开发后，在考虑存储在数据库，缓存之类的，反正到时候在说，万一还没上线就死了呢。
11. 安全需求
前期项目人员紧缺，资金匮乏，咱们先怎么简单怎么来，那就明文传输吧。（所以这就是这么多坑的原因了？程序猿：“这锅我不背”）
12. 实行方案
- 浏览器第一次请求网站， 服务端生成 Session ID。
- 把生成的 Session ID 保存到服务端存储中。
- 把生成的 Session ID 返回给浏览器，通过 set-cookie。
- 浏览器收到 Session ID， 在下一次发送请求时就会带上这个 Session ID。
- 服务端收到浏览器发来的 Session ID，从 Session 存储中找到用户状态数据，会话建立。
- 此后的请求都会交换这个 Session ID，进行有状态的会话。
（复制的，懒得写了，反正意思就是，你想要工资，就带上你的身份证过来我这，我接过从你手（cookie）里面给我的身份证（sessionID），我从文档库（服务器）里找到你的员工资料（session信息），然后在给你工资。没有你员工信息的话，你可以考虑先入个职啥的，给你办个身份证，然后下次就可以过来拿工资，咋样考虑下呗）
13. 项目总结
不管是存储在cookie里，还是存储在session里，都可以实现需求，但是具体使用哪种实现就看需求了。但是使用方案二的session的时候会依赖与浏览器的cookie
14. cookie和session的区别
- cookie是存储在本地的，所以可以离线使用。而session是存储在服务器的，安全更高些。
- cookie容易被篡改数据。而session在明文传输的时候容易被劫持唯一ID，冒充用户。
- session依赖与cookie，而cookie不需要依赖与session。
学到了一个新词，不吝斧正
