IM开发——HTTP短连接中的Cookie、Session和Token

众所周之，当今主流IM系统（尤其移动端IM）的数据流交换方式都是Http短连接+TCP或UDP长连接来实现。Http短连接主要用于从服务器读取各种持久化信息：比如用户信息、聊天历史记录、好友列表等等，长连接则是用于实时的聊天消息或指令的接收和发送。

Cookie

Cookie 技术产生源于 HTTP 协议在互联网上的急速发展。随着互联网时代的策马奔腾，带宽等限制不存在了，人们需要更复杂的互联网交互活动，就必须同服务器保持活动状态。于是在浏览器发展初期，为了适应用户的需求技术上推出了各种保持 Web 浏览状态的手段，其中就包括了 Cookie 技术。Cookie 在计算机中是个存储在浏览器目录中的文本文件，当浏览器运行时，存储在 RAM 中发挥作用 （此种 Cookies 称作 Session Cookies），一旦用户从该网站或服务器退出，Cookie 可存储在用户本地的硬盘上 （此种 Cookies 称作 Persistent Cookies）

**Cookie时效性：**目前有些 Cookie 是临时的，有些则是持续的。临时的 Cookie 只在浏览器上保存一段规定的时间，一旦超过规定的时间，该 Cookie 就会被系统清除。

**Cookie使用限制：**Cookie 必须在 HTML 文件的内容输出之前设置；不同的浏览器 (Netscape Navigator、Internet Explorer) 对 Cookie 的处理不一致，使用时一定要考虑；客户端用户如果设置禁止 Cookie，则 Cookie 不能建立。 并且在客户端，一个浏览器能创建的 Cookie 数量最多为 300 个，并且每个不能超过 4KB，每个 Web 站点能设置的 Cookie 总数不能超过 20 个。

执行流程：

Session

Cookie 虽然很方便，但是使用 Cookie 有一个很大的弊端，Cookie 中的所有数据在客户端就可以被修改，数据非常容易被伪造，那么一些重要的数据就不能存放在 Cookie 中了，而且如果 Cookie 中数据字段太多会影响传输效率。为了解决这些问题，就产生了 Session，Session 中的数据是保留在服务器端的。

Session是对于服务端来说的，客户端是没有Session一说的。Session是服务器在和客户端建立连接时添加客户端连接标志，最终会在服务器软件（Apache、Tomcat、JBoss）转化为一个临时Cookie发送给给客户端，当客户端第一请求时服务器会检查是否携带了这个Session（临时Cookie），如果没有则会添加Session，如果有就拿出这个Session来做相关操作。

Session 的运作通过一个session_id来进行。session_id通常是存放在客户端的 Cookie 中，比如在 express 中（说的是Nodejs），默认是connect.sid这个字段，当请求到来时，服务端检查 Cookie 中保存的 session_id 并通过这个 session_id 与服务器端的 Session data 关联起来，进行数据的保存和修改。

这意思就是说，当你浏览一个网页时，服务端随机产生一个 1024 比特长的字符串，然后存在你 Cookie 中的connect.sid字段中。当你下次访问时，Cookie 会带有这个字符串，然后浏览器就知道你是上次访问过的某某某，然后从服务器的存储中取出上次记录在你身上的数据。由于字符串是随机产生的，而且位数足够多，所以也不担心有人能够伪造。伪造成功的概率比坐在家里编程时被邻居家的狗突然闯入并咬死的几率还低。

Session 可以存放在：

线上来说，缓存的方案比较常见，存数据库的话，查询效率相比前三者都太低，不推荐；Cookie Session 有安全性问题，下面会提到。

传统的身份验证方法从最早的Cookie到Session以及给Session Cookie做个加密，接下来我们来看看Token认证。

Token

Token的起源

诸如Ember，Angular，Backbone之类的Web前端框架类库正随着更加精细的Web应用而日益壮大。服务器端的组建也正在从传统的任务中解脱，转而变的更像API。API使得传统的前端和后端的概念解耦。开发者可以脱离前端，独立的开发后端，在测试上获得更大的便利。这种途径也使得一个移动应用和网页应用可以使用相同的后端。

当使用一个API时，其中一个挑战就是认证（authentication）。在传统的web应用中，服务端成功的返回一个响应（response）依赖于两件事。

这就是传统的web应用逃避HTTP面向无连接的方法。

API应该被设计成无状态的（Stateless）。这意味着没有登陆，注销的方法，也没有sessions，API的设计者同样也不能依赖Cookie，因为不能保证这些request是由浏览器所发出的。自然，我们需要一个新的机制。Token这种东西就应运而生了。

Token是什么

token（令牌）是用户身份的验证方式。最简单的token组成:uid(用户唯一的身份标识)、time(当前时间的时间戳)、sign(签名，由token的前几位+盐以哈希算法压缩成一定长的十六进制字符串，可以防止恶意第三方拼接token请求服务器)。还可以把不变的参数也放进token，避免多次查库。

Token的应用场景

Token的使用流程：

Token的身份认证逻辑：

Token的安全性

我们可以保存认证过的Token记录在服务器上，来添加一个附加的安全层，然后在每一步验证Token的时候验证这个记录（比如每次客户端请求API时检查这个Token的合法性）。这将会阻止第三方伪装一个Token，也将会使得服务器可以失效一个Token。

Cookie和Session的区别

Token 和 Session 的区别

Session和 token并不矛盾，作为身份认证token安全性比Session好，因为每个请求都有签名还能防止监听以及重放攻击，而Session就必须靠链路层来保障通讯安全了。如上所说，如果你需要实现有状态的会话，仍然可以增加session来在服务器端保存一些状态。

App通常用restful api跟server打交道。Rest是stateless的，也就是app不需要像browser那样用cookie来保存Session,因此用Session token来标示自己就够了，session/state由api server的逻辑处理。如果你的后端不是stateless的rest api,那么你可能需要在app里保存Session.可以在app里嵌入webkit,用一个隐藏的browser来管理cookie Session.

Session是一种HTTP存储机制，目的是为无状态的HTTP提供的持久机制。所谓Session认证只是简单的把User信息存储到Session里，因为SID的不可预测性，暂且认为是安全的。这是一种认证手段。而Token，如果指的是OAuth Token或类似的机制的话，提供的是 认证 和 授权 ，认证是针对用户，授权是针对App。其目的是让 某App有权利访问 某用户 的信息。这里的Token是唯一的。不可以转移到其它App上，也不可以转到其它 用户 上。转过来说Session。Session只提供一种简单的认证，即有此SID，即认为有此User的全部权利。是需要严格保密的，这个数据应该只保存在站方，不应该共享给其它网站或者第三方App。所以简单来说，如果你的用户数据可能需要和第三方共享，或者允许第三方调用API接口，用Token。如果永远只是自己的网站，自己的App，用什么就无所谓了。

Token就是令牌，比如你授权（登录）一个程序时，他就是个依据，判断你是否已经授权该软件；cookie就是写在客户端的一个txt文件，里面包括你登录信息之类的，这样你下次在登录某个网站，就会自动调用cookie自动登录用户名；session和cookie差不多，只是Session是写在服务器端的文件，也需要在客户端写入cookie文件，但是文件里是你的浏览器编号。Session的状态是存储在服务器端，客户端只有Session id；而Token的状态是存储在客户端。