Session会话与Cookie简单说明

 

Facebook、 Gmail、 Twitter 是我们每天都会用的网站（LCTT 译注：才不是呢）。它们的共同点在于都需要你登录进去后才能做进一步的操作。只有你通过认证并登录后才能在 twitter 发推，在 Facebook 上评论，以及在 Gmail上处理电子邮件。经常有人会疑惑：Session会话与Cookies的区别是什么？用户登录的原理是什么？网站是如何认证的？它怎么知道是哪个用户从哪儿登录进来的？下面将对这些问题进行一一解答。

1）session与cookie的简单区别
session和cookie本质上确实是两个东西，但cookie同时也是session id的载体，cookie保存session id。

cookie数据存放在用户的浏览器上，session数据放在网站的服务器上。
session保存在服务器端与浏览器设置无关，cookie在客户端并受浏览器设置限制。
cookie是在你的电脑浏览器上保存的,session是在网站服务器上的. 也就是说你换一个电脑你的cookie就不起作用了, 而session只要你的浏览器不关就还能访问到.
通常的都是两者结合着用的. cookie的话你自己就可以通过对浏览器的设置禁用掉.这样就不起作用了

cookie不是很安全，别人可以分析存放在本地的cookie并进行cookie欺骗，考虑到安全应当使用session。
session是服务器端缓存，cookie是客户端缓存。
cookie机制采用的是在客户端保持状态的方案，而session机制采用的是在服务器端保持状态的方案

session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能，考虑到减轻服务器性能方面，应当使用cookie。
session是服务器保持客户端状态信息的方案，一般是保存在服务器中的一块内存中，session超时时间在服务器端进行设置。
cookie是客户端保持用户信息的方案，一般是文件形式保存，cookie清空时间是在客户端浏览器设置。
从开发角度说，session信息可以通过技术方案写到客户端保存，cookie中的用户信息，也可以在用户访问该网站时，通过技术手段自动更新用户的session信息。

单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。

建议：将登陆信息等重要信息存放为session；其他信息如果需要保留，可以放在cookie中

2）用户登录的原理是什么?
每次用户在网站的登录页面中输入用户名和密码时，这些信息都会发送到服务器。服务器随后会将你的密码与服务器中的密码进行验证。
如果两者不匹配，则你会得到一个错误密码的提示。如果两者匹配，则成功登录。

3）用户登录时发生了什么?
登录后，web 服务器会初始化一个会话session并在你的浏览器中设置一个 cookie 变量。该 cookie 变量用于作为新建会话的一个引用。
搞晕了？让我们说的再简单一点。

4）会话的原理是什么?
服务器在用户名和密码都正确的情况下会初始化一个会话。会话的定义很复杂，可以把它理解为“关系的开始”。

认证通过后，服务器就开始跟用户展开一段关系了。由于服务器不能象我们人类一样看东西，它会在我们的浏览器中设置一个 cookie 来将我们的关系从其他人与服务器的关系标识出来。

什么是 Cookie?
cookie 是网站在用户的浏览器中存储的一小段数据。当用户登录后，服务器为用户创建一段关系或者说一个会话，然后将唯一标识这个会话的会话 id 以 cookie 的形式存储在用户的浏览器中。所有这些东西存在的原因在于识别出用户来，这样当用户写评论或者发推时，服务器能知道是谁在发评论，是谁在发推。当用户登录后，会产生一个包含会话 id 的 cookie。这样，这个会话 id 就被赋予了那个输入正确用户名和密码的人了。也就是说，会话 id 被赋予给了拥有这个账户的人了。之后，所有在网站上产生的行为，服务器都能通过他们的会话 id 来判断是由谁发起的。

如何让用户保持登录状态?
会话有一定的时间限制。这一点与现实生活中不一样，现实生活中的关系可以在不见面的情况下持续很长一段时间，而会话具有时间限制。用户必须要不断地通过一些动作来告诉服务器用户还在线。否则的话，服务器会关掉这个会话，而用户会被登出。不过在某些网站上可以启用"保持登录"功能，这样服务器会将另一个唯一变量以 cookie 的形式保存到我们的浏览器中。这个唯一变量会通过与服务器上的变量进行对比来实现自动登录。若有人盗取了这个唯一标识（我们称之为 cookie stealing），他们就能访问用户的账户了。

========================扩展======================
1) 由于Http协议是无状态的，服务端如何识别客户端请求呢，只能依靠http报文中新增部分头字段来实现请求识别（如何在请求body或这参数中设置会员参数，服务器端会话就与自定义的会员识别绑定到一起）
2) 基于浏览器的web应用，请求都是有浏览器发起的，貌似也不能手动随便添加请求头（仅有XMLHttpRequest可以手动设置请求头），哪有没有一种可以由服务端生成，客户端请求是自动在请求中设置对应头字段的技术呢，这就是cookie

Cookie：
cookie是在客户端负责保存的，既可以客户端生成，也可以服务器端生成，Cookie总是保存在客户端中，按在客户端中的存储位置，可分为内存Cookie和硬盘Cookie：
1）内存Cookie由浏览器维护，保存在内存中，浏览器关闭后就消失了，其存在时间是短暂的
2）硬盘Cookie保存在硬盘里，有一个过期时间，除非用户手工清理或到了过期时间，硬盘Cookie不会被删除
3）cookie一些重要的属性，path，domain，maxAge，secure，httponly，可以自己去研究一下
4）服务端生成cookie的响应头为 Set-Cookie：JSESSIONID=164A9B3B768FD959AA20505D4C09; Path=/; HttpOnly
5）客户端发送http请求带的cookie请求头 Cookie：AMCV_niwodai%40AdobeOrg=-15069…7-badf-4795-9c64-eb9960c23d48

Session的实现原理：
1）服务端首先查找对应的cookie的值（sessionid）
2）根据sessionid，从服务器端session存储中获取对应id的session数据，进行返回
3）如果找不到sessionid，服务器端就创建session，生成sessionid对应的cookie，写入到响应头中

session共享实现(如tomcat session会话共享)
传统的session由服务器端生成并存储，当应用进行分布式集群部署的时候，如何保证不同服务器上session信息能够共享呢？
两种实现方式：1.session集中存储（redis，memcached，hbase等），2. 不同服务器上session数据进行复制，两种方式的优缺点，大家应该一目了然

基于session集中存储的实现方案：
1）新增Filter，拦截请求，包装HttpServletRequest
2）改写getSession方法，从session存储中获取session数据，返回自定义的HttpSession实现
3）在生成新Session后，写入sessionid到cookie中

Redis存储session的需要考虑问题：
1) session数据如何在Redis中存储？
2) session属性变更何时触发存储？

实现思路：
考虑到session中数据类似map的结构，采用redis中hash存储session数据比较合适，如果使用单个value存储session数据，不加锁的情况下，就会存在session覆盖的问题，因此使用hash存储session，每次只保存本次变更session属性的数据，避免了锁处理，性能更好.
如果每改一个session的属性就触发存储，在变更较多session属性时会触发多次redis写操作，对性能也会有影响，我们是在每次请求处理完后，做一次session的写入，并且之写入变更过的属性
如果本次没有做session的更改， 是不会做redis写入的，仅当没有变更的session超过一个时间阀值（不变更session刷新过期时间的阀值），就会触发session保存，以便session能够延长有效期