cookie
在cookie之前,请求中插入一个token，然后在发送请求的时候，把这个东西带给服务器，这种方式是易出错，所以有了cookie的出现；
- cookie不可跨域:在不同的域名下用，每个cookie都会绑定单一的域名;
- cookie的属性:name,value,domain,path；
- cookie的有效期:一搬，当关闭浏览器结束这个会话的时候，这个cookie也就会被删除；
- secure：这个属性设置为true时，此cookie只会在https和ssl等安全协议下传输；
- HttpOnly：这个属性设置为true，就不能通过js脚本来获取cookie的值，能有效的防止xss攻击；
- Cookie数量&大小限制及处理策略：超过大小长度的话就是直接被截取丢弃，在达到cookie限制时自动地剔除最老的cookie，以便腾出空间给许最新的cookie；
Session
- 以服务端保存状态
- 在单进程应用中，session一般是存在内存中的，不会做持久化操作或者说使用三方的服务来存session信息，如redis。但是在分布式场景下，这种存在本机内存中的方式显然是不适用的，因为session无法共享
- session的有效期：过期删除机制
- 分布式session：将session信息放在一个独立的机器上，所以分布式session要解决的问题其实就是分布式环境下的session共享的问题；
1、存取方式的不同
- Cookie中只能保管ASCII字符串，假如需求存取Unicode字符或者二进制数据，需求先进行编码。Cookie中也不能直接存取Java对象。若要存储略微复杂的信息，运用Cookie是比拟艰难的；而Session中能够存取任何类型的数据，包括而不限于String、Integer、List、Map等。Session中也能够直接保管Java Bean乃至任何Java类，对象等，运用起来十分便当。能够把Session看做是一个Java容器类。
2、隐私策略的不同
- Cookie存储在客户端阅读器中，对客户端是可见的，客户端的一些程序可能会窥探、复制以至修正Cookie中的内容。而Session存储在服务器上，对客户端是透明的，不存在敏感信息泄露的风险。
假如选用Cookie，比较好的方法是，敏感的信息如账号密码等尽量不要写到Cookie中。最好是像Google、Baidu那样将Cookie信息加密，提交到服务器后再进行解密，保证Cookie中的信息只要本人能读得懂。而假如选择Session就省事多了，反正是放在服务器上，Session里任何隐私都能够有效的保护。
3、有效期上的不同
登录信息长期有效,用户不用每次访问都重新登录
- 运用Cookie会是比较好的选择。只需要设置Cookie的过期时间属性为一个很大很大的数字。
- 由于Session依赖于名为JSESSIONID的Cookie，而Cookie JSESSIONID的过期时间默许为–1，只需关闭了阅读器该Session就会失效，因而Session不能完成信息永世有效的效果。运用URL地址重写也不能完成。而且假如设置Session的超时时间过长，服务器累计的Session就会越多，越容易招致内存溢出。
4、服务器压力的不同
- Session是保管在服务器端的，每个用户都会产生一个Session。假如并发访问的用户十分多，会产生十分多的Session，耗费大量的内存。而Cookie保管在客户端，不占用服务器资源。假如并发阅读的用户十分多，Cookie是很好的选择。
因而像Google、Baidu、Sina这样并发访问量极高的网站，是不太可能运用Session来追踪客户会话的。关于Google、Baidu、Sina来说，Cookie或许是唯一的选择。
5、浏览器支持的不同
- Cookie是需要客户端浏览器支持的。
假如客户端禁用了Cookie，或者不支持Cookie，则会话跟踪会失效。关于WAP上的应用，常规的Cookie就派不上用场了。
-
假如客户端浏览器不支持Cookie，需要运用Session以及URL地址重写。需要注意的是一切的用到Session程序的URL都要进行URL地址重写，否则Session会话跟踪还会失效。关于WAP应用来说，Session+URL地址重写或许是它唯一的选择。
-
假如客户端支持Cookie，则Cookie既能够设为本浏览器窗口以及子窗口内有效（把过期时间设为–1），也能够设为一切阅读器窗口内有效（把过期时间设为某个大于0的整数）。但Session只能在本阅读器窗口以及其子窗口内有效。假如两个浏览器窗口互不相干，它们将运用两个不同的Session。（IE8下不同窗口Session相干）
6、跨域支持上的不同
- Cookie支持跨域名访问，Session仅在他所在的域名内有效。
例如将domain属性设置为“.biaodianfu.com”，则以“.biaodianfu.com”为后缀的一切域名均能够访问该Cookie。跨域名Cookie如今被普遍用在网络中，例如Google、Baidu、Sina等。而Session则不会支持跨域名访问。
7、存储大小不同
- 单个 Cookie 保存的数据不能超过 4K，Session 可存储数据远高于 Cookie。
Cookie 和 Session 是如何配合
用户第一次请求服务器的时候，服务器根据用户提交的相关信息，创建创建对应的 Session ，请求返回时将此 Session 的唯一标识信息 SessionID 返回给浏览器，浏览器接收到服务器返回的 SessionID 信息后，会将此信息存入到 Cookie 中，同时 Cookie 记录此 SessionID 属于哪个域名。 当用户第二次访问服务器的时候，请求会自动判断此域名下是否存在 Cookie 信息，如果存在自动将 Cookie 信息也发送给服务端，服务端会从 Cookie 中获取 SessionID，再根据 SessionID 查找对应的 Session 信息，如果没有找到说明用户没有登录或者登录失效，如果找到 Session 证明用户已经登录可执行后面操作。
如果浏览器中禁止了 Cookie，如何保障整个机制的正常运转
服务端是根据 Cookie 中的信息判断用户是否登录
- 第一种方案，每次请求中都携带一个 SessionID 的参数，也可以 Post 的方式提交，也可以在请求的地址后面拼接 xxx?SessionID=123456...。
- 第二种方案，Token 机制。Token 机制多用于 App 客户端和服务器交互的模式，也可以用于 Web 端做用户状态管理。
Token 的意思是“令牌”，是服务端生成的一串字符串，作为客户端进行请求的一个标识。Token 机制和 Cookie 和 Session 的使用机制比较类似。 当用户第一次登录后，服务器根据提交的用户信息生成一个 Token，响应时将 Token 返回给客户端，以后客户端只需带上这个 Token 前来请求数据即可，无需再次登录验证。
分布式 Session
在互联网公司为了可以支撑更大的流量，后端往往需要多台服务器共同来支撑前端用户请求，那如果用户在 A 服务器登录了，第二次请求跑到服务 B 就会出现登录失效问题。
分布式 Session 一般会有以下几种解决方案：建议采用第三种方案。
-
Nginx ip_hash 策略，服务端使用 Nginx 代理，每个请求按访问 IP 的 hash 分配，这样来自同一 IP 固定访问一个后台服务器，避免了在服务器 A 创建 Session，第二次分发到服务器 B 的现象。
-
Session 复制，任何一个服务器上的 Session 发生改变（增删改），该节点会把这个 Session 的所有内容序列化，然后广播给所有其它节点。
-
共享 Session，服务端无状态话，将用户的 Session 等信息使用缓存中间件来统一管理，保障分发到每一个服务器的响应结果都一致。
跨域请求？Jsonp 跨域的原理
- 同源策略/SOP（Same origin policy）是一种约定，由 Netscape 公司 1995年引入浏览器，它是浏览器最核心也最基本的安全功能，如果缺少了同源策略，浏览器很容易受到 XSS、CSFR 等攻击。所谓同源是指"协议+域名+端口"三者相同，即便两个不同的域名指向同一个 ip 地址，也非同源。
- 解决跨域请求的常用方法是： 通过代理来避免，比如使用 Nginx 在后端转发请求，避免了前端出现跨域的问题; 通过 Jsonp 跨域; 其它跨域解决方案;
- Jsonp 跨域原理:浏览器的同源策略把跨域请求都禁止了，但是页面中的
<script><img><iframe>标签是例外，不受同源策略限制。Jsonp 就是利用<script>标签跨域特性进行跨域数据访问。
JSONP 的理念就是，与服务端约定好一个回调函数名，服务端接收到请求后，将返回一段 Javascript，在这段 Javascript 代码中调用了约定好的回调函数，并且将数据作为参数进行传递。当网页接收到这段 Javascript 代码后，就会执行这个回调函数，这时数据已经成功传输到客户端了。
部分参考：
作者：ityouknow
链接：https://juejin.cn/post/1cd9037ee51d456e5c5babca
