Cookie的由来:
HTTP 本身是一个无状态的 request/response 协议. 服务器接收一个来自客户端的request, 处理完以后返回一个response。 但是这个过程中, 服务器几乎没有什么信息可以用来判定是哪个客户端(用户)发来的request, 也无法记录用户的请求顺序.
Cookie是目前识别用户，实现持久会话最好的方式。Cookie通常会跟User-Agent，Referer，X-Forwarded-For，JS等技术共同使用，为服务器提供更为详细的信息。简而言之，cookie就是服务器为了记录用户信息而给客户端生成的特定信息，并且保存在客户端，下次发送request时携带的一个信息。
Cookie的创建
首次访问的时候服务器会在返回的信息头中放入set-cookie
taobao中，客户端可能有不同的屏幕尺寸,我们会尽可能的去适应客户端屏幕，不同的分辨率、长宽比，给不同比例尺寸的图片。这时，我们就需要客户端主动的告诉我们它的信息。在chrome里面我们能看到这样一个cookie的值。
_med参数就是表面屏幕尺寸的
html页面里面的一段javascript。当用户首次访问taobao主站时，它并不会携带这个信息，此时服务器可以通过发现_med来判断客户端是否携带了这个cookie，如果发现没有携带，那么就会在响应的html页面中加入一段javascript
Session
保存在服务器端的客户端标志。
生成过程：
1. 生成全局唯一标识符（sessionid）
2. 开辟数据存储空间。 一般会在内存中创建相应的数据结构，但这种情况下，系统一旦掉电，所有的会话数据就会丢失，如果是电子商务网站，这种事故会造成严重的后果。不过也可以写到文件里甚至存储在数据库中，这样虽然会增加I/O开销，但session可以实现某种程度的持久化，而且更有利于session的共享；
3. 将session的全局唯一标示符发送给客户端。 问题的关键就在服务端如何发送这个session的唯一标识上。联系到HTTP协议，数据无非可以放到请求行、头域或Body里，基于此，一般来说会有两种常用的方式：cookie和URL重写。
4. 服务端只要设置Set-cookie头就可以将session的标识符传送到客户端，而客户端此后的每一次请求都会带上这个标识符，由于cookie可以设置失效时间，所以一般包含session信息的cookie会设置失效时间为0，即浏览器进程有效时间。至于浏览器怎么处理这个0，每个浏览器都有自己的方案，但差别都不会太大（一般体现在新建浏览器窗口的时候）；
5. URL重写 所谓URL重写，顾名思义就是重写URL。试想，在返回用户请求的页面之前，将页面内所有的URL后面全部以get参数的方式加上session标识符（或者加在path info部分等等），这样用户在收到响应之后，无论点击哪个链接或提交表单，都会在再带上session的标识符，从而就实现了会话的保持。读者可能会觉得这种做法比较麻烦，确实是这样，但是，如果客户端禁用了cookie的话，URL重写将会是首选。
Session的数据结构的要求：同步、易操作。因此使用ConcurrentHashMap来存放。
Token
Token，就是令牌，最大的特点就是随机性，不可预测。一般黑客或软件无法猜测出来。
Token一般用在两个地方:
- 防止表单重复提交、
- anti csrf攻击（跨站点请求伪造）。
两者在原理上都是通过session token来实现的。当客户端请求页面时，服务器会生成一个随机数Token，并且将Token放置到session当中，然后将Token发给客户端（一般通过构造hidden表单）。下次客户端提交请求时，Token会随着表单一起提交到服务器端。
然后，如果应用于“anti csrf攻击”，则服务器端会对Token值进行验证，判断是否和session中的Token值相等，若相等，则可以证明请求有效，不是伪造的。
不过，如果应用于“防止表单重复提交”，服务器端第一次验证相同过后，会将session中的Token值更新下，若用户重复提交，第二次的验证判断将失败，因为用户提交的表单中的Token没变，但服务器端session中Token已经改变了。
上面的session应用相对安全，但也叫繁琐，同时当多页面多请求时，必须采用多Token同时生成的方法，这样占用更多资源，执行效率会降低。因此，也可用cookie存储验证信息的方法来代替session Token。比如，应对“重复提交”时，当第一次提交后便把已经提交的信息写到cookie中，当第二次提交时，由于cookie已经有提交记录，因此第二次提交会失败。
不过，cookie存储有个致命弱点，如果cookie被劫持（xss攻击很容易得到用户cookie），那么又一次gameover。黑客将直接实现csrf攻击。
所以，安全和高效相对的。具体问题具体对待吧。
此外，要避免“加token但不进行校验”的情况，在session中增加了token，但服务端没有对token进行验证，根本起不到防范的作用。
还需注意的是，对数据库有改动的增删改操作，需要加token验证，对于查询操作，一定不要加token，防止攻击者通过查询操作获取token进行csrf攻击。但并不是这样攻击者就无法获得token，只是增大攻击成本而已。
版权声明：本文为博主原创文章，未经博主允许不得转载。