客户端状态的存储空间——Session

简介: http协议在设计之初被设计成无状态特性,客户端的每次请求在服务端看来都是独立且无任何相关性,同一个客户端第一次请求不会与第二次请求有任何关联,即使相隔时间很短。

http协议在设计之初被设计成无状态特性,客户端的每次请求在服务端看来都是独立且无任何相关性,同一个客户端第一次请求不会与第二次请求有任何关联,即使相隔时间很短。无状态的特性让请求变得很快速且服务器也更加高效,但是随着人们对浏览器功能要求的不断提高,由于无状态导致的不足更加明显,因为有些场景下本次处理需要用到之前的请求的一些信息,如果单纯靠http协议而没有额外的机制是无法办到的。

为了提供一种让一定时间内的每次请求都拥有记忆的会话机制,需要依靠http协议的基础上提供一种解决方案,当然由于涉及到相关信息的存储,所以需要在http协议外另外提供存储介质,通信的主体无非就是客户端和服务端,于是人们可以想到的就是借客户端或服务端存储状态信息,后来基于这两端的存储的方式都被支持。在客户端,一种叫做cookie的小文本被生成并存放在客户端的指定目录,每次请求时浏览器会从cookie找出此次请求服务器希望得到的一些状态并附加到http协议头部传往服务端,服务端由此实现通信的状态性;在服务端,有时需要保存的信息量很大,存放在客户端会导致一个问题,即每次客户端请求都要携带大量的信息到服务端,传输效率低下,这时如果把客户端的信息都放在服务端就能避免大量附加信息的传输,仅仅只要携带一个识别编号到服务端即可,服务端根据此编号找到此客户端对应的保存信息,至此实现通信的状态性。

所以两种方式可以用下图表示,上面的为客户端模式,客户端每次请求都会将本地保存的状态一起传到服务端,服务端通过这些状态便可以辨别哪个客户端的某些状态。而下面的图则是服务端模式,这时客户端要传的仅仅是一个id编号,它其实是客户端的身份标识,而其他状态变量保存在服务端,通过客户端id可以找到对应客户端的状态变量,所有客户端的状态被统一存放在服务端进行管理。

 

 

 

点击订购作者《Tomcat内核设计剖析》 


目录
相关文章
解决开启子线程,导致request上下文和session信息丢失问题
解决开启子线程,导致request上下文和session信息丢失问题
824 0
|
存储 JSON NoSQL
谁说Session只能存储在服务器端?
今天使用Koa遇到了一个诡异的问题,然后仔细研究了Koa-Session的实现原理,刷新了我的认知。好我们从头讲起。 先看看Session的原理是什么?
396 0
|
1月前
|
监控 物联网 智能硬件
MQTT 持久会话与 Clean Session 详解
【2月更文挑战第17天】
42 5
|
3月前
客户端禁用cookie后的会话数据保存问题
客户端禁用cookie后的会话数据保存问题
|
9月前
|
缓存 运维 监控
SSL Session默认设置导致线程阻塞了几十秒的案例分析
SSL Session默认设置导致线程阻塞了几十秒的案例分析
112 0
|
4月前
|
存储
HTTP是不保存状态的协议 如何保存用户状态
HTTP是不保存状态的协议 如何保存用户状态
50session的销毁会话和超时管理
50session的销毁会话和超时管理
83 0
50session的销毁会话和超时管理
|
前端开发 应用服务中间件 JavaScript
Session管理之超时设置和强制下线
关于Session,在Java Web开发中,为我们提供了很多方便,Session是由浏览器和服务器之间维护的。好吧,闲话不多说,下面让我们一步一步来实现它们。
1633 0