客户端请求服务器，属于http请求，http请求是无状态的,即每次服务端接收到客户端的请求时，都是一个全新的请求，服务器并不知道客户端的历史请求记录；也就是说它分辨不了到底是张三还是李四。

所以当用户从客户端请求一次登录后，登录成功，再次进行请求时，因为tomcat不能识别这两次会话都是来自同一个浏览器，即服务端不知道客户端的历史请求记录；就会再次弹出登录对话框。

为了解决客户端与服务端会话同步问题。这便引出了下面几个概念：cookie、session。

Cookie

一个HTTP cookie的（网络Cookie，浏览器cookie）是一小片数据的一个服务器发送到用户的网络浏览器。浏览器可以存储它并将其与下一个请求一起发送回同一服务器。通常，它用于判断两个请求是否来自同一个浏览器 - 例如，保持用户登录。它记住无状态 HTTP协议的有状态信息。

Session

客户端请求服务端，服务端（Tomcat）会为这次请求开辟一块内存空间，这个对象便是Session对象， 存储结构为ConcurrentHashMap。

session的目的：弥补HTTP无状态特性，服务器可以利用session存储客户端在同一个会话期间的一些操作记录。

因此，session在服务端保存信息，cookie在客户端保存信息。

虽然Http是无状态的，但是HTTP cookie允许使用有状态会话。使用标头可扩展性，HTTP Cookie被添加到工作流中，允许在每个HTTP请求上创建会话以共享相同的上下文或相同的状态。

1、服务器如何判断客户端发送过来的请求属于同一个会话？

用session id区分；session id 相同即认为是同一个会话；

在tomcat中session id中用JSESSIONID来表示；

2、服务器、客户端如何获取sessionID?SessionID在期间是如何传输的？

服务器第一次接收到请求时，开辟了一块Session空间（创建了Session对象），同时生成一个Session id，并通过响应头的Set-Cookie：“JSESSIONID=XXXXXXX”命令，向客户端发送要求设置cookie的响应； 客户端收到响应后，在本机客户端设置了一个JSESSIONID=XXXXXXX的cookie信息，一般来讲后端为设置的情况下，该cookie的过期时间为浏览器会话结束；

接下来客户端每次向同一个网站发送请求时，请求头都会带上该cookie信息（包含Session id）； 然后，服务器通过读取请求头中的Cookie信息，获取名称为JSESSIONID的值，得到此次请求的Session id；

3、Session是保存在服务端的，为什么后续请求会读取到session？

因为请求会包含一个sessionId，该值存储在cookie中，服务器通过这个sessionId找到对应的session（之前讲过session底层是map结构的）。

注意：服务器只会在客户端第一次请求响应的时候，在响应头上添加Set-Cookie：“JSESSIONID=XXXXXXX”信息，接下来在同一个会话的第二第三次响应头里，是不会添加Set- Cookie：“JSESSIONID=XXXXXXX”信息的； 而客户端是会在每次请求头的cookie中带上JSESSIONID信息；

为什么关闭浏览器后，好像session就过期了？

服务端产生session后，会把session的id传回客户端，这样每个客户端就有了一个唯一的 ID，客户端只要传回这个 ID 就行了，这个 ID 通常是 NANE 为 JSESIONID 的一个 Cookie，value为session的id。

     session在服务端保存信息，是否关闭浏览器和session销毁无关，即：即使关闭浏览器，session还是存在的。但是为什么关闭浏览器后，好像session就不存在了。 这就是上文提到的，sessionID是通过cookie存再客户端的，并且存储的这个cookie的key为“JSESIONID”，value为sessionID的值。但是cookie的key(JSESIONID)的生存周期一般是浏览器关闭后消失，浏览器关闭后，JSESIONID消失。正常流程是前端请求服务端时会把cookie带过去，但是现在，因为浏览器关闭，JSESIONID为null。服务端再想通过JSESIONID获取session，就无法获取，这也是为什么关闭浏览器后，好像session就过期了。

解决办法：修改浏览器关闭后JSESIONID消失的默认设置，手动设置JSESSION的过期时间。

