谈谈对Cookie Session Token的认识

一、序言

对从事Web开发的或者有过Web开发经验的朋友来说，身份验证一定是一个避不开的话题。即使是再小的系统，也少不了登录这道程序。不管是前端还是后端，总要和会话打交道，那么，就从会话开始，聊聊常用的验证方式：Cookie、Session、Token。

在计算机术语中，会话是指一个终端用户与交互系统进行通讯的过程，TCP的三次握手就创建了一个会话，TCP关闭连接就是关闭会话。理论上，一个用户的所有请求操作都应该属于同一个会话。但是，Web应用程序是使用HTTP协议传输数据的。HTTP协议是无状态的协议。一旦数据交换完毕，客户端与服务器端的连接就会关闭，再次交换数据需要建立新的连接。这就意味着服务器无法从连接上跟踪会话。所以要跟踪用户会话，就需要引入会话跟踪机制。

二、Cookie

Cookie是一段用户文本信息，它存放在用户请求头信息中：

客户端第一次访问服务器的时候，服务器如果验证通过，就可以使用response向客户端返回一个Cookie，客户端将Cookie保存，下次向服务器进行请求时，请求头中就会携带服务器颁发的Cookie信息。可以理解为：由于http的无状态特性，服务器端需要借助一种认证方式来识别客户端身份，通过Cookie相当于给客户端颁发一个通行证，当客户端携带通行证进行访问时，服务器就可以通过通行证中的信息来识别客户端身份。

Cookie存放在客户端，具有不可跨域名性。前端与后端都可以进行Cookie的设置与修改，当设置Cookie时未设置对应的过期时间或过期时间设置为非正数，则该Cookie会被认为是临时性Cookie，不会被写入Cookie文件中，在用户关闭浏览器后，Cookie即自动消失；相反，如果显式设置Cookie过期时间，则Cookie会被写入Cookie文件，如果用户关闭了浏览器，但只要Cookie仍在过期时间之内，则Cookie依然生效。如果设置过期时间如下，则该Cookie永远生效：

cookie.setMaxAge(Integer.MAX_VALUE);           // 设置生命周期为MAX_VALUE

Cookie不存在显式的修改及删除操作，如果要修改某个Cookie，只需要新建一个同名的Cookie，添加到response中覆盖原来的Cookie。如果要删除某个Cookie，只需要新建一个同名的Cookie，并将maxAge设置为0，并添加到response中覆盖原来的Cookie。注意是0而不是负数。（修改、删除Cookie时，新建的Cookie除value、maxAge之外的所有属性，例如name、path、domain等，都要与原Cookie完全一样。否则，浏览器将视为两个不同的Cookie不予覆盖，导致修改、删除失败。）

 由于其可以被客户端获取及修改，因此，为保障网络安全，一般建议对Cookie进行加密。

三、Session

Session是服务器端使用的一种记录客户端状态的机制，使用上比Cookie简单一些，相应的也增加了服务器的存储压力。

Session是另一种记录客户状态的机制，不同的是Cookie保存在客户端浏览器中，而Session保存在服务器上。客户端浏览器访问服务器的时候，服务器把客户端信息以某种形式记录在服务器上。客户端浏览器再次访问时只需要从该Session中查找该客户的状态就可以了。

如果说Cookie机制是通过检查客户身上的“通行证”来确定客户身份的话，那么Session机制就是通过检查服务器上的“客户明细表”来确认客户身份。Session相当于程序在服务器上建立的一份客户档案，客户来访的时候只需要查询客户档案表就可以了。

Session对象是在客户端第一次请求服务器的时候创建的。Session也是一种key-value的属性对 ，为了获得更高的存取速度，服务器一般把Session放在内存里。每个用户都会有一个独立的Session。如果Session内容过于复杂，当大量客户访问服务器时可能会导致内存溢出。因此，Session里的信息应该尽量精简。

Session生成后，只要用户继续访问，服务器就会更新Session的最后访问时间，并维护该Session。为防止内存溢出，服务器会把长时间内没有活跃的Session从内存删除。这个时间就是Session的超时时间。如果超过了超时时间没访问过服务器，Session就自动失效了。

虽然Session保存在服务器端，但Session的正常运行仍然需要客户端浏览器的支持。这是因为Session需要使用Cookie作为识别标志。HTTP协议是无状态的，Session不能依据HTTP连接来判断是否为同一客户，因此服务器向客户端浏览器发送一个名为JSESSIONID的Cookie，它的值为该Session的id（也就是HttpSession.getId()的返回值）。Session依据该Cookie来识别是否为同一用户。

四、Token

当讨论基于token的身份验证时，一般都是说的JSON Web Tokens（JWT）。虽然有着很多不同的方式实现token，但是JWT已经成为了事实上的标准，所以后面会将JWT和token混用。

基于token的验证是无状态的。服务器不记录哪些用户已登陆或者已经发布了哪些JWT。对服务器的每个请求都需要带上验证请求的token。该标记既可以加在header中，可以在POST请求的主体中发送，也可以作为查询参数发送。

Token的验证流程如下：

• 用户输入登陆凭据；
• 服务器验证凭据是否正确，然后返回一个经过签名的token；
• 客户端负责存储token，可以存在local storage，或者cookie中；
• 对服务器的请求带上这个token；
• 服务器对JWT进行解码，如果token有效，则处理该请求；
• 一旦用户登出，客户端销毁token。

 从以上请求验证流程对比不难看出，Token不存在跨域问题，相比于Cookie的有状态性，基于token的验证是无状态的，这也许是它相对cookie来说最大的优点。后端服务不需要记录token。每个令牌都是独立的，包括检查其有效性所需的所有数据，并通过声明传达用户信息。

JWT具有两个特点：

1. 紧凑。由于其较小的尺寸，JWT可以通过URL，POST参数或者HTTP头发送。较小的尺寸会带来传输速度的优势；
2. 自包含：token中包含了用户的所有必须信息，避免了多次查询数据库的需要。

当然，JWT同样存在自己的缺点：其 最大的缺点就是它的大小，最小的它都比 cookie 要大，如果 token 中包含很多声明，那问题就会变得比较严重，毕竟向服务器发送的每个请求都要有这个 token。（意思应该是太大了会导致请求缓慢）

五、小结

 对于简单的小型应用而言，使用Session配合Cookie进行简单的用户身份验证就足够了。但在大型应用中，Session的大量存储会使得服务器不堪重负。事实上，现在的互联网公司普遍使用Token进行身份验证。当然，以上技术均有其优缺点，基于不同场景、不同需求，选择合适的方式即可。