软件体系 思维导图

无状态登录（token认证） 服务器当中不记录用户的登录信息，而是将登录成功后的合法用户信息以token方式保存到客户端当中，用户在每次请求都携带token信息。 优点： 减轻服务端存储session的压力； 支持分布式，支持单点登录并对移动端友好； 支持跨域； 无需考虑CSRF：由于不再依赖cookie，所以采用token认证方式不会发生CSRF，所以也就无需考虑CSRF的防御

JWT由3部分组成：标头(Header)、有效载荷(Payload)和签名(Signature)。在传输的时候，会将JWT的3部分分别进行Base64编码后用.进行连接形成最终传输的字符串 JWTString = Base64(Header).Base64(Payload).HMACSHA256(base64UrlEncode(header) + “.” + base64UrlEncode(payload), secret)

在实际开发中需要用下列手段来增加JWT的安全性： 因为JWT是在请求头中传递的，所以为了避免网络劫持，推荐使用HTTPS来传输，更加安全 JWT的哈希签名的密钥是存放在服务端的，所以只要服务器不被攻破，理论上JWT是安全的。因此要保证服务器的安全 JWT可以使用暴力穷举来破解，所以为了应对这种破解方式，可以定期更换服务端的哈希签名密钥(相当于盐值)。这样可以保证等破解结果出来了，你的密钥也已经换了

黑名单

白名单

Key/Value 单个cookie保存的数据不能超过4K，一般会设置不会超过20个

因为Http协议是无状态的,在Session出现以前，一直是由Cookie来保证服务会话，它是由服务器颁发给浏览器的通行证

同源策略保证浏览器数据安全问题 网站B拿到银行网站A的Cookie 获取敏感数据 是很危险的，随着互联网的发展，“同源政策”越来越严格。目前，如果非同源，共有三种行为受到限制 　　1、Cookie、LocalStorage 和 IndexedDB 无法读取 　　2、DOM 无法获得 　　3、AJAX 请求无效（可以发送，但浏览器会拒绝接受响应）

Cookie的maxAge决定着Cookie的有效期

修改/删除 Cookie只有response.addCookie(Cookie cookie)做覆蓋，没有删除 设置MaxAge =0 为删除

如何禁用

由于Cookie和Seesion是成对使用，如果没有禁用Cookie或者没有Cookie怎么办？

Unicode编码：保存中文

BASE64编码：保存二进制图片

Unicode和 ASCII 属于字符集，UTF-8是编码 UTF-8是变长编码，编码英文的时候使用ASCII 中文使用Unicode

属 性 名 描 述 String name 该Cookie的名称。Cookie一旦创建，名称便不可更改 Object value 该Cookie的值。如果值为Unicode字符，需要为字符编码。如果值为二进制数据，则需要使用BASE64编码 int maxAge 该Cookie失效的时间，单位秒。如果为正数，则该Cookie在maxAge秒之后失效。如果为负数，该Cookie为临时Cookie，关闭浏览器即失效，浏览器也不会以任何形式保存该Cookie。如果为0，表示删除该Cookie。默认为–1 boolean secure 该Cookie是否仅被使用安全协议传输。安全协议。安全协议有HTTPS，SSL等，在网络上传输数据之前先将数据加密。默认为false String path 该Cookie的使用路径。如果设置为“/sessionWeb/”，则只有contextPath为“/sessionWeb”的程序可以访问该Cookie。如果设置为“/”，则本域名下contextPath都可以访问该Cookie。注意最后一个字符必须为“/” String domain 可以访问该Cookie的域名。如果设置为“.google.com”，则所有以“google.com”结尾的域名都可以访问该Cookie。注意第一个字符必须为“.” String comment 该Cookie的用处说明。浏览器显示Cookie信息的时候显示该说明 int version 该Cookie使用的版本号。0表示遵循Netscape的Cookie规范，1表示遵循W3C的RFC 2109规范

除了使用Cookie，Web应用程序中还经常使用Session来记录客户端状态。Session是服务器端使用的一种记录客户端状态的机制，使用上比Cookie简单一些，相应的也增加了服务器的存储压力。

　Session保存在服务器端。为了获得更高的存取速度，服务器一般把Session放在内存里。每个用户都会有一个独立的Session。如果Session内容过于复杂，当大量客户访问服务器时可能会导致内存溢出。因此，Session里的信息应该尽量精简。 　　Session在用户第一次访问服务器的时候自动创建。需要注意只有访问JSP、Servlet等程序时才会创建Session，只访问HTML、IMAGE等静态资源并不会创建Session。如果尚未生成Session，也可以使用request.getSession(true)强制生成Session。 　　Session生成后，只要用户继续访问，服务器就会更新Session的最后访问时间，并维护该Session。用户每访问服务器一次，无论是否读写Session，服务器都认为该用户的Session“活跃（active）”了一次。

