接口相关知识点汇总

学习笔记
1

一、http与https的区别

1、HTTP 与 HTTPS 的概念

  • HTTP
    • 超文本传输协议
    • 是一个基于请求与响应，无状态的，应用层的协议
    • 常基于 TCP/IP 协议传输数据
    • 以明文方式发送内容
  • HTTPS
    • 安全套接字层超文本传输协议
    • 通过计算机网络进行安全通信的传输协议
    • 在 HTTP 的基础上加入了 SSL/TLS 协议
    • HTTP + 加密 + 认证 + 完整性保护 = HTTPS

image

image
image1183×758 65.7 KB

2、HTTP 与 HTTPS 的区别

  1. HTTPS 比 HTTP 更安全
  • HTTP 是超文本传输协议，连接简单无状态，信息明文传输
  • HTTPS 通过 SSL/TLS 提供安全方式
  1. HTTP 和 HTTPS 使用完全不同的连接方式
  2. HTTP 和 HTTPS 用的端口也不一样
  • HTTP 是 80 端口
  • HTTPS 是 443 端口
  1. HTTPS 协议需要到 CA 申请证书，可能需要一定费用

二、get、post区别

1、区别

GET POST
请求资源 从指定的资源请求数据 向指定的资源提交要被处理的数据
可见性 数据在 URL 中对所有可见 数据不会显示在 URL 中
安全性 安全性差 安全性好
对数据类型的限制 只允许 ASCII 字符 没有限制也允许二进制数据
长度限制 长度受浏览器限制 无限制
参数 保留在浏览器 参数不会保存在浏览器
编码类型 application/x-www-form-urlencoded application/x-www-form-urlencoded or multipart/form-data。为二进制数据使用多重编码。
缓存 能被缓存 不能缓存
书签 可被保存 不可收藏为书签
后退按钮/刷新 不影响 数据会被重新提交（浏览器应该告知用户数据会被重新提交）。

image
image819×507 32.9 KB

2、总结：GET 与 POST 的区别

  • HTTP 的 method 字段不同
  • POST 可以附加 body，可以支持 form、json、xml、binary 等各种数据格式
  • 行业通用的规范
    • 无状态变化的建议使用 GET 请求
    • 数据的写入与状态修改建议用 POST
  • 传送数据量不同
  • 安全性不同

三、session、cookie、token的区别

1、 Session Cookie Token 区别

  • Session：数据存储到服务端，只把关联数据的一个加密串放到 Cookie 中标记
  • Cookie：浏览器接受服务器的 Set-Cookie 指令，并把 cookie 保存到电脑上，每个网站保存的 cookie 只作用于自己的网站
  • Token：是一个用户请求时附带的请求字段，用于验证身份与权限

2、 Session 实现机制

  • 服务器创建 Session 出来后，会把 Session id，以 Cookie 的形式回写给客户端 浏览器，这样，只要客户端的浏览器不关，再去访问服务器时，都会带着 Session id ，服务器发现客户机浏览器带 Session id 过来了，就会使用内存中与之对应的 Session 为之服务。(Session 会存在服务器)

image
image1280×377 44.3 KB

3、 cookie 实现机制

  • Cookie 通过在客户端记录信息确定用户身份，
  • Cookie 由服务器生成，发送给浏览器，浏览器把 Cookie 以 kv 形式保存到某个目录下的文本文件内，下一次请求同一网站时会把该 Cookie 发送给服务器。

image
image1301×388 38.5 KB

4、 Token 的原理

  • 基于 Token 的身份验证是无状态的，我们不将用户信息存在服务器或 Session 中。这解决了在服务端存储信息时的许多问题 NoSession 意味着你的程序可以根据需要去增减机器，而不用去担心用户是否登录。
  • 基于 Token 的身份验证的过程如下:
    • 用户发送数据请求
    • 程序验证
    • 程序返回一个签名的 token 给客户端
    • 客户端储存 token，并且每次用于每次发送请求。
    • 服务端验证 token 并返回数据。
  • token 通常在 HTTP 的头部发送给服务端

5、 Session,Cookie,Token 的工作原理

