【cookie和session】娓娓道来cookie和session

情景导入

我们都知道 HTTP 协议是无状态的，所谓的无状态就是客户端每次想要与服务端通信，都必须重新与服务端链接，意味着请求一次客户端和服务端就连接一次，下一次请求与上一次请求是没有关系的。

这种无状态的方式就会存在一个问题：如何判断两次请求的是同一个人？就好比用户在页面 A 发起请求获取个人信息，然后在另一个页面同样发起请求获取个人信息，我们如何确定这俩个请求是同一个人发的呢？

为了解决这种问题，我们就迫切需要一种方式知道发起请求的客户端是谁？此时，cookie、token、session 就出现了。

为什么需要cookie？

所谓HTTP是无状态的，指的是同一个浏览器访问同一个服务器，它们产生了连接。那当它们连接上以后，就可以发送多次请求，多次请求之间没有任何关系。从服务器角度来说，即使是同一个浏览器像服务器发送多个请求，对于每个请求，服务器也还是会把它当成陌生人对待，即便你来自同一个位置，同一个地方。

这就带来了一个问题，平时我们访问很多网站，它都需要有持续性的交互。比如说访问电商网站，我们假如看中了一个鼠标，加入到购物车；我又打开一个网页，看中了一个键盘，然后加入到购物车。那按理来讲，最后结算时一定要看到键盘和鼠标。但是我们刚才讲了，两次请求其实没有任何关系，那就意味着它不会把键盘和鼠标都放在一起成为一个订单。服务器记不住，浏览器更加记不住，这种状况就叫Http是无状态的。

官方解释就是：同一个浏览器访问同一个服务器，多次请求之间彼此是独立的，无关联的。或者说服务器无法记住浏览器的状态，它不能识别你是谁。

那我们怎么解决这种业务连续性的问题呢？肯定是有办法的，用cookie可以解决这个问题。这里有一个结论：Http本质上是无状态的，使用cookie可以创建有状态的会话。

那什么是Http cookie呢？刚才我们说的本质的问题是服务器记不住，那我们就应该想办法让它记住，那业务不就可以延续了吗？cookie就是一项想办法让服务器记住浏览器的意思。

cookie是一个特殊的数据，服务器将cookie发送到浏览器，浏览器得到它之后会自动保存，下次浏览器访问服务器的时候，会自动携带该数据，将其发送给服务器。

不过这也有缺点，就是cookie是存放在客户端的，客户端远不如服务器安全。

这就引出了一个新的名词：session。session和cookie正好相反，session是存放在服务端的，放在服务端更安全，但是服务端内存压力也同样会增大。

所以，假如你的数据很隐私，那就最好放在session，如果数据不是隐私的话，cookie就行了。

为什么需要session？

我们来讲一下session的原理：

第一次请求，浏览器访问了服务器，那服务器就会创建一个session对象（而不是cookie对象），这个session对象就会存在于服务器端，它不会把整个session对象都发送给浏览器。那么，浏览器和服务器可是多对一的关系，那每个浏览器访问服务器都会产生一个session，那下次浏览器再访问服务器的时候，服务器怎么知道你这个浏览器和这个session对应，那个浏览器和那个session对应呢？也就是说浏览器和服务器对应的依赖关系如何区分？

其实可以这样做：服务器在响应的时候，会自动向浏览器发送一份数据，这份数据是吧通过cookie携带的，在cookie中存了一个sessionid，sessionid是这个对象的唯一标识，它把这个唯一标识通过cookie发送给浏览器。当浏览器下次访问服务器时，它会将sessionid也发给服务器，那服务器接受到sessionid后，利用这个sessionid在内存里一找，就找到了与这个浏览器对应的session（也可以说找到了与浏览器对应的数据）。

总之，session依赖于cookie，但session存在于服务器端，虽然会对服务器内存一定的压力，但是更加安全。不过，我们平时能用cookie就用cookie，实在不行就用session。

不过，大家有没有想过，若只有一个服务器，那你session随便用都没啥问题。但是，假如我分布式的部署好几台服务器，那还可以用session吗？

答案肯定是不行的。为什么会有问题呢？

就像上面这样，假如我第一次请求，通过Nginx访问服务端，Nginx将我引导到了服务器1，服务器1给我一个sessionid标记，浏览器拿到这个sessionid后，再次通过Nginx访问服务器。此时，Nginx为了让服务器负载均衡，Nginx就会将我的这次请求引导到服务器3，那这个时候，服务器3是没有我的这个sessionid的（我的这个sessionid在服务器1那里），那这个服务器3就傻眼了。

那怎么办？网上有很多乱七八糟的方法，我感觉最好用的也就是这种：