由于会有越来越多的用户访问服务器，因此Session也会越来越多。为防止内存溢出，服务器会把长时间内没有活跃的Session从内存删除。这个时间就是Session的超时时间。如果超过了超时时间没访问过服务器，Session就自动失效了。 　　Session的超时时间为maxInactiveInterval属性，可以通过对应的getMaxInactiveInterval()获取，通过setMaxInactiveInterval(longinterval)修改。 　　Session的超时时间也可以在web.xml中修改。另外，通过调用Session的invalidate()方法可以使Session失效。

cookie数据存放在客户的浏览器上，session数据放在服务器上.

Cookie不是很安全，别人可以分析存放在本地的Cookie并进行Cookie欺骗考虑到安全应当使用Session。

单个cookie保存的数据不能超过4K，很多浏览器都限制一个站点最多保存20个cookie。(Session对象没有对存储的数据量的限制，其中可以保存更为复杂的数据类型)

session会在一定时间内保存在服务器上。当访问增多，会比较占用你服务器的性能考虑到减轻服务器性能方面，应当使用cookie。

设置cookie时间可以使cookie过期。但是使用session-destory（），我们将会销毁会话。

授权码模式被广泛应用于第三方互联网开放平台，通过第三方登录是其最常见应用场景之一，比如使用微信、QQ和淘宝账号进行登录。

https://xxx.com/authorize? response_type=code& #请求返回授权码 client_id=CLIENT_ID& redirect_uri=xxx& #重定向地址 scope=write #申请读权限 客户端拿到授权码之后再去获取token

针对授权码模式 少了获取授权码的过程，直接获取token

https://xxx.com/oauth/authoriize? response_type=token& client_id=xxx& redirect_uri=http://xx& scope=read

密码模式比较好理解，用户在客户端输入自己的用户名和密码，客户端拿着信息直接去授权服务申请令牌，请求响应返回token。grant_type 为 password 表示密码式授权。

https://xxx.com/token? grant_type=password& username=xxx& password=xxx& client_id=client_Id

注意：这种模式非常危险，除非高度信任

凭证式和密码式很相似，主要适用于那些没有前端的命令行应用，可以用最简单的方式获取应用的令牌。 grant_type 为 client_credentials 表示凭证式授权，client_id 和 client_secret 用来识别身份

https://xxx.com/token? grant_type=client_credentials& client_id=XXX& client_secret=xxx

上面几种授权方式例子中，涉及到client_id及client_secret，一般也不会放在url里，都是header头中，Authorization设置为Basic + Base64(client_id:client_secret)。

客户端安全

https://zhuanlan.zhihu.com/p/507011790

子主题 3

子主题 4

待补充

用户界面层：controller 应用层：组装领域以及领域用到的基础层的Component对象 领域层：业务逻辑层，非spring bean对象 基础设施层：包含数据访问层

用户界面层：controller 应用层：组装领域以及领域用到的基础层的Component对象 基础基础层：包含数据访问层 领域层：业务逻辑层，非spring bean对象

command：六边形架构 query：三层架构，query-查询操作，查询后更新某个表字段的操作也算是查询操作使用三层架构

拓展点

CGLIB 是对目标对象本身进行代理，所以无论目标对象是否有接口，都可以对目标对象进行代理，其原理是使用字节码生成工具在内存生成一个继承目标对象的代理类，然后创建代理对象实例。由于代理类的父类是目标对象，所以代理类是可以赋值给目标对象的，自然如果目标对象有接口，代理对象也是可以赋值给接口的。 CGLIB 动态代理中生成的代理类的字节码相比 JDK 来说更加复杂。 JDK 使用反射机制调用目标类的方法，CGLIB 则使用类似索引的方式直接调用目标类方法，所以 JDK 动态代理生成代理类的速度相比 CGLIB 要快一些，但是运行速度比 CGLIB 低一些，并且 JDK 代理只能对有接口的目标对象进行代理。

项目配置放到GIT或者本地 需要项目重启才能生效

消费者/生产者模式

目前 Spring Cloud Bus 支持两种消息代理：RabbitMQ 和 Kafka，

http1.0

http2.0

https=HTTP+SSL

如何防御

CSRFTester

如何防御XSS攻击

线程池

新建线程

锁

对如今的缓存和磁盘来说，数据有很大的差差异，但是缓存的真正目的是将数据预热，方便拿，就好像我每次要做一件事情前，先把需要的东西放在身边，如果忽视这种物理距离，那么还有结构是优化空间的，有序总比无序找得快