三亚市建设局网站,电子商务网站建设期末试题08答案,竞价网站转化率为多少,怎样做代刷网站长一、概述
1.1 HTTP无状态问题
目前主流的服务采用的是B\S架构#xff0c;即浏览器\服务端架构。一般采用的协议是HTTP#xff0c;HTTP有个特点是无状态#xff0c;即在一次连接#xff0c;两次成功请求之间没有任何的关系。这个特性既带来了一定的优点#xff0c;在某些…一、概述
1.1 HTTP无状态问题
目前主流的服务采用的是B\S架构即浏览器\服务端架构。一般采用的协议是HTTPHTTP有个特点是无状态即在一次连接两次成功请求之间没有任何的关系。这个特性既带来了一定的优点在某些场景下也有不足。 优点因为服务器不会去记录HTTP的状态所以不需要额外的资源来记录状态信息减轻了服务器的负担 缺点因为没有记忆能力如果后续操作需要前面的信息必须重传效率低。例如用户在进行购物时用户将某一个商品加入购物车切换页面后再次添加另一个商品者两次添加商品的请求之间没有任何关系。因此浏览器就无法知道用户最终选择了哪些商品。可使用HTTP的头部进行扩展来解决此问题。 1.2 解决方案
目前主要有三种主流的解决方案Cookie机制、Session机制以及Token机制。
二、三种机制的原理
2.1 Cookie机制原理
2.1.1 特点
服务器发送到浏览器并保存到浏览器的一小块数据浏览器下次访问该服务器时会自动携带该块数据将其发送给服务器。主要用于服务器判断请求是否来自同一个浏览器。
2.1.2 原理
核心机制通过在请求和响应报文中写入Cookie信息来控制客户端的状态 当客户端第一次向服务器请求信息时后端服务器会将需要验证的信息以Key-Value的形式放入Cookie中并将Cookie放入到响应报文中客户端会解析响应报文取出Cookie并保存Cookie当该客户端再次向服务器发送请求报文时会在请求报文中添加Cookie信息服务器在收到请求报文时会解析Cookie中的信息判断是否和预期设置的验证信息一致进而达到不同请求之间的数据互通。 2.1.3 优缺点
优点1. 可配置到期时间;2. 简单性Cookie是一种基于文本的轻量结构包含简单的键值对;3. 数据持久性Cookie在过期之前一直存储在客户端浏览器上。
缺点1. 大小受限制大多数浏览器对Cookie的大小有4K、8K的限制;2. 用户配置Cookie禁用有些用户会在浏览器客户端禁用Cookie的能力3. 安全性差Cookie由于存在在浏览器,有可能会被篡改2.1.4 代码实现
/*
* 服务器生成Cookie
* */
RequestMapping(path /cookie/set, method RequestMethod.GET)
ResponseBody
public String setCookie(HttpServletResponse response) {Cookie cookie new Cookie(code, CommunityUtil.generateUUID()); // 存在验证信息cookie.setMaxAge(60 * 10); // 设置过期时间cookie.setPath(/community/alpha); // 设置生效路径response.addCookie(cookie); // 将Cookie放入到响应报文中return set cookie;
}/** 浏览器发送Cookie* */
RequestMapping(path /cookie/get, method RequestMethod.GET)
ResponseBody
public String getCookie(CookieValue(code) String code) {System.out.println(code);return get cookie;
}2.2 Session机制原理
2.2.1 特点
在服务端保存客户端的信息;Session指的是同一个浏览器发起的多次请求一旦会话关闭Session也会被销毁服务器会为每一次会话分配一个Session对象。
2.2.2 原理
核心机制服务器端生成一个Session存储浏览器的各种信息同时有唯一的一个sessionId服务器通过识别这个sessionId来实现业务的连续 打开第一次会话时服务器会默认生成一个Session服务器将各种信息存放在Session中同时服务器端隐式的生成一个Cookie用于存放SessionId会放在响应报文中返回给浏览器浏览器会保存Cookie;同一个会话下每次请求都会将SessionId放入到Cookie中发送给服务器服务器就可以解析Session获取需要的信息。 2.2.3 优缺点
优点解决了Cookie存放数据大小的限制, 同时数据保存在服务器, 安全性更高
缺点大量的Session数据存放在服务器, 占用很大的内存扩展实际生产环境中如何使用Session 背景现实生活中多采用分布式集群架构中间利用NGINX保证负载均衡若服务器A为此请求生成了session,下一次请求时因NGINX可能会请求到另一台服务器上重新生成Session无法获取到上一次请求的信息同时占用大量内存。 解决方案设置分配策略 1. 黏性Session记住上次访问主机的IP地址下一次同一请求还来请求这台服务器【缺点无法保证负载均衡】 2. 同步Session: 每生成一个session在服务器集群中同步该session;【缺点1. 同步对服务器产生性能影响2.服务器之间产生耦合对部署不利。】 3. 共享Session: 专门设置一台服务器用于存放Session;【缺点单机存在性能瓶颈一旦宕机则无法使用】 利用数据库[推荐使用]大部分存在浏览器中敏感数据直接放在Mysql数据库集群中;【缺点数据存放在硬件中性能低】 优化利用Redis数据库存放 2.2.4 代码实现
/*
* 服务器端生成session
* */
RequestMapping(path /session/set, method RequestMethod.GET)
ResponseBody
public String setSession(HttpSession session) {session.setAttribute(id, 1);session.setAttribute(name, test);return set session;
}/** 浏览器发送请求的时候session* */
RequestMapping(path /session/get, method RequestMethod.GET)
ResponseBody
public String getSession(HttpSession session) {session.getAttribute(id);session.getAttribute(name);return get session;
}2.3 Token机制原理
2.3.1 特点
JWTJSON Web Token是一种开放标准RFC 7519它定义了一种紧凑的、自包含的方式用于作为JSON对象在各方之间安全地传输信息。这些信息可以被验证和信任因为它们是数字签名的不需要存储在服务器端。
2.3.2 原理
JWT主要由三部分组成Header、PayLoad和Signature每一部分通过.分割。例如
xxxx.yyyyy.zzzzzzHeader由两部分组成算法和类型。例如
{”alg“: HS256,typ: JWT
}上述JSON数据会被encode成Base64Url, 作为JWT第一部分设置。 PayLoad载荷即存放有效信息的地方是一组claim值。claim包含claim name和claim value前者是String类型后者可以是任意的json对象。claims有三种类型reserved claimpublic claim和private claim类似于Java中的权限控制符。例如
{sub: 27927692,name: ”John“,admin: true
}上述JSON也会被encode成Base64Url 作为第二部分设置。 Signature: 签名用点号将header和payload关联起来用header中指定的加密算法对字符串进行加密。例如
signature HAMCHA256(base64UrlEncode(header) . base64UrlEncode(payload), secret密钥)最佳实践在客户端和服务端之间的传输将JWT设置在HTTP header里一般名称设置为Authorization的header, 具体格式如下
Authorization: Bearer token。Beaer之后有个空格2.3.3 代码实现 // 生成JWT TokenTestpublic void testGengerateJWT() {String jwtToken Jwts.builder()// set header.setHeaderParam(typ, JWT).setHeaderParam(alg, HS256)// set payload.claim(username, tom).claim(role, admin).setSubject(admin-role-test)// set expired time 有效期.setExpiration(new Date(System.currentTimeMillis() time)).setId(UUID.randomUUID().toString())// set signature.signWith(SignatureAlgorithm.HS256, secert).compact();System.out.println(jwtToken);}// 获取JWT Token信息以及验证Token的有效性Testpublic void testCheckJwtToken() {String token eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJ1c2VybmFtZSI6InRvbSIsInJvbGUiOiJhZG1pbiIsInN1YiI6ImFkbWluLXJvbGUtdGVzdCIsImV4cCI6MTcxMzMxOTA1NSwianRpIjoiNzViNjlhYTUtNjBmYy00NGQwLWJmYjctZGIyMWRhZWE4MDQ1In0.pg7F_gN9r6gZuMie4Ibs6IYjfvVAbywMcSSQtdUA27s;JwtParser parser Jwts.parser();Claims claims parser.setSigningKey(secert).parseClaimsJws(token).getBody();System.out.println(claims.get(username));System.out.println(claims.get(role));System.out.println(claims.getExpiration());}三、三种机制的区别和联系 是否支持跨域JWT支持跨域Cookie和Session不支持跨域只能在当前域和子域中使用存储位置JWT放在HTTP header中, Cookie放在客户端Session放在服务端安全性JWT 的安全性高于Session和Cookie性能 JWT中放在Header中若存放信息过多会使得整个网络流量非常大但不占用内存不过需要耗费解析Token的时间Session耗费服务器的内存Cookie放在客户端相对来说占用内存较小。原理JWT Token是使服务端无状态化的机制不会存储会话信息支持服务负载均衡Session使服务端有状态化会存储会话信息在分布式情况下无法负载均衡。应用场景JWT比较适合移动端不支持Cookie和内部系统跨域认证、API接口鉴权等场景特别是在微服务架构和分布式系统中。
