Cookie 和 Session

Cookie

起源

当初 W3C 在设计 Cookie 时实际上考虑的是为了记录用户在一段时间内访问 Web 应用的行为路径。

由于HTTP 协议是一种无状态协议，当用户的一次访问请求结束后，后端服务器就无法知道下一次来访问的还是不是上次访问的用户。
Cookie 的作用正是在此，由于是同一个客户端发出的请求，每次发出的请求都会带有上一次访问时服务端设置的信息，这样服务端就可以根据之前存入 Cookie 的值来做相应的处理(区分访问的用户等)。

作用

解决了客户端和服务端之间的无状态

通俗地讲就是当一个用户通过 HTTP 协议访问一个服务器的时候，服务器会根据需要设置一些 Cookie 信息（Key/Value 键值对），并给这些数据加上一些限制条件，再以响应头的形式返回给客户端浏览器。在条件符合时这个用户下次访问这个服务器的时候，数据又被完整地带回给服务器。

流程简介

1. 当客户端浏览器发送请求时，会根据自身的设置找寻相应条件下的 Cookie 信息并解析。若找到，则设置相应的请求头信息，再发送请求，否则直接发送请求。

2. 服务端设置好 $_COOKIE 后，将会通过响应头返回给浏览器。注意： Cookie 是在 header 中发送的，所以之前不能有任何输出。

缺点

1. 每次请求都会携带全部的 Cookie 信息，容易造成不必要的带宽浪费。

2. 每个浏览器对 Cookie 在同一个域名下的个数和每个 Cookie 的总大小(4kb)都有相应的限制。

3. 数据存储在客户端，容易被拦截篡改，不安全。

4. 客户端可以禁用 Cookie，导致功能失效。

5. 难于管理，大型系统里每个应用都会有自己的 Cookie，加上以上的限制，容易出现数据被截取，导致数据丢失。

Session

基于以上的缺点， Session 来了。

流程简介

1. 服务端（默认设置）接受请求时，先查看 $_COOKIE 中是否存在 name 为 PHPSESSID 的键值对（value 为服务端生成的 SESSION_ID：bebfaf6c745c1a6e5f341baf2178113b）。

2. 若不存在（第一次请求），将会自动生成 SESSION_ID，写入到 $_COOKIE 数组中(name 为 PHPSESSID， value 为 SESSION_ID)，然后通过响应头返回给浏览器。

3. 若存在（非第一次请求），则根据 value 值到设置的目录下获取相应的文件，反序列化并写入到 $_SESSION 数组供后续使用。

4. 当服务端进行 $_SESSION 设置时，此 $_SESSION 只会维持在内存中。当脚本执行结束时，将会自动把 $_SESSION 序列化后写入到 SESSION_ID 对应的文件中（创建或覆盖）。

优点

1. 只将会话标识符放到 Cookie 里，减少带宽的传输。

2. 可以存储大量的信息，基本没有空间上的限制。

3. 数据存放在服务端，安全。

4. 可以统一集中式管理。

联系

SESSION 为了识别会话，需要传输一个唯一的 SESSION_ID 到客户端。一般情况下，都是借助 Cookie 来传递，当然也可以通过其他方式进行传递。

Session 安全延伸

以上分析得出， Session 需要通过 SESSION_ID 来识别客户端，这就会导致一个安全隐患。当 SESSION_ID 落入第三者时，服务端将无法分辨出是否是合法的请求。

一个简单的防御措施就是：每次请求时都生成一个新的 SESSION_ID 关联到对应的数据并将老的 SESSION_ID 删除。