cookie和session

HTTP协议是无状态的，这里的「状态」到底指什么？

无连接：
每一个访问都是无连接，服务器挨个处理访问队列里的访问，处理完一个就关闭连接，这事儿就完了，然后处理下一个新的
无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接。
无状态：
协议对于事务处理没有记忆能力【事物处理】【记忆能力】
对同一个url请求没有上下文关系【上下文关系】
每次的请求都是独立的，它的执行情况和结果与前面的请求和之后的请求是无直接关系的，它不会受前面的请求应答情况直接影响，也不会直接影响后面的请求应答情况【无直接联系】【受直接影响】
服务器中没有保存客户端的状态，客户端必须每次带上自己的状态去请求服务器【状态】
cookie和session应该是完全实现了有状态这个功能

实验：假如没有cookie没有session，只有http的时候，那当一个注册用户访问这个购物网站的时候，会发生这些事情：

1. 前提情况：
   服务器肯定为每个注册用户建立了数据表，记录用户的数据
   http是无连接的
2. 第一步需要登录
   用户通过http把用户的用户名和密码发送给服务器，服务器把他们跟自己存有的用户资料对比，如果一致，则返回信息登录成功。
3. 然后用户点击某一商品页
   这个动作相当于输入一个商品页的网址
   假如商品页比较机密不对外公开，需要是用户才能访问
   而虽然http能传送用户名和密码，而且刚才也输入了，还验证成功了，但是因为服务器既不会记得你登录的状态，你的客户端也不会存储你刚才输入的用户名和密码
   所以因为这一次访问因为无法确定你的身份，只能访问失败
   这时候如果要解决这个问题，而且没有cookie没有session，那就只能你在访问网址的同时继续带上你的用户名和密码
4. 假设上一步的问题解决了，就是每次访问的时候都会手动输入用户名和密码，然后现在的情况是：你已经选了几件商品在你的购物车中，你想再添加一件商品，于是你点击某个商品旁边的加号
   这个动作也相当于输入一个网址，网址的内容是发送一个请求，往你的购物车中加入这个商品系统首先用你传来的用户名和密码验证你的身份，然后访问你的数据库，在其中的购物车属性下加一条数据，就是这个商品的数据操作结束后，返回操作成功，并结束访问。
5. OK，实验结束，看似没有cookie没有session也能凑合解决问题，其实两个操作都有很大的问题。
   a.你每访问一次需要权限的内容都需要在客户端输入用户名和密码，这一项的繁琐就不必赘述了
   b.你的每一次操作都要与系统底层的数据库进行交互
   多次少量的访问存在非常大的性能浪费。非常容易就能想到肯定是一次大量的操作更加有效率，于是就想到了缓存区
   3.你的非重要琐碎数据也被写进数据库中，跟你的主要数据放在一起一次次添加和删除购物车其实只是跟你这次浏览，或者叫这次会话有关，是临时的数据，跟用户的主要信息无关，它们没什么价值，纯粹的冗余数据（不排除现在有的公司觉得这种数据也有非常大的价值可以让它们巧妙的利用），用什么存放这些临时的数据，我们也很容易想到缓存区

由上所述，我们可以在http的基础上增加一些机制来解决上面出现的三个问题

1. 在用户端增加一个记录本是非常有必要的，正好官方加入的cookie机制跟这个一样，它的用处也确实是上面讨论的那样，一般就是用来标识访问者的身份

2. 在服务器增加一个缓存区能同时解决后两个问题
   有了这个缓存区作为一个数据缓冲，就不用一次次地访问数据库，浪费大量计算机资源，而是在最后统一归入数据库
   有了这个缓存区，你就不用把临时的数据放到数据库中了，只需要在你们交流告一段落之后，再把数据整理，把有用的数据归入数据库

3. 这里就自然引申出了一个重要的概念：会话，它作为一个缓冲存储区被从数据库中分离出来，理由并不生硬，它有其独特的重要且不可替代的作用。这个东西恰好跟官方加入的session机制一样
   3.1. 另外说一个非常具有迷惑性的容易让人对session的主要作用产生偏离的理解：认为session存在的价值就是给访问者分配一个sessionID代替用户名和密码，
   3.2. 为什么非常具有迷惑性，因为session确实做了这件事，而且也起到了很大的作用，所以它是对的，但是只对一半，而且没有涉及问题的本质，这种情况是最危险的（看似很有说服力，把你说服了，所以你很难有动力继续找下去，但是真实情况跟它有偏差，但是偏差不大，所以又很难把你说服回来，只有隐隐的不对劲，这个时候你离真实最近，也离真实最远）
   3.3. 那就顺便说说它为什么是对的，也就是用session做的另一件有用的事：
   给每个session一个ID，一方面用来方便自己查询，另一方面把这个ID给用户，用户下一次访问的时候就可以不用用户名和密码，而是直接使用这个ID来表明自己的身份
   首先，这个ID安全吗？这个ID比直接传用户名和密码安全吗？
   不严格加密的sessionID和用户名和密码一样，都不太安全
   但是相比较来说，sessionID要安全一些
   而使用https是安全的

4. 你很容易会想到，本来用户名和密码的组合还特地设置地比较复杂，你这换一组数字就代替了，是不是太不安全了？

5. 我们知道http协议本身是完全不加密的，如果使用用户名和密码，第一次访问是放在http头中，后边自动保存了密码就会放在cookie中，这些都完全没有加密，它的安全性基本为0，就是裸奔了，只要被窃取，那就丢失了
   所以，就这个意义来讲，sessionID的安全性跟使用用户名和密码没什么区别

6. 但是其实，虽然http本身不能加密，但是有些软件什么的，能在应用层面手动给你加密，比如QQ就会使用户名密码加临时验证码联合哈希，sessionID加一个时间戳简单加密也是非常常用的方法

7. 而且因为sessionID本身有有效期，即使丢了，也可能很快失效，造成的损失可能没那么大，而用户名跟密码丢了，那就大了

   有人在解释HTTP的无状态时，把它跟有连接对立，说是两种方式，也就是如果想不无状态，就必须有连接，但其实不然

有连接和无连接以及之后的Keep-Alive都是指TCP连接
有状态和无状态可以指TCP也可以指HTTP
TCP一直有状态，HTTP一直无状态，但是应用为了有状态，就给HTTP加了cookie和session机制，让使用http的应用也能有状态，但http还是无状态
开始TCP是有连接，后来TCP无连接，再后来也就是现在TCP是Keep-Alive，有点像有连接。