这套机制的功能
你可以想象一下，你是一个微信群的群主，群里只有你一个人是实名的，其他所有人都是匿名的，而且是名字头像完全都一样的匿名，以至于你完全分不清谁是谁，连哪两句话是同一个人说的都不知道。这里的群友，就是 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
当浏览器收到这一条返回头后，会把这些信息都存到一个文件中，如果你用的是 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 机制也无法达到记录用户的目的了，之后会有单点登陆相关的讲解。