Cookie Session Token
存储位置 客户端 服务器 客户端
安全性 较差 较高 相对最高
占用服务器资源 占用服务器资源消耗少 当访问多时消耗服务器的资源 不占用服务器资源
作用 记录用户状态，辩认身份（传话管理，个性化，追踪） 同cookie 减轻服务端查询数据库的压力，提供授权和认证功能
优点 易于使用和实现，不需要服务器资源，透明性，持久性 信息非常的安全,都是存储在服务器端的 无状态，可扩展和解耦，更好的跨域（跨域资源共享）
缺点 安全性差 服务器压力大，，扩展性不强，分布式，跨系统实现困难 最小的token也比cookie更大，占带宽，性能问题（需要验证两次），无法在服务端注销，很难解决劫持问题
适用范围 在线定货系统、网站个人化和网站跟踪 session 更适用于客户端代码和服务端代码运行在同一台服务器上 token 更适用于项目级的前后端分离（前后端代码运行在不同的服务器下）

四、tcp三次握手与四次挥手

1、 TCP 报文

  • 序号:占4个字节，表示发送的数据字节流
  • 确认号:占4个字节，发送方期待接收的下一序列号，只有 ACK=1 时才有效
  • ACK：确认序号的标志，ACK=1 表示确认号有效，ACK=0 表示报文不含确认序号信息
  • SYN：连接请求序号标志，用于建立连接，SYN=1 表示请求连接
  • FIN：结束标志，用于释放连接，为1表示关闭本方数据流

image
image1075×673 91.6 KB

2、 三次握手

  • 首先 Client 端发送连接请求报文
  • Server 端接受连接后回复 ACK 报文，并为这次连接分配资源
  • Client 端接收到 ACK 报文后也向 Server 段发生 ACK 报文，并分配资源

image

3、 四次挥手

  • 假设 Client 端发起中断连接请求，也就是发送 FIN 报文。
  • Server 端接到 FIN 报文后，先发送 ACK，这个时候 Client 端就进入 FIN_WAIT 状态，继续等待 Server 端的 FIN 报文。
  • 当 Server 端确定数据已发送完成，则向 Client 端发送 FIN 报文
  • Client 端收到 FIN 报文后, 发送 ACK 后进入 TIME_WAIT 状态，如果 Server 端没有收到 ACK 则可以重传。Client 端等待了 2MSL 后依然没有收到回复，则证明 Server 端已正常关闭
  • Client 端关闭连接

image

4、 tcp 三次握手与四次挥手

  • 三次握手
    • 首先 Client 端发送连接请求报文
    • Server 段接受连接后回复 ACK 报文，并为这次连接分配资源
    • Client 端接收到 ACK 报文后也向 Server 段发生 ACK 报文，并分配资源
  • 四次挥手
    • Client 端发起中断连接请求(发送 FIN 报文)
    • Server 端接到 FIN 报文后，先发送 ACK，Client 端进入 FIN_WAIT 状态，继续等待 Server 端的 FIN 报文。
    • 当 Server 端确定数据已发送完成，则向 Client 端发送 FIN 报文
    • Client 端收到 FIN 报文后, 发送 ACK 后进入 TIME_WAIT 状态，如果 Server 端没有收到 ACK 则可以重传。Client 端等待了 2MSL 后依然没有收到回复，则证明 Server 端已正常关闭
    • Client 端关闭连接

五、tcp与udp的区别

1、 TCP 与 UDP 的区别

  • TCP：面向连接、错误重传、拥塞控制，适用于可靠性高的场景
  • UDP：不需要提前建立连接，实现简单，适用于实时性高的场景

2、 UDP 无连接，TCP 面向连接

  • 使用 UDP 不需要提前建立连接
  • 使用 TCP 协议的双方在发送数据之前必须使用
  • UDP 支持一对一，一对多，一对全的通信
  • TCP 仅支持一对一

3、 TCP 和 UDP 对报文的处理

  • UDP 是面向报文的
  • TCP 面向字节流

image
image897×615 24.8 KB

4、 传输方式

  • UDP 是无连接的不可靠的传输
  • TCP 是有连接的可靠传输

5、 数据报首部

  • UDP 首部是 4 个字段，每个字段两个字节，共 8 个字节
  • TCP 首部最小长度为 20 字节，最大长度为 60 字节

image

image

6、 TCP 与 UDP 区别总结

UDP TCP
是否需要建立连接 否 是
通信方式 一对一，一对多，多对一，多对多交互通信 每条 TCP 连接只能有两个端点，只能是一对一通信
对报文的处理 对应用层交付的报文直接打包 面向字节流
传输是否可靠 不可靠，不进行流量控制和拥塞控制 可靠传输，使用流量控制和拥塞控制
首部对比 仅 8 个字节 最小 20 个字节，最大 60 个字节