即以下：

这样即使浏览器关闭，服务端仍然可以通过request.getSession().getAttribute("aa")获取值。

Session与Cookie区别和联系：

Cookies是属于Session对象的一种。但有不同，Cookies不会占服务器资源，是存在客服端内存或者一个cookie的文本文件中；而“Session”则会占用服务器资源。所以，尽量不要使用Session，而使用Cookies。但是我们一般认为cookie是不可靠的，session是可靠地，但是目前很多著名的站点也都以来cookie。有时候为了解决禁用cookie后的页面处理，通常采用url重写技术，调用session中大量有用的方法从session中获取数据后置入页面。

Cookies与Session的应用场景：

Cookies的安全性能一直是倍受争议的。虽然Cookies是保存在本机上的，但是其信息的完全可见性且易于本地编辑性，往往可以引起很多的安全问题。所以Cookies到底该不该用，到底该怎样用，就有了一个需要给定的底线。

先来看看，网站的敏感数据有哪些。

登陆验证信息。一般采用Session(“Logon”)＝true or false的形式。

用户的各种私人信息，比如姓名等，某种情况下，需要保存在Session里

需要在页面间传递的内容信息，比如调查工作需要分好几步。每一步的信息都保存在Session里，最后在统一更新到数据库。

当然还会有很多，这里列举一些比较典型的

假如，一个人孤僻到不想碰Session，因为他认为，如果用户万一不小心关闭了浏览器，那么之前保存的数据就全部丢失了。所以，他出于好意，决定把这些用Session的地方，都改成用Cookies来存储，这完全是可行的，且基本操作和用Session一模一样。那么，下面就针对以上的3个典型例子，做一个分析

很显然，只要某个有意非法入侵者，知道该网站验证登陆信息的Session变量是什么，那么他就可以事先编辑好该Cookies，放入到Cookies目录中，这样就可以顺利通过验证了。这是不是很可怕？

Cookies完全是可见的，即使程序员设定了Cookies的生存周期（比如只在用户会话有效期内有效），它也是不安全的。假设，用户忘了关浏览器 或者一个恶意者硬性把用户给打晕，那用户的损失将是巨大的。

这点如上点一样，很容易被它人窃取重要的私人信息。但，其还有一个问题所在是，可能这些数据信息量太大，而使得Cookies的文件大小剧增。这可不是用户希望所看到的。

显然，Cookies并不是那么一块好啃的小甜饼。但，Cookies的存在，当然有其原因。它给予程序员更多发挥编程才能的空间。所以，使用Cookies改有个底线。这个底线一般来说，遵循以下原则。

不要保存私人信息。

任何重要数据，最好通过加密形式来保存数据（最简单的可以用URLEncode，当然也可以用完善的可逆加密方式，遗憾的是，最好不要用md5来加密）。

是否保存登陆信息，需有用户自行选择。

长于10K的数据，不要用到Cookies。

也不要用Cookies来玩点让客户惊喜的小游戏。

本文参考以下文章

https://www.iteye.com/blog/wx1568300408-2452328

https://blog.csdn.net/duan1078774504/article/details/51912868?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522163213175416780255242322%2522%252C%2522scm%2522%253A%252220140713.130102334.pc%255Fblog.%2522%257D&request_id=163213175416780255242322&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~blog~first_rank_v2~rank_v29-2-51912868.pc_v2_rank_blog_default&utm_term=Session%E4%B8%8ECokkie&spm=1018.2226.3001.4450

https://blog.csdn.net/qq_28296925/article/details/80921585?ops_request_misc=%257B%2522request%255Fid%2522%253A%2522163213175416780274116786%2522%252C%2522scm%2522%253A%252220140713.130102334..%2522%257D&request_id=163213175416780274116786&biz_id=0&utm_medium=distribute.pc_search_result.none-task-blog-2~blog~baidu_landing_v2~default-1-80921585.pc_v2_rank_blog_default&utm_term=Session%E4%B8%8ECokkie&spm=1018.2226.3001.4450