1.sessionid 的生成
浏览器第一次跟服务器请求的时候，服务器会创建一个session（会话），并生成一个唯一的key（sessionid），把用户的一些信息，状态存在session里，并把sessionid和session当作key，value存起来（可以存在缓存里），然后服务器把sessionid以cookie的形式发送给浏览器，浏览器下次访问服务器时直接携带上cookie中的sessionid，服务器再根据sessionid找到对应的session进行匹配，对应的session就有对应用户的信息。 注意，服务器把sessionid发送给浏览器，浏览器存在客户端这个过程是自动的，并不是程序员人为干预的，服务器发送是如tomcat,apache帮我们完成的 这个举一个例子： 有一个jsp，setCookie.jsp 新建了一个cookie，并通过response添加到返回 另一个jsp，getCookie.jsp 获取浏览器请求的cookie，我们查看浏览器的开发者工具，查看request的cookie 先运行第一个jsp，再运行第二个jsp 看到请求带上的cookie还有一个JSESSIONID, 我们并没有手动去设置，这是tomcat帮我们完成的，也就是我上面所说的服务器自动帮我们sessionid的传递 2.token的生成 token的生成方式我这里讲一种，随机字符串+当前时间戳+盐，再加密。然后服务器把token返回给客户端，客户端把它存起来，下次请求的时候带上，服务器再进行身份认证。token的生成，返回，浏览器的存储都是需要程序员去完成的，不是自动的。token同样是一种唯一标识 3.区别，联系 既然sessionid已经能够唯一标识用户了，那我们要token做什么。 sessionid和session（会话）有关，它关注的是会话状态。每一次浏览器与服务器的请求都是一次会话，当把浏览器关掉，会话就结束了，那我们用cookie+sessionid的方式来记录会话状态，举个例子，平时网站的登录状态就是用cookie+sessionid来实现的，一段时间内不用重新登录，当cookie，session过期了或者我们清除了浏览器的cookie，那么我们就需要重新登录了。
那为什么要用token 我觉得有几个原因 来看几个问题 1 安全 Cross-Site Request Forgery (CSRF) This attack method works by including malicious code or a link in a page that accesses a web application that the user is believed to have authenticated. If the session for that web application has not timed out, an attacker may execute unauthorized commands. In the session chapter you have learned that most Rails applications use cookie-based sessions. Either they store the session ID in the cookie and have a server-side session hash, or the entire session hash is on the client-side. In either case the browser will automatically send along the cookie on every request to a domain, if it can find a cookie for that domain. The controversial point is that if the request comes from a site of a different domain, it will also send the cookie. Let’s start with an example: Bob browses a message board and views a post from a hacker where there is a crafted HTML image element. The element references a command in Bob’s project management application, rather than an image file: <img src="http://www.webapp.com/project…;>
Bob’s session at www.webapp.com is still alive, because he didn’t log out a few minutes ago. By viewing the post, the browser finds an image tag. It tries to load the suspected image from www.webapp.com. As explained before, it will also send along the cookie with the valid session ID. The web application at www.webapp.com verifies the user information in the corresponding session hash and destroys the project with the ID 1. It then returns a result page which is an unexpected result for the browser, so it will not display the image. Bob doesn’t notice the attack - but a few days later he finds out that project number one is gone.
It is important to notice that the actual crafted image or link doesn’t necessarily have to be situated in the web application’s domain, it can be anywhere - in a forum, blog post or email. CSRF appears very rarely in CVE (Common Vulnerabilities and Exposures) - less than 0.1% in 2006 - but it really is a ‘sleeping giant’ [Grossman]. This is in stark contrast to the results in many security contract works - CSRF is an important security issue.
2 如果浏览器禁用了cookie，那么这一整套东西也就没有用了 3 移动端的开发，比如小程序，app，因为移动端上没有cookie这套系统，不必非要给移动端搞一套这样的cookie的系统。 移动端上也叫access_token，令牌（通篇我就采用简称token了） 那么token的好处在于它只是一串字符串，并不是一整套系统，维持session要使用大量内存，即便token也可能会作为key，将对应用户的个别信息，不需要存储大量用户信息，作为value存在缓存，但维持一个会话的内存开销应该要更大，这点有待考证。 token是无状态的stateless，每次把token传过来服务器就验证是否有效 token不需要存储状态、用户信息（按实际需求，一般来说value存用户在用户表的id或加上一些用户的权限的标识），不像cookie那样，传过来还要验证里面的信息 它的传递方式不是通过cookie来传递的，是通过加在header里传递的
最后 session 和 oauth token并不矛盾，作为身份认证 token安全性比session好，因为每个请求都有签名还能防止监听以及重放攻击，而session就必须靠链路层来保障通讯安全了。如上所说，如果你需要实现有状态的会话，仍然可以增加session来在服务器端保存一些状态
以上是一点对cookie，sessionid，token的理解
