session 和 cookie

session 和 cookie 的目的相同，都是为了克服 http 协议无状态的缺陷，但完成的方法不同。session 通过 cookie，在客户端保存 session id，而将用户的其他会话消息保存在服务端的 session 对象中，与此相对的，cookie 需要将所有信息都保存在客户端。因此 cookie 存在着一定的安全隐患，例如本地 cookie 中保存的用户名密码被破译，或 cookie 被其他网站收集（例如：1. appA 主动设置域 B cookie，让域 B cookie 获取；2. XSS，在 appA 上通过 javascript 获取 document.cookie，并传递给自己的 appB）。

session 创建过程

session 的基本原理是由服务器为每个会话维护一份信息数据，客户端和服务端依靠一个全局唯一的标识来访问这份数据，以达到交互的目的。当用户访问 Web 应用时，服务端程序会随需要创建 session，这个过程可以概括为三个步骤：

• 生成全局唯一标识符（sessionid）；
• 开辟数据存储空间。一般会在内存中创建相应的数据结构，但这种情况下，系统一旦掉电，所有的会话数据就会丢失，如果是电子商务类网站，这将造成严重的后果。所以为了解决这类问题，你可以将会话数据写到文件里或存储在数据库中，当然这样会增加 I/O 开销，但是它可以实现某种程度的 session 持久化，也更有利于 session 的共享；
• 将 session的全局唯一标示符发送给客户端。

以上三个步骤中，最关键的是如何发送这个 session 的唯一标识这一步上。考虑到 HTTP 协议的定义，数据无非可以放到请求行、头域或 Body 里，所以一般来说会有两种常用的方式：cookie 和 URL 重写。

• Cookie
  服务端通过设置 Set-cookie 头就可以将 session 的标识符传送到客户端，而客户端此后的每一次请求都会带上这个标识符，另外一般包含 session 信息的 cookie 会将失效时间设置为 0 (会话 cookie)，即浏览器进程有效时间。至于浏览器怎么处理这个 0，每个浏览器都有自己的方案，但差别都不会太大 (一般体现在新建浏览器窗口的时候)；
• URL 重写
  所谓 URL 重写，就是在返回给用户的页面里的所有的 URL 后面追加 session 标识符，这样用户在收到响应之后，无论点击响应页面里的哪个链接或提交表单，都会自动带上 session 标识符，从而就实现了会话的保持。虽然这种做法比较麻烦，但是，如果客户端禁用了 cookie 的话，此种方案将会是首选。