一，http和https的区别
1，了解概念
- HTTP
- 超文本传输协议
- 是一个基于请求与响应，无状态的，应用层的协议
- 常基于 TCP/IP 协议传输数据
- 以明文方式发送内容
- HTTPS
- 安全套接字层超文本传输协议
- 通过计算机网络进行安全通信的传输协议
- 在 HTTP 的基础上加入了 SSL/TLS 协议
HTTP + 加密 + 认证 + 完整性保护 = HTTPS
2，通信过程
3，回答
- HTTPS 比 HTTP 更安全
- HTTP 是超文本传输协议，连接简单无状态，信息明文传输
- HTTPS 通过 SSL/TLS 提供安全方式
- HTTP 和 HTTPS 使用完全不同的连接方式
- HTTP 和 HTTPS 用的端口也不一样
- HTTP 是 80 端口
- HTTPS 是 443 端口
- HTTPS 协议需要到 CA 申请证书，可能需要一定费用
二，get和post的区别
| GET | POST | |
|---|---|---|
| 请求资源 | 从指定的资源请求数据 | 向指定的资源提交要被处理的数据 |
| 可见性 | 数据在 URL 中对所有可见 | 数据不会显示在 URL 中 |
| 安全性 | 安全性差 | 安全性好 |
| 对数据类型的限制 | 只允许 ASCII 字符 | 没有限制也允许二进制数据 |
| 长度限制 | 长度受浏览器限制 | 无限制 |
| 参数 | 保留在浏览器 | 参数不会保存在浏览器 |
| 编码类型 | application/x-www-form-urlencoded | application/x-www-form-urlencoded or multipart/form-data。为二进制数据使用多重编码。 |
| 缓存 | 能被缓存 | 不能缓存 |
| 书签 | 可被保存 | 不可收藏为书签 |
| 后退按钮/刷新 | 不影响 | 数据会被重新提交（浏览器应该告知用户数据会被重新提交）。 |
回答：
- HTTP 的 method 字段不同
- POST 可以附加 body，可以支持 form、json、xml、binary 等各种数据格式
- 行业通用的规范
- 无状态变化的建议使用 GET 请求
- 数据的写入与状态修改建议用 POST
- 传送数据量不同
- 安全性不同
三，session、cookie、token的区别
- Session：数据存储到服务端，只把关联数据的一个加密串放到 Cookie 中标记
- Cookie：浏览器接受服务器的 Set-Cookie 指令，并把 cookie 保存到电脑上，每个网站保存的 cookie 只作用于自己的网站
- Token：是一个用户请求时附带的请求字段，用于验证身份与权限
Session 实现机制
- 服务器创建 Session 出来后，会把 Session id，以 Cookie 的形式回写给客户端 浏览器，这样，只要客户端的浏览器不关，再去访问服务器时，都会带着 Session id ，服务器发现客户机浏览器带 Session id 过来了，就会使用内存中与之对应的 Session 为之服务。(Session 会存在服务器)
cookie 实现机制
- Cookie 通过在客户端记录信息确定用户身份
- Cookie 由服务器生成，发送给浏览器，浏览器把 Cookie 以 kv 形式保存到某个目录下的文本文件内，下一次请求同一网站时会把该 Cookie 发送给服务器。
Token 的原理
- 基于 Token 的身份验证是无状态的，我们不将用户信息存在服务器或 Session 中。这解决了在服务端存储信息时的许多问题 NoSession 意味着你的程序可以根据需要去增减机器，而不用去担心用户是否登录。
- 基于 Token 的身份验证的过程如下:
- 用户发送数据请求
- 程序验证
- 程序返回一个签名的 token 给客户端
- 客户端储存 token，并且每次用于每次发送请求。
- 服务端验证 token 并返回数据。
- token 通常在 HTTP 的头部发送给服务端
session、cookie、token的区别
| Cookie | Session | Token | |
|---|---|---|---|
| 存储位置 | 客户端 | 服务器 | 客户端 |
| 安全性 | 较差 | 较高 | 相对最高 |
| 占用服务器资源 | 占用服务器资源消耗少 | 当访问多时消耗服务器的资源 | 不占用服务器资源 |
| 作用 | 记录用户状态，辩认身份（传话管理，个性化，追踪） | 同cookie | 减轻服务端查询数据库的压力，提供授权和认证功能 |
| 优点 | 易于使用和实现，不需要服务器资源，透明性，持久性 | 信息非常的安全,都是存储在服务器端的 | 无状态，可扩展和解耦，更好的跨域（跨域资源共享） |
| 缺点 | 安全性差 | 服务器压力大，，扩展性不强，分布式，跨系统实现困难 | 最小的token也比cookie更大，占带宽，性能问题（需要验证两次），无法在服务端注销，很难解决劫持问题 |
| 适用范围 | 在线定货系统、网站个人化和网站跟踪 | session 更适用于客户端代码和服务端代码运行在同一台服务器上 | token 更适用于项目级的前后端分离（前后端代码运行在不同的服务器下） |
四，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报文详解
- 序号:占4个字节，表示发送的数据字节流
- 确认号:占4个字节，发送方期待接收的下一序列号，只有 ACK=1 时才有效
- ACK：确认序号的标志，ACK=1 表示确认号有效，ACK=0 表示报文不含确认序号信息
- SYN：连接请求序号标志，用于建立连接，SYN=1 表示请求连接
- FIN：结束标志，用于释放连接，为1表示关闭本方数据流
五，tcp与udp的区别
- TCP：面向连接、错误重传、拥塞控制，适用于可靠性高的场景
- UDP：不需要提前建立连接，实现简单，适用于实时性高的场景
连接方式
- UDP 是无连接的不可靠的传输，不进行流量控制和拥塞控制
- TCP 是有连接的可靠传输，使用流量控制和拥塞控制
通信方式
- UDP 支持一对一，一对多，多对多的通信
- TCP 仅支持一对一
对报文的处理
- UDP 是面向报文的（对应用层交付的报文直接打包）
- TCP 面向字节流
数据报首部
- UDP 首部是 4 个字段，每个字段两个字节，共 8 个字节
- TCP 首部最小长度为 20 字节，最大长度为 60 字节
六，消息队列测试场景
消息队列
- Broker：消息服务器，提供消息核心服务
- Producer：消息生产者，业务的发起方，负责生产消息传输给 broker。
- Consumer：消息消费者，业务的处理方，负责从 broker 获取消息并进行业务逻辑处理。
应用场景
- 异步通信
- 流量削峰
- 应用解耦
- 负载均衡
- 数据同步
消息队列的测试点
- 生产者：
- 时序：不同时序推送消息，先后顺序是否和预期一致
- 数据正确性： 内容是否完整；内容是否满足需求
- 推送：推送失败是否有重试
- 消费者：
- 是否正常消费信息
- 消息被消费后是否清除
- 消费者接收到的信息和生产者一致
- 消费者堵塞，如何处理。
- 幂等（接收到重复消息）
七，redis测试场景
redis简介
- 读写性能优异。
- 数据类型丰富。
- Redis 支持数据的备份。
- 数据自动过期。
- 发布订阅。
- 分布式。
应用场景
- 主要包含：
- 读多写少，并发强的场景。
- 有时间性的业务场景。
- 对有序集合数据类型排序。
- 对于时效性要求不高。
- Session 会话缓存。
- 消息系统。
- 单线程的特点可以天然用作分布式锁。
面试题
1，你们的 Redis 使用的是淘汰缓存还是更新缓存，这两者有什么区别？请详细说明。
-
淘汰缓存
- 优点： 操作简单，性能比较好。
- 缺点：至少会出现一个 cache miss。
-
更新缓存
- 优点： 基本不会出现cache miss的情况。
- 缺点： 每次更新数据库都更新缓存，比较影响性能。
2，怎么定位 Redis 缓存失效问题（缓存坏了）？
-
缓存失效：缓存不可用之后，大量并发到数据库。
-
缓存失效原因：
- 缓存过期。
- Redis 异常。
- 网络异常。
- 缓存更新
-
缓存失效场景：
-
缓存失效的解决方案
- 降级： 禁用部分接口，开放核心接口。
- 熔断： 禁用部分服务，开放核心服务。
-
缓存失效相关测试方法
-
- 梳理系统中的核心服务列表（通常直接让研发给出对应列表）。
-
- 梳理服务中核心接口列表（通常直接让研发给出对应列表）。
-
- 模拟 Redis 失效，验证核心服务和核心接口是否还能正常运行。
-
3，Redis 击穿、穿透区别，如何设计用例以及完成测试？
-
缓存击穿场景
-
击穿场景的测试用例步骤
-
- 获取热 key 的列表（与运维沟通后获取）。
-
- 模拟热 key 失效的场景（比如登陆 Redis，直接将热 key 删除）。
-
- 查看研发是否有对应的容错机制，保证服务正常运行。
-
-
缓存穿透场景
-
穿透场景的测试用例步骤
-
- 不停访问对应服务的接口，传递一个不存在的数据的查询请求。
-
- 查看研发是否有对应的容错机制，保证服务正常运行。
-
