理解HTTP的无状态

发布于 2021-11-29  1k 次阅读


在学习计算机网络协议的时候,出现过HTTP无状态的介绍,但当时只是简单的理解为服务器与客户端的第二次会话无法辨别。

即,第一次会话,C --- S;第二次会话,S无法分别C还是不是第一次的那个C

 

但我个人感觉这样的理解可能会有偏差,因此查阅资料,进行整理

且看案例:

https://www.zhihu.com/question/23202402/answer/515842304

另外一个维度的分析:

https://www.zhihu.com/question/23202402/answer/527748675

 

摘要:

作者:灵剑
链接:https://www.zhihu.com/question/23202402/answer/527748675
来源:知乎
著作权归作者所有。商业转载请联系作者获得授权,非商业转载请注明出处。

HTTP所谓的“无状态协议”,其实跟Cookies、Session这些都没有什么大的联系,它描述的主要是通信协议层面的问题

常见的许多七层协议实际上是有状态的,例如SMTP协议,它的第一条消息必须是HELO,用来握手,在HELO发送之前其他任何命令都是不能发送的;接下来一般要进行AUTH阶段,用来验证用户名和密码;接下来可以发送邮件数据;最后,通过QUIT命令退出。可以看到,在整个传输层上,通信的双方是必须要时刻记住当前连接的状态的,因为不同的状态下能接受的命令是不同的;另外,之前的命令传输的某些数据也必须要记住,可能会对后面的命令产生影响。这种就叫做有状态的协议。(1.连接的状态要记住 2.之前发送的命令要记住)

相反,什么说HTTP是无状态的协议呢?因为它的每个请求都是完全独立的,每个请求包含了处理这个请求所需的完整的数据,发送请求不涉及到状态变更。(对应上述的有状态的协议,即首先连接不分阶段,连接上了就连上了,其次就是不需要记住之前的命令,因为每个请求包含了所有的信息)即使在HTTP/1.1上同一个连接允许传输多个HTTP请求的情况下,如果第一个请求出错了,后面的请求一般也能够继续处理(当然,如果导致协议解析失败、消息分片错误之类的自然是要除外的)可以看出,这种协议的结构是要比有状态的协议更简单的,一般来说实现起来也更简单,不需要使用状态机,一个循环就行了——不过,HTTP本身很复杂,这是另一个故事了,这里暂时不提。

无状态的协议有一些优点,也有一些缺点。

和许多人想象的不同,会话(Session)支持其实并不是一个缺点,反而是无状态协议的优点,因为对于有状态协议来说,如果将会话状态与连接绑定在一起,那么如果连接意外断开,整个会话就会丢失,重新连接之后一般需要从头开始(当然这也可以通过吸收无状态协议的某些特点进行改进);而HTTP这样的无状态协议,使用元数据(如Cookies头)来维护会话,使得会话与连接本身独立起来,这样即使连接断开了,会话状态也不会受到严重伤害,保持会话也不需要保持连接本身。另外,无状态的优点还在于对中间件友好,中间件无需完全理解通信双方的交互过程,只需要能正确分片消息即可,而且中间件可以很方便地将消息在不同的连接上传输而不影响正确性,这就方便了负载均衡等组件的设计。

无状态协议的主要缺点在于,单个请求需要的所有信息都必须要包含在请求中一次发送到服务端,这导致单个消息的结构需要比较复杂,必须能够支持大量元数据,因此HTTP消息的解析要比其他许多协议都要复杂得多。同时,这也导致了相同的数据在多个请求上往往需要反复传输,例如同一个连接上的每个请求都需要传输Host、Authentication、Cookies、Server等往往是完全重复的元数据,一定程度上降低了协议的效率。(缺点是请求更复杂,占用的空间更多,效率更低)

协议的状态是指下一次传输数据的时候能考虑到这次传输信息的状态。也有是说有状态协议以前的请求导致协议所处的状态会影响后续的状态,协议会根据上一个状态创建上下文。
http协议里就是无状态协议不用考虑上下文;每个请求都是与服务器的独立连接,即下一次请求到来的时候协议不用维护这次请求中客户机-服务器间交互的信息。


她喜欢所以就做咯