Cookie与Session机制以及关于他们的一些常见问题

会话（Session）跟踪是Web程序中常用的技术，用来跟踪用户的整个会话。常用的会话跟踪技术是Cookie与Session。Cookie通过在客户端记录信息确定用户身份，Session通过在服务器端记录信息确定用户身份。

本文我们来说一下Cookie与Session机制，以及关于他们的一些常见问题。

一、Cookie和Session

Cookie

Cookie 是一个非常具体的东西，指的就是浏览器里面能永久存储的一种数据，仅仅是浏览器实现的一种数据存储功能。

cookie 由服务器生成，发送给浏览器，浏览器把 Cookie 以 kv 形式保存到某个目录下的文本文件内，下一次请求同一网站时会把该 cookie 发送给服务器。由于 Cookie 是存在客户端上的，所以浏览器加入了一些限制确保 Cookie 不会被恶意使用，同时不会占据太多磁盘空间，所以每个域的 Cookie 数量是有限的。

Cookie 相当于服务器给浏览器的一个临时的编号，这个编号与身份绑定，服务器通过编号再去确定你的身份。

 

Session

Session 从字面上讲，就是会话。这个就类似于你和一个人交谈，你怎么知道当前和你交谈的是张三而不是李四呢？对方肯定有某种特征（长相等）表明他就是张三。Session 也是类似的道理，服务器要知道当前发请求给自己的是谁。为了做这种区分，服务器就要给每个客户端分配不同的“身份标识”，然后客户端每次向服务器发请求的时候，都带上这个“身份标识”，服务器就知道这个请求来自于谁了。至于客户端怎么保存这个“身份标识”，可以有很多种方式，对于浏览器客户端，大家都默认采用 Cookie 的方式。服务器使用 Session 把用户的信息临时保存在了服务器上，用户离开网站后 Session 会被销毁。这种用户信息存储方式相对 Cookie 来说更安全，可是 Session 有一个缺陷：如果 web 服务器做了负载均衡，那么下一个操作请求到了另一台服务器的时候 Session 会丢失。

1.1 Cookie和Session的区别

1. 作用范围不同， Cookie保存在客户端(浏览器)，Session保存在服务端。
2. 存取方式的不同，Cookie只能保存ASCII，Session可以存任意数据类型，一般情况下我们可以在Session中保存一些常用变量信息，比如UserId等。
3. 隐私策略不同，Cookie存储在客户端，比较容易遭到不法获取，早期有人将用户的登录名和密码存储在Cookie中导致信息被窃取。Session存储在服务端，安全性相对于Cookie要好很多。
4. 存储大小不同，单个Cookie保存的数据不能超过4K，Session可存储数据远高于Cookie。

1.2 为什么需要Cookie和Session，他们有什么关联？

为什么需要 Cookie和Session ，这就需要从浏览器开始说起，我们都知道浏览器是没有状态的(HTTP 协议无状态)，这意味着浏览器并不知道是张三还是李四在和服务端打交道。这个时候就需要有一个机制来告诉服务端，本次操作用户是否登录，是哪个用户在执行的操作，那这套机制的实现就需要 Cookie 和 Session 的配合。

 

当用户第一次请求服务器的时候，

• 服务器根据用户提交的相关信息，创建对应的 Session ，请求返回时将此 Session 的唯一标识信息 SessionID 返回给浏览器。
• 浏览器接收到服务器返回的 SessionID 信息后，会将此信息存入到 Cookie 中，同时 Cookie 记录此 SessionID 属于哪个域名。
• 当用户第二次访问服务器的时候，请求会自动判断此域名下是否存在 Cookie 信息，如果存在自动将 Cookie 信息也发送给服务端，服务端会从 Cookie 中获取 SessionID，再根据 SessionID 查找对应的 Session 信息，
• 如果没有找到说明用户没有登录或者登录失效，如果找到 Session 证明用户已经登录可执行后面操作。

根据以上流程可知，SessionID 是连接 Cookie 和 Session 的一道桥梁，大部分系统也是根据此原理来验证用户登录状态。

1.3 如果浏览器禁用了Cookie，如何判断客户端是否登录

这种情况下一般有两种解决方案：

第一种方案，每次请求中都携带一个SessionID的参数，也可以Post的方式提交，也可以在请求的地址后面拼接参数。

第二种方案，使用Token的机制。Token机制多用于App客户端和服务器交互的模式，也可以用于Web端做用户状态管理。

Token的意思是“令牌”，是服务端生成的一串字符串，作为客户端进行请求的一个标识。Token机制和Cookie和Session的使用机制比较相似。就是在用户第一次登录后，服务端会根据用户的信息生成一个Token，响应时将Token返回给客户端，以后客户端只需带上这个Token前来请求数据即可，无需再次登录验证，一般这个Token会放在请求头中。

1.4 如何考虑分布式Session问题

一般大型互联网公司为了支撑更多的流量，后台往往都是多个服务器共同来支撑用户的请求，那如果用户在A服务器登录了，第二次请求跑到了B服务器，就会出现登录失效的问题。

分布式Session一般会有以下几种解决方案：

1. Nginx ip_hash 策略，服务端使用Nginx代理，每个请求按照访问IP的hash分配，这样来自同一固定IP访问一个后台服务器，避免了在服务器A登录创建Session，第二次分发到服务B，这样就不会有分布式Session的问题了。
2. Session复制，任何一个服务器上的Session发生改变，该节点会把这个Session的所有内容序列化，然后广播给所有其他节点。
3. 共享Session，服务端无状态会话，将用户的Session等信息使用缓存中间件来统一管理，保障分发到每一个服务器的响应结果都一致。

目前比较流行的是第三种解决方案。

二、总结

Session是在服务端保存的一个数据结构，用来跟踪用户的状态，这个数据可以保存在服务端的数据库、文件中。

Cookie是客户端保存用户信息的一种机制，用来记录用户的一些信息，也是实现Session的一种方式。