struct {
ContentType type; // 1字节，内容类型
ProtocolVersion version; // 2字节，TLS版本号
uint16 length; // 2字节，负载长度
opaque fragment[TLSPlaintext.length]; // 负载数据
} TLSPlaintext;
**一个值得注意的事**：TLS 1.3 里记录层的 version 字段固定为 0x0303（TLS 1.2），但实际协商版本用扩展字段指示。这是因为记录层的 version 在加密之前就已经确定了，没法动态改变。设计上是有意为之。
### 记录层的报警机制
报警消息（ContentType = 21）是记录层的重要反馈手段。比如你抓包看到 TLS 连接突然中断，多半是报警记录先来了。
常见的报警类型分两类：
- **严重报警（fatal）**：接收端收到后必须立刻关闭连接，比如 bad_record_mac、handshake_failure、protocol_version 等。
- **警告报警（warning）**：只是提示，连接还可继续。比如 close_notify（通知对方我要正常关闭）、no_certificate（客户端没证书）等。但实践中大部分实现会把 warning 也当 fatal 处理——安全起见嘛。
我在生产排障时经常看报警码来定位错误。比如：
- `alert 21 = decrypt_error`：通常发生在密码套件不匹配、密钥解密出错
- `alert 42 = bad_certificate`：证书验证失败，我要接着看 Certificate 消息的签名和链
### 记录层内部的交互关系
我来画一张整个记录层协议的核心流程，更直观一些：
我画这个图的时候特意把加密阶段标红了，它是最容易出错的地方。MAC 计算错误、序列号不一致、或者密码套件选用错误的算法，都会导致解密失败。我在现场经常这样排查：先看记录头是否正常，再看解密过程报什么错——绝大多数问题就出在这两个地方。
### 记录层的超时与重传
记录层虽然不负责丢包重传（那是 TCP 的事），但它会在握手阶段管理超时。比如握手消息的发送方会启动一个定时器，如果超时还没收到应答就重发上一次握手消息。有些实现还会动态调整重试间隔。
**小技巧**：如果你在抓包文件里看到大量重复的 TLS 握手消息（比如相同序列号的 ClientHello），那很可能是对方超时重传了。这时候优先排查网络延迟，而不是证书或密码套件。
### 记录层的常见错误与日志标识
我们最后整理一下你会在日志里看到的记录层相关错误，我都是从实际排障中提炼出来的：
| 日志标识 | 含义 | 典型原因 |
|----------|------|----------|
| `bad_record_mac` | MAC 校验失败 | 加密密钥不匹配、数据被篡改、序列号回绕 |
| `decrypt_error` | 解密失败 | 密钥无法解出数据、padding 格式错误 |
| `record_overflow` | 记录长度超限 | 负载长度 > 16384 |
| `unexpected_message` | 消息类型不对 | 比如握手没完成就收到应用数据 |
| `protocol_version` | 版本不兼容 | 客户端与服务端 TLS 版本不一致 |
**特别注意**：`bad_record_mac` 也常由密码套件协商不一致引起，比如客户端想用 AES-GCM，服务端却用 RC4，中间某个代理转发了不对的密钥。排查时最好对比两端协商的 cipher suite 是否一致。
我习惯把所有跟记录层相关的错误归类到“封装与校验异常”这个大目录下。如果你日志中出现这些关键词，优先检查：
1. 抓包确认记录头的 content_type 和 version 是否在预期范围内
2. 确认密码套件两端是否一致（尤其是中间件）
3. 确认 sequence number 是否连续且没有重置（比如重启后忘记重置计数器）
嗯，到这里，记录层协议的核心就讲清楚了。你理解了这个容器，后续看握手层、证书验证这些就好办多了。