token相对安全加密算法
http://blog.csdn.net/q8649912/article/details/52370565
关于文章的理解
1 sessionid
这个名词应该理解为：一个http客户端在服务端的一个标识，仅此而已，他唯一性的标识了一个客户端，但是其作用却很关键，他的关键作用在于token的生成。
2 真实的http登陆请求详细过程（非前后端分离，如jsp，asp.net）
1）浏览器无论如何都会向服务器发送一次请求，服务器获取sessionid和token，判断有无登录。如果没有，那么生成密钥对，缓存sessionid，将公钥和sessionid发送到http响应中，也就是交给客户端，重定向到登陆页
2）浏览器提交登陆表单，携带sessionid，和使用公钥加密的密码，服务区接收到这些信息，这时候sessionid唯一性的标识客户端很关键，通过sessionid拿到缓存在服务器的私钥，进行密码解密，解密后完成用户名，密码验证。接下来降低sessionid的关键作用一步，在验证通过后生成token，使用token为关键点缓存登陆会话相关信息，如权限等。服务器将sessionid，使用客户端公钥加密token交给客户端
3）客户端用私钥解密token，由于rsa加密算法每次加密结果都不一样，所以这里在浏览器与服务器传输中的加密token一直处于变化中。客户端完成相关操作后向发服务器再次发生请求，私钥加密token，将sessionid和token一些其他起脚信息交给服务器，这个时候就算是黑客拿到token，sessionid也没有用
4）服务器接收将token解密，然后获取token映射的信息进行处理，即便是黑客能够拿到这一次的加密token，请求成功，服务器加密后返回给客户端，客户端需要正确解密和加密后才会进入下一次交互过程，如果服务端发现黑客还是拿着上一次的token来请求自然就会解密失败，自然的请求也就失败了
5）作为黑客来说吃亏就在于rsa每一次加密结果不一致造成的，那么黑客可以分析客户端的加解密程序，并拿到私钥才能进行伪装成功，但这也是比较费技术的，那么另外一种就是每一次都可以截取正常加密后的token就可以很好的伪装了
6）为了解决这个问题呢，引入证书了，由于证书的存在，即便是你每次能截取到加密token但是没有证书相关信息也是不行的
7）大魔法ssl可以非常有效解决这种问题，但是ssl非常复杂，我也不咋个了解，所以暂时就这样吧
3 sessionid的生命周期sessionid在密码验证，token生成过程中非常关键，也就是验证过程，但是之后就失去了这个关键作用了。这个作用失去就是在会话维持阶段基本没什么用了。