这套机制的功能
你可以想象一下,你是一个微信群的群主,群里只有你一个人是实名的,其他所有人都是匿名的,而且是名字头像完全都一样的匿名,以至于你完全分不清谁是谁,连哪两句话是同一个人说的都不知道。这里的群友,就是 http 请求中的客户端,群主就是 http 请求中的服务端。
cookie 的任务是当服务端拿到客户端发来的请求时,可以分的清这是谁发的,相当于匿名的群友都各自给自己取了个假名字,这样你起码知道哪些话是同一个人说的了。改微信名是群友们自己打开设置去改的(虽然改是群友改的,但是这个名字其实是群主分配的,后文中可以看到),所以在 http 中 cookie 储存在客户端,由客户端维护。
session 的任务是方便你记住群友们的各项信息,比如群友 “cxk” 说自己爱打篮球,“wyf” 说自己喜欢 rap ,你就拿个小本本记下来这些群友的爱好,方便之后和各位群友交流。小本本记下来,是由群主去记的,所以 session 储存在服务端,由服务端维护。
网上经常会看到一些比较 cookie 和 session 区别的文章,博主认为这完全是两样东西,各自有不同的使命,是无法拿来比较的,这些文章一度阻碍博主理解这套机制的原理。
这套机制具体是实现方式(非常具体)
Cookie
//这是以 tomcat 为例的一段代码,其他语言和服务器软件也是异曲同工
httpResponse.addCookie(new Cookie("name", "value"));
服务端在加入这句代码后,服务器软件即会在返回的 http 报头中加上这样一条字段 :
set-Cookie:name=value;下图中的 ab={} ,ab 就是这条 cookie 的 name,{} 就是这条 cookie 的 value
http 返回头
当浏览器收到这一条返回头后,会把这些信息都存到一个文件中,如果你用的是 chrome,直接在地址栏中输入 chrome://settings/cookies 就可以查看这个文件:
可以看到 cookie 中的属性有 域名 这一条属性,这条 cookie 的意思就是,当我们再次访问 juejin.im 这个域名时,会在 http 头中带上这条信息:
Cookie总结
Cookie 可以说它是在 http 头中的一条字段,发明人是制定 http 协议的人,发挥作用的整个流程是这样:
- 服务端将 cookie 写入 http 返回头
- 客户端在返回头中取出 cookie 在本地存下来,之后访问同样的域名时将它带上
Session
session 完全是由 web 容器(如tomcat)实现的,整套机制的实现不需要浏览器和 http 协议做额外的配合,只要它们支持 cookie 就行了。
当我们在服务端第一次用这样的代码获取一个 session 并向其中添加属性时:
HttpSession httpSession = httpRequest.getSession();
httpSession.setAttribute("爱好", "篮球");
web 容器 会帮你干三件事:
- 生成一个 ID (在 tomcat 中这个 ID 的名字就叫 JSESSIONID)。
String JSESSIONID = “cxk”;
//JSESSIONID 在真实情况下,通常是由服务器软件随机生成的一条字符串
- 在一个 <JSESSIONID,HttpSession> 的 Map 中添加一条记录
HttpSession httpSession = new HttpSession();
sessionMap.put(JSESSIONID,httpSession);
//随后就会运行你的代码 httpSession,setAttribute("爱好\", "篮球")
- 在返回的 cookie 中添加一条记录
httpResponse.addCookie(new Cookie("JSESSIONID", JSESSIONID));
好了,到了这里应该就十分明了了,当客户端再来请求时,就会带上 "JSESSIONID" = “cxk" 这条信息,服务端拿着这条信息去 sessionMap 里面一查,把对应的 httpSession 拿出来,就可以获取到这位客户的属性了,知道他的爱好是打篮球。
Session总结
Session 的发明人是设计 web 容器的人发明的,容器不同,实现的方式也就会有一些细微的差别,上文用 tomcat 举例,但是 tomcat 真实的实现源码也远不如上文中那么简单,因为还要涉及一些多机共享或持久化的东西,以上内容可以帮助理解概念。
在现代的 web 系统中都使用的是分布式系统,仅凭 cookie 和 session 机制也无法达到记录用户的目的了,之后会有单点登陆相关的讲解。
网友评论