这三者都和维持状态信息有关。比如我们如果在网页进行了一次登录，如果我们希望以后再访问该网页的时候，维持登录信息的话，就需要用到上面的这三种，如果不用的话，那么我们每次都需要携带登录信息到服务器，并且服务器需要将登录信息携带返回，后续请求的任何页面都需要这样，这样是很麻烦的。

        采用cookie的话，登录以后，服务器会返回给客户端一个cookie，cookie是保存在客户端的本地的，后续所有请求都会携带这个cookie进行访问，这样就维持了登录状态。

        但是，如果只用cookie来存储用户信息等内容的话，他会有很多的问题，

        cookie特点：

                优点：1.存储在客户端。2.帮助在客户端和服务器之间维护状态信息。

                缺点：1.安全风险:有被串改风险。2.容量限制4KB。3.可用限制:用户可能禁用。4.只能存储字符串对象。

        采用session的话，客户端发起登录请求，请求信息中会包括用户登录所需要的信息，服务器端拿到以后，会将其登录信息存入到服务器中，响应的时候会存入一个叫set-cookie的属性，再把当前session的唯一id放到属性当中，前端会自动在cookie当中存入当前的session的id，在下次请求的时候，就会携带这次的cookie，到服务器端，服务器端通过响应的sessionid找到存入的信息，进而完成登录的验证。session能够存入对象信息，不仅限于字符串类型。

        session特点：

                优点：1.安全性高:存储在服务器端。2.容量大:可以保存对象。

                缺点：1.占用服务器资源。2.扩展性差(分布式集群)。3.依然需要依赖cookie跨域限制。

        当服务器集群部署的时候，某一次session的信息只会存入一个服务器端，其他服务器不会存储相同的信息，当发生负载均衡的时候，选择了另外一个服务器，那么，就无法通过sessionid来获取响应的信息了。

        token就是一个秘钥字符串，jwt（json web token）提供了一种加密规范，也就是一种通过json来进行传递的加密后的字符串。

        jwt加密方法，加密后的加密字符串分为3部分：

        第一部分，就是header，下图中红色的字符串，来指定当前使用的算法和token类型：

        第二部分就是payload，下图中紫色的字符串，也就是来存放数据的地方：

        第三部分，是signature，是安全所在了，我们叫他秘钥。

        他会将base64编码之后的header和base64编码之后的payload相加，再加上只有自己知道的私钥，最后通过header中指定的算法来进行加密，最后就得到了下图蓝色的字符串了：

        引入token后，前后端以及集群的处理流程：

        token是一直在传输的一种字符串，并不依赖客户端或者服务器端的存储，只是一个传输过程中的一个字符串。能够解决跨域问题，更适合与前后端分离的项目和集群分布的项目。