1.概念：是用来存储信息的数据对象。它是一个抽象对象，指的是由多个关联的http请求组成的会话。一些信息可以在多个请求之间共享。2、实现方案：方案一：在每个请求的参数或数据中带上相关信息。不受cookie限制，但受请求长度限制。方案二：使用cookies来存储，可以是整个session的具体数据，也可以是session标识（sessin_id）。3.特点：只存在于服务器端。服务器本身不支持它。它由中间件本身创建和管理。session只是一个对象信息，可以保存在cookie中，也可以保存在任何地方（如内存、数据库）。保存在哪里可以由开发者决定。session_id，唯一标识session，和其他必要的信息会放在cookie中，一起返回给前端。其他信息可以保存在以session_id命名的文件中。4.session的负面影响：性能影响。如果用户多，信息存放在sessin文件中，查找太费时间（可以分目录和hash等）。可以自己实现session，将session信息存入数据库。这种方式最好给数据库设置缓存，不然上千万条数据过于频繁的查找会消耗很多资源。5.Session清除：定期清理session（清除server端的session文件，client端的cookie信息）cookies，设置expires为过去的时间/max-age=0，client端的cookie信息会过期,浏览器会自动删除。6、koa-session的原理：【有时间一定要看源码。阅读源码时一定要注意命名、特征、知识点的学习。我也会学习写koa插件的过程】【看源码，首先要有一个整体的控制图，然后一步步分析】使用过程：app.use(session(CONFIG,app));//初始化中间的koa-session组件letn=ctx.session.views||0;//每次初始化当前用户的会话时，将会话对象挂载到app.context上。所以你可以稍后从ctx.session中获取会话。接收http请求时，默认将数据json塞入cookie中，即cookie用于存储加密后的session信息。如果设置了外部存储，将调用store.set()来保存会话。具体的保存逻辑和保存位置由store对象自己决定！使用cookie存储时，序列化session（包括过期时间），做简单的base64编码。即使信息保存在文件中，它仍然是必要的。cookiesession_id的默认实现是一个时间戳，后跟一个随机字符串。koa-session允许用户在config中配置自己的编解码函数，所以完全可以使用自定义的加解密函数对session进行编解码7.session认证过程：当用户登录时，服务器产生一个sessionandid标识sessionid，通过cookies在client和server之间传递。服务端可以通过sessionid获取session的相关信息，然后响应client的请求；如果没有找到有效的session，则认为该用户处于非登录状态的session会有一个过期时间，也可以通过一些操作（比如注销）主动删除。8、分布式session：问题：在分布式环境下，前后访问的服务器不同，因此无法准确保存session。将session信息放在独立机器上的缺点（可以是独立的数据库服务，也可以是缓存服务）：但是一旦持久层宕机，就会是单点故障。新方案：干脆不保存session数据，所有数据都保存在客户端，每次请求都会回传给服务端（这就是token）9.cookie和session的区别：保存位置不同：cookie->客户端浏览器。session->服务器隐私策略不同：cookie->不是很安全，cookie劫持。Session->相对安全性能不同：session->流量过大时，服务器性能存储大小不同：cookie->有大小限制，一般不超过4K10。使用session需要考虑的问题将session存储在服务器中，当有很多用户同时在线时，这些session会占用较多的内存，需要在服务器端定期清理过期的session。当网站部署在集群中时，会遇到多个web服务器之间如何共享session的问题。因为session是由单个服务器创建的，但是处理用户请求的服务器不一定是创建session的服务器，那么服务器就无法获取到之前已经放在session中的登录凭证等信息。当多个应用要共享session时，除了上述问题外，还会遇到跨域问题，因为不同的应用可能部署在不同的主机上，需要在每个应用中处理cookie跨域处理。sessionId保存在cookie中，如果浏览器禁止cookies或者不支持cookies怎么办？一般是sessionId后面跟url参数重写url，所以session不一定需要依赖cookies。移动端对cookie的支持不是很好，需要基于cookie实现session，所以移动端常用的是token11。Distributed架构下的session共享方案1.Sessionreplication如果任意一台服务器上的session发生变化（增删改查），该节点会将session的所有内容序列化，然后广播给所有其他节点，无论是否其他服务器是否需要会话。这确保了会话同步。优点：容错，服务器之间的会话可以实时响应。缺点：会对网络负载造成一定的压力。如果会话数量很大，可能会导致网络拥塞并降低服务器性能。2、stickysession/IP绑定策略，利用Ngnix中的ip_hash机制，将某个ip的所有请求都指向同一个服务器，即把用户绑定到服务器上。当用户第一次请求时，负载均衡器将用户的请求转发给A服务器。如果负载均衡器设置了stickysession，那么用户后续的每次请求都会转发到A服务器，相当于连接了用户和A服务器。服务器粘在一起，这就是粘性会话机制。优点：简单，不需要对session做任何处理。缺点：缺乏容错能力，如果当前访问的服务器出现故障，将用户转移到第二台服务器上，他的session信息就会失效。适用场景：故障对客户影响不大；服务器故障是低概率事件。实现方法：以Nginx为例，在upstream模块配置ip_hash属性，实现粘性会话。3、Session共享（常用）采用Memcached、Redis等分布式缓存方案对Session进行缓存，但需要将Memcached或Redis集群化，将Session存储在Redis中。虽然架构变得复杂，需要重新访问Redis，但是这种方案带来的好处也是很大的：实现了session共享；水平扩展（增加Redis服务器）；服务器重启后session不丢失（还要注意Redis中的session刷新/失效机制）；不仅是跨服务器session共享，甚至是跨平台（比如网页端和APP端）4.session持久化将session存储在数据库中，保证session的持久化。优点：如果服务器出现问题，会话不会丢失。如果量很大，将session存入数据库会给数据库带来很大的压力，需要额外的开销来维护数据库。只要关闭浏览器，session就真的消失了吗？错误的。对于session，除非程序通知服务器删除一个session，否则服务器会永远保留它。程序一般会在用户注销时发送删除会话的命令。但是浏览器在关闭前从来不会主动通知服务器自己将要关闭，所以服务器永远没有机会知道浏览器已经关闭。造成这种错觉的原因是大部分session机制使用sessioncookies来保存sessionids，关闭浏览器后sessionid消失，再次连接服务器时就找不到原来的session了。如果服务器设置的cookie保存在硬盘上，或者通过某种手段改写浏览器发送的HTTP请求头，将原来的sessionid发送给服务器，打开浏览器仍然可以打开原来的session再次。正是因为关闭浏览器不会导致session被删除，才迫使服务器为session设置一个过期时间。当客户端最后一次使用会话的时间超过这个过期时间时，服务器认为客户端已经停止了它的活动。该会话将被删除以节省存储空间。12.参考：-https://www.cnblogs.com/woodk/p/10129836.html-查看源码时，可以画出主要模块的思维导图，更有利于理解。-https://www.cnblogs.com/longhao/p/3558871.html-https://www.jianshu.com/p/8f4cc45d712e-https://segmentfault.com/a/1190000013039187-https://juejin.im/post/59d1f59bf265da06700b0934#heading-9-https://juejin.im/post/5d01f82cf265da1b67210869#heading-11
