cas 注销不关闭浏览器异常_一次浏览器请求的生命周期

“ 我们经常使用浏览器访问各种资源，那在浏览器输入一个地址，究竟做了哪些事情呢？OSI七层协议有什么作用呢？HTTP协议请求体和返回体有哪些参数需要注意呢？” 01 — 浏览器请求-生命周期      

   如上图所示：主机A在浏览器发起一次HTTP请求，因为 HTTP协议位于应用层 ，所以请求会从应用层按照每层特定的协议模式进行向下转换，最后直到物理层按特定的协议转换成二进制流向主机B进行请求，因为主机A和B不在同一网段，途中会经过 三层路由器进行请求转发 。主机B收到的请求从物理层逐步向应用层进行解析，最后根据请求访问的具体程序执行对应逻辑并返回结果到主机A的浏览器，主机A浏览器根据主机B返回的内容进行 解析显示 ，最终就是我们在浏览器看到的结果。 注：具体各层的含义可以参考上述图片，OSI的应用层、表示层、会话层合并成为应用层则为TCP/IP五层协议。 通过上述OSI七层我们除了理解各层的作用，重要的是理解这样解决互联网信息通信的功能架构设计，是否能作为后续复杂业务的架构设计方式。 比如该架构主要的设计模式为分层业务解耦，该模式也是一个常用的模式。

如上 图所示：采用类似OSI七层协议的分层业务解耦模式，帮用户中心的服务的代码结构分为三层。 第一层聚合层， 该层主要为逻辑聚合层，一般在controller层提供对外暴露的接口，比如当你调用用户信息修改接口的时候，会调用底层的查询接口先查询数据是否存在，在对比传入待 修改数据与数据库数据是否一致，修改成功之后会调用MQ服务模块，发送一条用户信息更新的MQ。该层会根据不同的业务需求实现基础服务的聚合。 第二层基础服务层， 按照具体的业务模块划分不同的子业务聚会服务，比如你需要调用MQ，则按MQ参数要求直接调用mq服务模块就行，而且每个子服务模块都是独立的可以平移到任何一个新项目中。 第三层为数据存储层 ，该层注意封装好操作数据库以及操作redis等相关CRUD的基础功能，该层也是可以平移到任何一个新项目中。 02 — HTTP协议 HTTP协议：       

http是一个简单的请求-响应协议，它通常运行在TCP之上。它指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应。请求和响应消息的头以ASCII码形式给出；而消息内容则具有一个类似MIME的格式。这个简单模型是早期Web成功的有功之臣，因为它使得开发和部署是那么的直截了当。

百度百科

目前HTTP协议主要分为四个版本：分别是

HTTP 0.9：1991年发布

HTTP 1.0：1996年5月发布

HTTP 1.1：1997年1月发布

HTTP 2：   2015年发布

其中我们常说的HTTP其实为HTTP 1.1这个版本。 URL解析：

名称	描述
protocol(协议)	指定使用的传输协议：下面列出一些常用的 http 通过 HTTP 访问该资源。格式 HTTP:// https 通过安全的 HTTPS 访问该资源。格式 HTTPS:// file 资源是本地计算机上的文件。格式file:///，注意后边应是三个斜杠 ftp 通过 FTP访问资源。格式 FTP:// 另外该传输协议也可以自己定制，具体可参考相关博文
hostname(主机名)	存放资源的服务器的域名系统(DNS) 主机名或 IP 地址。 有时，在主机名前也可以包含连接到服务器所需的用户名和密码(格式：username:password@hostname) 比如：blog.csdn.net
port(端口)	指计算机内部或交换机路由器内的端口，不可见。如http的默认端口为80，https默认的端口为443。如果输入时省略，则使用默认端口号。如果为非标准端口号，URL中就不能省略端口号这一项
path(路径)	由零或多个“/”符号隔开的字符串，一般用来表示主机上的一个目录或文件地址。比如：/zk18286047195 协议+主机+端口+path: https://blog.csdn.net//zk18286047195
query(查询)	可选，用于给动态网页(如使用CGI、ISAPI、PHP/JSP/ASP/ASP.NET等技术制作的网页)传递参数，可有多个参数，用“&”符号隔开，每个参数的名和值用“=”符号隔开。比如：?username=zxx&age=18
fragment(信息片断)	可选，又称为锚点，用于指定浏览器中资源的位置

‍ ‍ HTTP请求头：

#HTTP头详细介绍https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers

HTTP请求方法(默认1.1版本)：

