难住了N个面试者，http协议无状态中的 "状态" 到底指的是什么？！

难住了N个面试者，http协议无状态中的 "状态" 到底指的是什么？！

引子

找了很多资料不仅没有发现有一针见血正面回答这个问题的，而且有些解释还充斥了各种错误，看着看着就觉得心里憋着一股浊气吐不出来

然后开始不断探索解决这个问题。。。

最终很高兴的是我找到了让人满意的答案，先卖个关子，各位如果着急可以直接拉到最下查看

正文

2.无连接指的是什么

每一个访问都是无连接，服务器挨个处理访问队列里的访问，处理完一个就关闭连接，这事儿就完了，然后处理下一个新的 无连接的含义是限制每次连接只处理一个请求。服务器处理完客户的请求，并收到客户的应答后，即断开连接

对于【无状态】，我看到很多隔着一层磨砂玻璃一样的模糊说法（官方或者教程里的说法），看着非常难受（但其实算是对的）（后来我发现我为什么觉得它看着难受了，因为他们引入了很多新的，而且明显是一个可能用在很多地方的广义名词，这些词最大的作用就是，混淆概念，下面我标注了）

协议对于事务处理没有记忆能力【事物处理】【记忆能力】 对同一个url请求没有上下文关系【上下文关系】 每次的请求都是独立的，它的执行情况和结果与前面的请求和之后的请求是无直接关系的，它不会受前面的请求应答情况直接影响，也不会直接影响后面的请求应答情况【无直接联系】【受直接影响】 服务器中没有保存客户端的状态，客户端必须每次带上自己的状态去请求服务器【状态】

我必须得到确切而具体的解释！

这几点给了我下一步思考的方向：

1.【服务器中没有保存客户端的状态，客户端必须每次带上自己的状态去请求服务器 】这里的客户端的状态是不是确切地指服务器没有保存客户的信息呢？但显然不是啊

2.【HTTP无状态的特性严重阻碍了这些应用程序的实现，毕竟交互是需要承前启后的，简单的购物车程序也要知道用户到底在之前选择了什么商品】我对此质疑为什么无状态就不能实现购物车呢？服务器就不能存储东西了么？

3.【 每次的请求都是独立的，<它的执行情况和结果>与<前面的请求>和<之后的请求>是无直接关系的】我觉得这个说法比较靠谱，但是所谓的不同请求间的没有关系，是指的请求内容没有关系，还是只是指请求本身没有关系？

请求内容没有关系只可能是服务器上不存有用户数据才可能啊，但是显然是存有的啊 请求本身没有关系，这又有什么意义呢，每一次的请求有什么价值？

1.前提情况：

2.第一步需要登录

这个动作也相当于输入一个网址，网址的内容是发送一个请求，往你的购物车中加入这个商品 系统首先用你传来的用户名和密码验证你的身份，然后访问你的数据库，在其中的购物车属性下加一条数据，就是这个商品的数据 操作结束后，返回操作成功，并结束访问

5.OK，实验结束，看似没有cookie没有session也能凑合解决问题，其实两个操作都有很大的问题

你每访问一次需要权限的内容都需要在客户端输入用户名和密码，这一项的繁琐就不必赘述了 你的每一次操作都要与系统底层的数据库进行交互  多次少量的访问存在非常大的性能浪费。非常容易就能想到肯定是一次大量的操作更加有效率，于是就想到了缓存区 你的非重要琐碎数据也被写进数据库中，跟你的主要数据放在一起 一次次添加和删除购物车其实只是跟你这次浏览，或者叫这次会话有关，是临时的数据，跟用户的主要信息无关，它们没什么价值，纯粹的冗余数据（不排除现在有的公司觉得这种数据也有非常大的价值可以让它们巧妙的利用），用什么存放这些临时的数据，我们也很容易想到缓存区

经过这个模拟访问实验，结合前面的思考方向，我们知道了三点：

服务器上肯定存有用户的数据，你提交的增删改查它也能够处理，所以这句话中【服务器中没有保存客户端的状态】的状态并不是指用户的数据，我们的猜测不对 我们的质疑对了，无状态能实现购物车，可以通过服务器上存有的用户数据来实现 但是，使用上面这种方式实现购物车，存在三个比较大的问题。由此，我们不禁会想，这三个问题的解决是不是跟我们不确切了解的【状态】一词有关？于是，接下来我们来通过解决这三个问题来把【状态】的意义探寻下去

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

2.在服务器增加一个缓存区能同时解决后两个问题

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

3.这里就自然引申出了一个重要的概念：会话，它作为一个缓冲存储区被从数据库中分离出来，理由并不生硬，它有其独特的重要且不可替代的作用。这个东西恰好跟官方加入的session机制一样

3.1.另外说一个非常具有迷惑性的容易让人对session的主要作用产生偏离的理解：认为session存在的价值就是给访问者分配一个sessionID代替用户名和密码，

3.2.为什么非常具有迷惑性，因为session确实做了这件事，而且也起到了很大的作用，所以它是对的，但是只对一半，而且没有涉及问题的本质，这种情况是最危险的（看似很有说服力，把你说服了，所以你很难有动力继续找下去，但是真实情况跟它有偏差，但是偏差不大，所以又很难把你说服回来，只有隐隐的不对劲，这个时候你离真实最近，也离真实最远）

3.3.那就顺便说说它为什么是对的，也就是用session做的另一件有用的事：

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

3.  所以，就这个意义来讲，sessionID的安全性跟使用用户名和密码没什么区别

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

6.  所以总结就是：

然后，使用sessionID有哪些好处

1.  方便直接根据ID查询用户对应的session

2.  加密的时候计算量小

3.  安全性不会降低，甚至还更高一些

所以这个无状态指的是【没有对 本次会话 设置一个缓存区，记录这次会话的状态，缓存区包括服务器端和用户端】但好像还是没有点破关键（主要是觉得跟前面那些官方对状态的说法不太吻合，甚至没有对应关系）

2.那就类比一下吧，另一个天然有状态的机制叫TCP

如果有状态的意思是它的每次请求是有联系的，那么有状态的TCP的样子是：假如一份数据分了三份TCP包发送，那这个包上面会标明这是第几个包，会标明这个包跟那几个包是有联系的，有什么联系

4.诶，等等，好像能类比：

4.3.不过我灵机一动，从另一个角度来想，好像解决了这个问题：

通过在服务器端开辟一块缓存区，存储、记忆、共享一些临时数据，你就可以： 协议对于事务处理有记忆能力【事物处理】【记忆能力】 对同一个url请求有上下文关系【上下文关系】 每次的请求都是不独立的，它的执行情况和结果与前面的请求和之后的请求是直接关系的【不独立】【直接关系】 服务器中保存客户端的状态【状态】

6.  所以，这个状态，加上前面说的客户端也有cookie，就是指，客户端和服务器在临时会话中产生的数据！而前面也说道了，使用缓存区保存临时会话中的数据是多么重要

所以状态不仅包括不同URL访问之间的关系，还有对其他URL访问的数据记录，还有一些其他的东西，所以更确切地说，状态应该是【实现了这些东西所凭借的后面的缓存空间】中的客户的临时数据 cookie和session应该是完全实现了有状态这个功能

一种常见的对状态的误解：

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。