Cookie & Session

由于HTTP的无状态特性，即便我们与服务器连接并且成功登陆后，第二次发送请求服务器依然不知道当前的请求是属于哪个用户。为了使web应用有状态，因此引入了Cookie&Session的机制。

---

Cookie

由服务器发送给客户端的特殊信息，以文本的形式存放在客户端，客户端每次向服务器发送请求的时候都会带上这些特殊的信息。

例如：我们用浏览器访问一个支持Cookie的网站时，通过发送附带Cookie的请求，会给服务器提供包括用户名在内的信息（前提是本地存有该网站的Cookie）。

而服务器在给客户端回发响应报文的同时，也会附带用户信息，这些信息存放在HTTP响应头中，当客户端接收到来自服务器的响应时，浏览器会将这些信息存放在一个统一的位置。

客户端再向服务器发送请求的时候，会把Cookie放在请求头中一起发送。

服务器接收后，就能够分析请求头中的Cookie，以此得到客户端特有的信息，从而动态生成与该客户端相对应的内容。

一般我们在网站登陆后常见的"请记住我"的弹窗其本质就是：客户端向服务器发送附带登陆的请求，服务器收集这些请求信息，将其作为Cookie存放在HTTP响应头中回发给客户端，客户端浏览器收到响应后取出Cookie存放于本地。

该客户端下次访问该网站的时候，发送的请求中就会附带登陆信息的Cookie，服务器解析并回执响应后就不用进行登陆操作了。

Session

Session是一种服务器端机制，用于在服务器上保存用户信息。

实现方式：

1. 通过Cookie：
   
   当服务端程序需要为某个客户端的请求创建Session时，首先会检查客户端请求里是否已经包含了JSESSIONID。若包含了，则表明已经为此客户端创建了session，服务器就会按照该JSESSIONID将对应的Session检索出来使用；如果通过JSESSIONID未能检索到，那么会在服务端重新为该客户端创建一个Session，并生成一个与此Session相对应的JSESSIONID，该JSESSIONID将会通过Cookie的形式存放在响应头中，回发给客户端进行保存。

客户端接收并存储了JSESSIONID，下次发送请求的时候，就会在请求头中携带包含JSESSIONID的Cookie发送给服务端，服务端接收后对其解析并进行相应的响应。

2. 通过URL回写
   服务器在发送给浏览器的所有页面中都携带JSESSIONID的参数，客户端点击任何一个连接，都会把JSESSIONID带会给服务器。
   若通过在浏览器中输入服务端的URL来请求资源，则无法进行URL回写。

Tomcat对Session实现：一开始会同时使用Cookie和URL回写。如果发现客户端支持Cookie则会一直使用Cookie实现Session，若Cookie被禁用，则采取URL回写的方式实现Session。

二者区别

1. Cookie存放在客户端浏览器上，Session存放在服务器

2. Session相对于Cookie更安全，因为可以通过存放在本地的Cookie进行Cookie欺骗（虽然当今的Cookie都是通过了加密的，其参数中还夹带了ip等用于校验身份的信息）

3. Session会在一定时间内保存在服务器上，若用户访问量增多则会占用服务器的性能，若考虑减轻服务器的开销，应当使用Cookie。（现如今，服务器的性能对于保存Session的性能还是绰绰有余的）