方法	说明
GET	get方法请求指定资源的表示形式。使用GET的请求应该只检索数据。 默认get方法传参数为拼接到url后面，但是get同样可以支持request body作为参数。
POST	POST方法发送数据给服务器。常用request body作为参数体发送到服务端。
PUT	PUT 与 POST 方法的区别在于，PUT方法是幂等的：调用一次与连续调用多次是等价的(即没有副作用)，而连续调用多次POST方法可能会有副作用，比如将一个订单重复提交多次。
HEAD	HEAD方法请求资源的头部信息, 并且这些头部与 HTTP GET 方法请求时返回的一致. 该请求方法的一个使用场景是在下载一个大文件前先获取其大小再决定是否要下载, 以此可以节约带宽资源。
DELETE	DELETE请求方法用于删除指定的资源。
OPTIONS	OPTIONS方法用于获取目的资源所支持的通信选项。客户端可以对特定的URL使用 OPTIONS 方法，也可以对整站(通过将 URL 设置为“*”)使用该方法。可以用来预检服务端支持的请求方法以及在CORS时获取服务端支持的请求方法与内容类型。
TRACE	TRACE 方法 实现沿通向目标资源的路径的消息环回(loop-back)测试 ，提供了一种实用的 debug 机制。
CONNECT‍	‍‍在 HTTP 协议中，CONNECT 方法可以开启一个客户端与所请求资源之间的双向沟通的通道。它可以用来创建隧道(tunnel)。

HTTP请求内容类型(content-type)：

Content-Type实体头部用于指示资源的MIME类型 media type。

在响应中，Content-Type标头告诉客户端实际返回的内容的内容类型。浏览器会在某些情况下进行MIME查找，并不一定遵循此标题的值;为了防止这种行为可以将标题 X-Content-Type-Options 设置为 nosniff。

内容类型	说明
application/x-www-form-urlencoded	客户端可以通过body发送键值对数据， 例如key1=value1&key2=value2，表单默认的提交数据的格式。数据被编码成以 '&' 分隔的键-值对, 同时以 '=' 分隔键和值. 非字母或数字的字符会被 percent-encoding: 这也就是为什么这种类型不支持二进制数据(应使用 multipart/form-data 代替)。
multipart/form-data	与application/x-www-form-urlencoded不同，这是一个多部分多媒体类型。 首先生成了一个 boundary 用于分割不同的字段，在请求实体里每个参数以------boundary开始，然后是附加信息和参数名，然后是空行，最后是参数内容。多个参数将会有多个boundary块。如果参数是文件会有特别的文件域。最后以------boundary–为结束标识。 multipart/form-data支持文件上传的格式，一般需要上传文件的表单则用该类型。
application/json	JSON数据格式，目前互联网接口常用内容类型，符合restfule风格的接口采用该类型，可以很方便的进行信息交互。
application/octet-stream	二进制流数据(如常见的文件下载)。
text/html	HTML格式。
text/xml	XML格式。

除了上述常见的内容类型(content-type)还有其他类型具体可见以下站点：

#HTTP content-typehttps://www.runoob.com/http/http-content-type.html

HTTP状态码(status)：

http状态码 是用以表示网页服务器超文本传输协议响应状态的3位数字代码。它由 RFC 2616 规范定义的，并得到 RFC 2518、RFC 2817、RFC 2295、RFC 2774 与 RFC 4918 等规范扩展。所有状态码的第一个数字代表了响应的五种状态之一。所示的消息短语是典型的，但是可以提供任何可读取的替代方案。除非另有说明，状态码是HTTP / 1.1标准(RFC 7231)的一部分。 注意：有些小伙伴写设计自己接口统一返回值的code的时候，会用http的状态码，或者当接口有异常的时候，直接强制修改http返回的status的值。 个人建议：在接口设计的时候，可以参考HTTP状态的码的设计方式，定义自己系统业务返回码，建议与HTTP码区分开来，并不要直接修改http状态码的返回值。HTTP状态用来标示接口是否已经请求成功，而业务接口返回的code码标示是否调用该接口成功。 精彩推荐

• 程序猿生活-五维能力模型
• 如何设计王者荣耀角色转移服务避免系统崩溃(附服务架构方案)
• 开源项目ZXX-CAS系统从零到一|第四篇：A-RBAC权限服务设计与实现
• 开源项目ZXX-CAS系统从零到一|第三篇：集成数据库服务
• 开源项目ZXX-CAS系统从零到一|第二篇：后端基础架构搭建
• 开源项目ZXX-CAS系统从零到一|第一篇：需求分析
• 微信抢红包到底是怎么抢到的？
• 实战-elasticsearch索引平滑迁移方案
• 武功秘籍之微服务
• 武功秘籍之熔断与降级
• 武功秘籍之限流