网络面经：你真的了解Cookie和Session吗？

在初级面试中，关于Cookie和Session的区别是一个高频的面试题。如果只是机械的回答一下它们的区别，那你可能真的不了解Cookie和Session，就更别说灵活运用了。

这篇文章带你从Cookie和Session的初级应用到高级应用捋一遍，看看有多少不知道的内容。

什么是Cookie?

我们知道HTTP协议是无状态的，一次请求完成，不会持久化请求与相应的信息。那么，在购物车、用户登录状态、页面个性化设置等场景下，就无法识别特定用户的信息。这时Cookie就出现了。

Cookie是客户端保存用户信息的一种机制，将服务器发送到浏览器的数据保存在本地，下次向同一服务器再发起请求时被携带发送。对于Cookie，可以设置过期时间。

通常，Cookie用于告知服务端两个请求是否来自同一浏览器，如保持用户的登录状态。这样就解决了HTTP无状态的问题。

Cookie主要用于以下方面：

会话状态管理(如用户登录状态、购物车、游戏分数或其它需要记录的信息)
个性化设置(如用户自定义设置、主题等)
浏览器行为跟踪(如跟踪分析用户行为等)

Cookie存储在客户端，这就意味着，可以通过一些方式进行修改，欺骗服务器。针对这个问题，怎么解决呢?那就引入了Session。

什么是Session?

Session代表服务器和客户端一次会话的过程。

维基百科这样解释道：在计算机科学领域来说，尤其是在网络领域，会话(session)是一种持久网络协议，在用户(或用户代理)端和服务器端之间创建关联，从而起到交换数据包的作用机制，session在网络协议(例如telnet或FTP)中是非常重要的部分。

对照Cookie，Session是一种在服务器端保存数据的机制，用来跟踪用户状态的数据结构，可以保存在文件、数据库或者集群中。

当在应用程序的Web页之间跳转时，存储在Session对象中的变量将不会丢失，而会在整个用户会话中一直存在下去。当客户端关闭会话，或者Session超时失效时会话结束。

目前大多数的应用都是用Cookie实现Session跟踪的。第一次创建Session时，服务端会通过在HTTP协议中返回给客户端，在Cookie中记录SessionID，后续请求时传递SessionID给服务，以便后续每次请求时都可分辨你是谁。

Cookie与Session的区别

关于Cookie与Session的区别，就是在面试中经常回答的问题了。

作用范围不同，Cookie 保存在客户端(浏览器)，Session 保存在服务器端。
存取方式的不同，Cookie只能保存 ASCII，Session可以存任意数据类型，比如UserId等。
有效期不同，Cookie可设置为长时间保持，比如默认登录功能功能，Session一般有效时间较短，客户端关闭或者Session超时都会失效。
隐私策略不同，Cookie存储在客户端，信息容易被窃取;Session存储在服务端，相对安全一些。
存储大小不同，单个Cookie 保存的数据不能超过 4K，Session可存储数据远高于Cookie。

禁用Cookie会怎样?

如果客户在浏览器禁用了Cookie，该怎么办呢?

方案一：拼接SessionId参数。在GET或POST请求中拼接SessionID，GET请求通常通过URL后面拼接参数来实现，POST请求可以放在Body中。无论哪种形式都需要与服务器获取保持一致。

这种方案比较常见，比如老外的网站，经常会提示是否开启Cookie。如果未点同意或授权，会发现浏览器的URL路径中往往有@quot;?sessionId=123abc@quot;这样的参数。

方案二：基于Token(令牌)。在APP应用中经常会用到Token来与服务器进行交互。Token本质上就是一个唯一的字符串，登录成功后由服务器返回，标识客户的临时授权，客户端对其进行存储，在后续请求时，通常会将其放在HTTP的Header中传递给服务器，用于服务器验证请求用户的身份。

分布式系统中Session如何处理?

在分布式系统中，往往会有多台服务器来处理同一业务。如果用户在A服务器登录，Session位于A服务器，那么当下次请求被分配到B服务器，将会出现登录失效的问题。

针对类似的场景，有三种解决方案：

方案一：请求精确定位。也就是通过负载均衡器让来自同一IP的用户请求始终分配到同一服务上。比如，Nginx的ip_hash策略，就可以做到。

方案二：Session复制共享。该方案的目标就是确保所有的服务器的Session是一致的。像Tomcat等多数主流web服务器都采用了Session复制实现Session的共享.

方案三：基于共享缓存。该方案是通过将Session放在一个公共地方，各个服务器使用时去取即可。比如，存放在Redis、Memcached等缓存中间件中。

在Spring Boot项目中，如果集成了Redis，Session共享可以非常方便的实现。

同源策略与跨域请求

所谓的“同源”指的是“三个相同”：协议相同、域名相同、端口相同。只有这三个完全相同，才算是同源。

同源策略的目的：是为了保证用户信息的安全，防止恶意的网站窃取数据。

比如，用户访问了银行网站A，再去浏览其他网站，如果其他网站可以读取A的Cookie，隐私信息便会泄露。更可怕的是，通常Cookie还用来保存用户登录状态，会出现冒充用户行为。因此，@quot;同源策略@quot;是必需的，如果Cookie可以共享，互联网就毫无安全可言了。

同源策略保证了一定的安全性，但在某些场景下也带来了不便，比如常见的跨域请求问题。

在HTML中，@lt;a@gt;,@lt;form@gt;, @lt;img@gt;, @lt;script@gt;, @lt;iframe@gt;, @lt;link@gt; 等标签以及Ajax都可以指向一个资源地址，而所谓的跨域请求就是指：当前发起请求的域与该请求指向的资源所在的域不一样。同源即同域，三项有一项不同便会出现跨域请求。

浏览器会对跨域请求做出限制，因为跨域请求可能会被利用发动CSRF攻击。

CSRF（Cross-site request forgery），即“跨站请求伪造”，也被称为：one click attack/session riding，缩写为：CSRF/XSRF。CSRF攻击者在用户已经登录目标网站之后，诱使用户访问一个攻击页面，利用目标网站对用户的信任，以用户身份在攻击页面对目标网站发起伪造用户操作的请求，达到攻击目的。

针对跨域请求通常有如下方法：