第一步：浏览器输入域名
例如输入：www.csdn.net/
第二步：浏览器查找域名的IP地址
浏览器会把输入的域名解析成对应的IP，其过程如下：
1.查找浏览器缓存：因为浏览器一般会缓存DNS记录一段时间，不同浏览器的时间可能不一样，一般2-30分钟不等，浏览器去查找这些缓存，如果有缓存，直接返回IP，否则下一步。
2.查找系统缓存：浏览器缓存中找不到IP之后，浏览器会进行系统调用（windows中是gethostbyname），查找本机的hosts文件，如果找到，直接返回IP，否则下一步。
3.查找路由器缓存：如果1,2步都查询无果，则需要借助网络，路由器一般都有自己的DNS缓存，将前面的请求发给路由器，查找ISP 服务商缓存 DNS的服务器，如果查找到IP则直接返回，没有的话继续查找。
4.递归查询：如果以上步骤还找不到，则ISP的DNS服务器就会进行递归查询，所谓递归查询就是如果主机所询问的本地域名服务器不知道被查询域名的IP地址，那么本地域名服务器就以DNS客户的身份，向其他根域名服务器继续发出查询请求报文，而不是让该主机自己进行下一步查询。（本地域名服务器地址是通过DHPC协议获取地址，DHPC是负责分配IP地址的）
5.迭代查询：本地域名服务器采用迭代查询，它先向一个根域名服务器查询。本地域名服务器向根域名服务器的查询一般都是采用迭代查询。所谓迭代查询就是当根域名服务器收到本地域名服务器发出的查询请求报文后，要么告诉本地域名服务器下一步应该查询哪一个域名服务器，然后本地域名服务器自己进行后续的查询。（而不是替代本地域名服务器进行后续查询）。
本例子中：根域名服务器告诉本地域名服务器，下一次应查询的顶级域名服务器dns.net的IP地址。本地域名服务器向顶级域名服务器dns.net进行查询。顶级域名服务器dns.net告诉本地域名服务器，下一次应查询的权限域名服务器dns.csdn.net的IP地址。本地域名服务器向权限域名服务器dns.csdn.net进行查询。权限域名服务器dns.csdn.net告诉本地域名服务器，所查询的主机www.csdn.net的IP地址。本地域名服务器最后把结果告诉主机。
第三步 ：浏览器与目标服务器建立TCP连接
-
主机浏览器通过DNS解析得到了目标服务器的IP地址后，与服务器建立TCP连接。 -
TCP3次握手连接：浏览器所在的客户机向服务器发出连接请求报文（SYN标志为1）；服务器接收报文后，同意建立连接，向客户机发出确认报文（SYN，ACK标志位均为1）；客户机接收到确认报文后，再次向服务器发出报文，确认已接收到确认报文；此处客户机与服务器之间的TCP连接建立完成，开始通信。
第四步：浏览器通过http协议发送请求
浏览器向主机发起一个HTTP-GET方法报文请求。请求中包含访问的URL，也就是http://www.csdn.com/ ，KeepAlive，长连接，还有User-Agent用户浏览器操作系统信息，编码等。值得一提的是Accep-Encoding和Cookies项。Accept-Encoding一般采用gzip，压缩之后传输html文件。Cookies如果是首次访问，会提示服务器建立用户缓存信息，如果不是，可以利用Cookies对应键值，找到相应缓存，缓存里面存放着用户名，密码和一些用户设置项。
第五步：某些服务会做永久重定向响应
对于大型网站存在多个主机站点，了负载均衡或者导入流量，提高SEO排名，往往不会直接返回请求页面，而是重定向。返回的状态码就不是200OK，而是301,302以3开头的重定向码，浏览器在获取了重定向响应后，在响应报文中Location项找到重定向地址，浏览器重新第一步访问即可。
重定向的作用：重定向是为了负载均衡或者导入流量，提高SEO排名。利用一个前端服务器接受请求，然后负载到不同的主机上，可以大大提高站点的业务并发处理能力；重定向也可将多个域名的访问，集中到一个站点；由于baidu.com，www.baidu.com会被搜索引擎认为是两个网站，照成每个的链接数都会减少从而降低排名，永久重定向会将两个地址关联起来，搜索引擎会认为是同一个网站，从而提高排名。
第六步：浏览器跟踪重定向地址
当浏览器知道了重定向后最终的访问地址之后，重新发送一个http请求，发送内容同上。
第七步：服务器处理请求
服务器接收到获取请求，然后处理并返回一个响应。
第八步：服务器发出一个HTML响应
返回状态码200 OK，表示服务器可以响应请求，返回报文，由于在报头中Content-type为“text/html”，浏览器以HTML形式呈现，而不是下载文件。
第九步：释放TCP连接
1.浏览器所在主机向服务器发出连接释放报文，然后停止发送数据；
2.服务器接收到释放报文后发出确认报文，然后将服务器上未传送完的数据发送完；
3.服务器数据传输完毕后，向客户机发送连接释放报文；
4.客户机接收到报文后，发出确认，然后等待一段时间后，释放TCP连接；
第十步：浏览器显示页面
在浏览器没有完整接受全部HTML文档时，它就已经开始显示这个页面了，浏览器接收到返回的数据包，根据浏览器的渲染机制对相应的数据进行渲染。渲染后的数据，进行相应的页面呈现和脚步的交互。
第十一步：浏览器发送获取嵌入在HTML中的其他内容
比如一些样式文件，图片url，js文件url等，浏览器会通过这些url重新发送请求，请求过程依然是HTML读取类似的过程，查询域名，发送请求，重定向等。不过这些静态文件是可以缓存到浏览器中的，有时访问这些文件不需要通过服务器，直接从缓存中取。某些网站也会使用第三方CDN进行托管这些静态文件。
通过postman批量自动化接口测试 第一步 手动填写url 或者通过本机代理 获取批量的请求url 自动录入 第二步 填写断言
用来判定执行情况 第三步 填写body 报文内容 同时引入变量 用于自动化 第四步 导入csv文件 引入测试用例 实现自动化测试
等价类划分 分类 为了缩减用例个数 先分类 再在分类中找典型数据为代表进行测试。
先分有效和无效 再细分，建议先测试有效，再测试无效的。
边界值分析 边界 可能会混淆 边界不光是数字，可能不止一个。前端文本框有边界-宽度长度-协议-地址栏 -服务器--硬件软件string--数据库- varchar-65535
错误猜测法 直觉经验
决策表（判定表）分析法
?grant_type=client_credential&appid=APPID&secret=APPSECRET
？后面就是参数，grant_type参数名=client_credential参数值&是两个参数间间隔符。appid参数名=APPID参数值。
http协议是无状态的 但是随着技术的发展，我们有了维持状态的需求 为了维持状态，就诞生了cookie
cookie的缺点：1、有安全隐患；数据存储量有限 为了弥补cookie的缺陷，就诞生了session
session的数据是存储在服务器的，所有就解决了安全问题 服务器存储空间相对比较大 缺点：不方便服务器的横向扩展
为了解决session的问题，就诞生了token 用户第一次登陆服务器时，服务器会给该用户生成一个唯一的token
把token返回到客户端 客户端需要把token缓存起来 后续客户端所有的请求都携带该token
服务器接口到请求之后会验证token是否合法 如果token验证通过就返回正常数据，否则不给数据
缺点：服务器不容易控制token（有效期之内不太容易控制单独的token）
COOKIE 是什么 COOKIE 本身是由服务器产生的，生成之后发送给浏览器，并保存在浏览器 COOKIE
就是浏览器存储在本地目录的一小段文本 COOKIE 是以 key-value 形式存储的 COOKIE 有大小限制，为了保证
COOKIE 不占用太多的磁盘空间，每个 COOKIE 大小一般不超过 4KB COOKIE 默认在会话结束后直接销毁，此种
COOKIE 称之为会话 COOKIE COOKIE 可以设置过期时间，此种 COOKIE 称之为持久 COOKIE COOKIE
的不足 每个 COOKIE 的容量有限 因为 cookie 由浏览器存储在本地目录，所以不方便记录敏感信息，如密码等 cookie
不支持跨域访问 cookie 不支持手机端方案
什么是 SESSION SESSION 是由服务器产生的，存储在服务端 SESSION
的存储形式多种多样，可以是文档、数据库、缓存等，这需要靠进程如何设计 SESSION 也是以 key-value 形式存储的
SESSION 是没有大小限制的，这比 cookie 灵活很多，不过将过多的东西放在其中也并不是明智的做法 SESSION
也有过期时间的概念，默认为 30 分钟，可以通过 tomcat、web.xml 等方式进行配置 SESSION 可以主动通过
invalidate() 方法进行销毁 SESSION 通过 session_id 识别，如果请求持有正确的
session_id，则服务器认为此请求处于 session_id 代表的会话中 SESSION 的不足 SESSION
大小不限制，存储在服务端，本身是对资源的一种负担 如何保证 session 的高可用、准确性，优势对整体架构的一种负担
频繁的创建、查询、验证 session，会对服务器造成很大的压力 SESSION 是有状态的
什么是 TOKEN TOKEN 是一种轻量级的用户验证方式 TOKEN 是无状态的 TOKEN 允许跨域访问 TOKEN
是服务端生成的一个字符串，保存在客户端（可以放在 cookie 中），作为请求服务的验证令牌 TOKEN
无需存放在服务端，这样服务端无需存放用户信息 TOKEN 对服务端压力极小`，因为服务端只需存储秘钥，并支持生成 token
的算法，无需存储 token TOKEN 最简单的构造：用户唯一的身份标识 (辨识用户) + 时间戳 (用于过期校验) + 签名
(防止第三方恶意冒充) TOKEN 无法主动过期，只能等待它达到过期时间后才会失效 TOKEN
的产生：首次请求时，服务器对请求参数（如账号、密码）验证通过，则根据用户标识，加上服务的密钥，通过生成算法，生成 token TOKEN
的验证：再次请求时，携带此 token，则服务端再次根据用户标识，生成 token，根据两个 token
是否一致且未过期来判定用户是否已授权 TOKEN 的不足 TOKEN 无法主动过期，只能等待它达到过期时间后才会失效 TOKEN 本身比
session_id 要大，会消耗更多的流量与带宽
|