六、消息队列测试场景

1、 什么是消息队列

  • Broker：消息服务器，提供消息核心服务
  • Producer：消息生产者，业务的发起方，负责生产消息传输给 broker。
  • Consumer：消息消费者，业务的处理方，负责从 broker 获取消息并进行业务逻辑处理。

image

2、 消息队列的应用场景

  • 异步通信
  • 流量削峰
  • 应用解耦
  • 负载均衡
  • 数据同步

3、 消息队列的测试点

所属类型 注意点 测试点
生产者 时序 不同时序推送消息，先后顺序是否和预期一致
数据正确性 内容是否完整
内容是否满足需求
推送 推送失败是否有重试
消费者 正确性 正常消费信息
消息被消费后是否清除
消费者接收到的信息和生产者一致
消费者堵塞，如何处理。
幂等（接收到重复消息）

七、redis测试场景

1、 Redis 简介

  • 读写性能优异。
  • 数据类型丰富。
  • Redis 支持数据的备份。
  • 数据自动过期。
  • 发布订阅。
  • 分布式。

2、 Redis 的应用场景

  • 应用场景主要包含：
    • 读多写少，并发强的场景。
    • 有时间性的业务场景。
    • 对有序集合数据类型排序。
    • 对于时效性要求不高。
    • Session 会话缓存。
    • 消息系统。
    • 单线程的特点可以天然用作分布式锁。

3、 Redis 的查询流程

没有redis的情况下

image

有redis的情况下

image

4、 淘汰缓存与更新缓存

（1） 缓存操作流程-读

  • 缓存中有数据。
  • 缓存中没有数据。

image

（2） 缓存操作流程-写（淘汰缓存）

  • 优点： 操作简单，性能比较好。
  • 缺点：至少会出现一个 cache miss。

image
image908×648 69 KB

（3） 缓存操作流程-写（更新缓存）

  • 优点： 基本不会出现cache miss的情况。
  • 缺点： 每次更新数据库都更新缓存，比较影响性能。

image
image1244×972 126 KB

（4） 淘汰缓存与更新缓存区别

  • 视应用场景而定。
  • 通常会使用淘汰缓存。
类型 性能 cache miss
淘汰缓存 较好 会出现
更新缓存 较差 基本不会出现

5、 Redis 缓存失效

  • 缓存不可用之后，大量并发到数据库。

image

6、 为什么会产生缓存失效

  • 缓存过期。
  • Redis 异常。
  • 网络异常。
  • 缓存更新

7、 缓存更新导致失效场景

image
image1022×828 84.8 KB

image
image920×798 80.2 KB

8、 缓存失效的解决方案

  • 降级： 禁用部分接口，开放核心接口。
  • 熔断： 禁用部分服务，开放核心服务。

9、 缓存失效相关测试方法

  • 梳理系统中的核心服务列表（通常直接让研发给出对应列表）。
  • 梳理服务中核心接口列表（通常直接让研发给出对应列表）。
  • 模拟 Redis 失效，验证核心服务和核心接口是否还能正常运行。

10、 Redis 击穿、穿透区别

（1） 击穿

image

（2） 击穿的场景的测试用例步骤

  • 获取热 key 的列表（与运维沟通后获取）。
  • 模拟热 key 失效的场景（比如登陆 Redis，直接将热 key 删除）。
  • 查看研发是否有对应的容错机制，保证服务正常运行。

（3） 穿透-正常查询场景

image
image1410×852 109 KB

（4） 穿透-缓存穿透的场景

image
image1506×948 139 KB

（5） 穿透的场景的测试用例步骤

  • 不停访问对应服务的接口，传递一个不存在的数据的查询请求（并发查询）。
  • 查看研发是否有对应的容错机制，保证服务正常运行。

（6） 击穿与穿透总结

类型 穿透 击穿
测试目标 查看研发是否有对应的容错机制，保证服务正常运行。 查看研发是否有对应的容错机制，保证服务正常运行。
测试方法 不停访问对应服务的接口，传递一个不存在的数据的查询请求。 模拟热 key 失效的场景（比如登陆 Redis，直接将热 key 删除）。
2 个赞