前后端知识点笔记

关于Session与JWT令牌的不同点与选择方法

依据是否需要服务端保存状态来选择

✔ Session：服务端有状态（Stateful）

• 登录后，服务器存储用户信息（Session 对象）
• 客户端只保存 sessionId

核心特性：服务端必须记住用户信息。

带来的结果：

特性	影响
服务器要保存会话	多机/分布式部署麻烦（需要 Session 同步或 Redis）
Session 占内存	用户多时服务器负担大
服务端可主动使会话失效	安全性更高（可踢下线、可立即注销）

→ 因此 Session 更适合传统单体应用、内部系统、安全要求高的系统。

---

✔ JWT：服务端无状态（Stateless）

• 登录后，服务器不保存任何会话信息
• 用户信息全部写在 Token 内（并签名）
• 服务端只做签名校验，不记录用户状态

核心特性：服务端不需要存储任何用户状态。

带来的结果：

特性	影响
无需 Session 粘性	非常适合多机、微服务、前后端分离
服务端不存 Token	节省内存，扩展性强
Token 无法由服务端主动失效	安全性低于 Session（无法立即踢人）
Token 数据可被解码（Base64）	不适合存敏感信息

→ 因此 JWT 更适合分布式、前后端分离、移动端、小程序、微服务。

---

✔ 核心总结

Session 是 有状态认证（Stateful），需要服务器保存会话。
JWT 是 无状态认证（Stateless），服务器不保存任何会话信息。

使用场景的根本差异，就是由这两者在“是否需要服务器存储状态”上的特性不同导致的。

JWT 的三部分组成与防篡改原理

一、JWT 的三部分组成

JWT（JSON Web Token）由三段字符串组成，以 . 分隔：

Header.Payload.Signature

---

1. Header（头部）

说明签名算法与令牌类型，例如：

{
  "alg": "HS256",
  "typ": "JWT"
}

经过 Base64URL 编码后形成第一段。

---

2. Payload（载荷）

存放应用数据（Claims），例如：

{
  "sub": "userId123",
  "name": "Tom",
  "role": "admin",
  "exp": 1712345678
}

Payload 仅编码，不加密。

常见字段：

• iss：签发者
• exp：过期时间
• iat：签发时间
• sub：用户唯一标识

---

3. Signature（签名）

用于校验数据是否被篡改。

生成公式：

Signature = HMACSHA256(
  Base64UrlEncode(Header) + "." + Base64UrlEncode(Payload),
  secret_key
)

secret_key 由服务端保存。

---

JWT 的防篡改原理

1. Header 与 Payload 可见，但 Signature 不能伪造

攻击者可解码前两段，但无法生成正确的签名。

---

2. 无法生成有效签名的原因

服务端生成签名需要：

HMACSHA256(data, secret_key)

攻击者没有 secret_key，所以无法伪造。

---

3. 服务端验证原理

服务器收到 JWT 后，会重新计算签名：

server_signature = HMACSHA256(header.payload, secret_key)

若与 JWT 中的签名一致，则未被修改；否则拒绝。

---

三、一句话总结

JWT 的防篡改依赖签名校验：前两段可见，但没有密钥就无法生成正确的签名，因此篡改会被服务器识别。

数据库的隔离级别（事务的隔离级别）

并发异常类型	现象描述	解决方法（隔离级别）	隔离级别中文说明	说明
脏读 (Dirty Read)	一个事务读取到另一个未提交事务修改的数据	READ COMMITTED	读已提交	防止读取到未提交数据（行锁，读不上锁）
不可重复读 (Non-Repeatable Read)	同一事务中，重复读取同一条记录结果不同	REPEATABLE READ	可重复读	防止中途被其他事务修改（行锁，读也加锁）
幻影读 (Phantom Read)	同一事务中，重复查询得到新增或删除的记录	SERIALIZABLE	串行化	防止中途被其他事务新增/删除数据（表锁）
现在大多数据库都有一个默认的隔离级别。如MySQL默认是重复读

实时视频帧转发

方式 A：前端用 canvas/MediaStream 采集成 图片帧（JPEG/PNG）

• 优点：实现简单

• 缺点：带宽大、延迟高

方式 B：用 WebRTC 传视频（更专业）

• 优点：实时性好、带宽低

• 缺点：比 WebSocket 复杂（需要信令、STUN/TURN）

WebRTC 的工作流程（简单版）

1. A 获取摄像头/麦克风

2. A 创建 PeerConnection

3. A 生成 offer（提议）

4. A 通过信令服务器发给 B

5. B 接收 offer 生成 answer（回应）

6. B 也通过信令服务器发给 A

7. 双方交换 ICE 候选（解决 NAT 穿透）

8. 建立 P2P 连接

9. 音视频/数据开始传输