记录层与 TCP 段的关系
TLS 把应用数据切成记录（Record）发送，单条记录的明文字节上限是 2^14，也就是 16384 字节。记录边界与 TCP 段边界没有任何绑定：一条大记录会被拆进多个 TCP 段，一个 TCP 段里也可能塞着好几条小记录。所以做请求数统计、包长分析、重传定位之前，要先想清楚自己在数「记录」还是数「段」。
基本信息
| 单记录明文上限 | 16384 字节（2^14） |
|---|---|
| 关键字段 | tls.record.content_type、tls.record.length、tls.record.version |
| 与 TCP 关系 | 不对齐，一段可含多记录，一记录可跨多段 |
| 1.3 差异 | 长度字段含内部内容类型与 AEAD tag |
典型使用场景
- 判断服务端是否按固定块大小发送，评估分片与吞吐
- 排查大记录造成的队头阻塞与延迟抬升
- 区分 TLS 记录分片与 IP 分片：两者层级不同，处理手段不同
- 统计应用请求量时选对口径，避免按记录数误算
- 定位中间设备按记录切分或重组导致的吞吐下降
观察记录层
观察记录层
tshark -r t.pcap -Y "tls.record.content_type==23 && tls.record.length>16000" -T fields -e frame.number -e tls.record.length -e tls.record.version
# 应用数据大记录：1.3 略超 16384 属正常，明显超标才需要追
tshark -r t.pcap -Y "tcp.analysis.retransmission" -T fields -e frame.number
# 重传、乱序、拥塞窗口都在 TCP 层判断，记录层看不到字段逐项读法
| 字段 | 含义 | 注意 |
|---|---|---|
| tls.record.content_type | 20 变更密码规格、21 告警、22 握手、23 应用数据 | 只有 23 是业务数据 |
| tls.record.length | 该记录分片长度 | 1.3 含内部类型与 tag，可略大于 16384 |
| tls.record.version | 记录层版本 | 1.3 显示为 0x0303 |
| frame.len | 整帧长度 | 含以太/IP/TCP 头，不等于记录长度 |
TLS 1.3 的记录长度字段覆盖的是密文，即内部明文加 1 字节内部内容类型再加 AEAD tag。因此看到 16385 到 16401 之间属于正常范围，不要当异常上报。
不要用记录数估算 HTTP 请求数：一条连接可以流水线复用，一个请求也可能跨多条记录。统计请求应答请用应用层字段，例如 HTTP/2 的流 ID。
分析口径选择
- 数请求量：用应用层字段（HTTP 方法、HTTP/2 流 ID），不要数记录个数
- 看重传与乱序：用 tcp.analysis.retransmission 等 TCP 层字段，不要看记录
- 看吞吐：用 tcp.len 或记录长度之和，注意区分线路字节与有效载荷
- 看延迟：用 frame.time_delta 或响应首字节时间，记录边界只作辅助参考
- 看分片：先确认是 TLS 记录切分还是 IP 分片，再去看对应层的字段