摘要

  • 第 03 版仍是活跃的 Internet-Draft，不是 RFC，也不是实现、部署或互操作性的证据。
  • 扩展让每一端分别声明愿意接收的最大内部明文；它是方向性上限，不是内存预留，也不是要求对端发到最大。
  • 一条记录可以只是应用消息的一部分，传输分段、上层重组和最终处理都有自己的边界。
  • 大记录改变 AEAD 使用量的计算基础，调整上限时必须重新核算密钥生命周期。

记录层只交付自己的事实

TLS 1.3 与 DTLS 1.3 通常把内部明文限制在 2^14 + 1 字节。large_record_size_limit 草案允许端点声明更大的接收值，有效范围从 64 到 2^30 - 256。这个数回答的是：对端最多可以向我发送多大的内部明文记录。

它没有回答应用消息是否完整。一个消息可以跨越多条 TLS 记录；一条记录也可以装入上层协议后来会分别处理的数据。TCP 或其他传输层还可能把同一条大记录拆进许多网络分段。记录数减少，不等于包数、消息数或业务步骤按同样比例减少。

因此，监控必须沿着证据链前进：上限已声明、发送端选择了某个尺寸、记录被接收并认证、上层重组完成、应用解析并授权、服务结果出现。任何前一步都不能代替后一步。

两个方向有两份承诺

这个扩展不是协商一个双方共享的最大值。客户端声明自己愿意从服务器接收多少，服务器声明自己愿意从客户端接收多少。两个值可以不同，而且并不冲突。

端点发送的记录甚至可以大于它为自身接收方向声明的值，只要不超过对端的接收上限。若仪表板只保存一个“TLS 记录上限”，它会丢掉判断合规所必需的方向，可能把合法发送标成越界，也可能把真实越界藏在另一个方向的较大数字之下。

最小事件应保存连接、端点角色、方向、本地策略、发出的声明、收到的声明以及实际认证的内部明文长度。方向不是展示标签，而是数值的法律主体。

上限不是发送目标

接收端给出的是允许值，不是订单。发送端仍可根据时延、批处理、拥塞、内存和应用节奏选择更小的记录。把较高上限当成“应尽量填满”的目标，会让优化器为了减少头部而推迟交付交互性数据。

草案的动机之一是减少重复的记录头与 AEAD 开销，并在某些大消息 DTLS 用途中避免上层碎片。但它提供的是更大的可选封装单位，不是通用性能结论。批量传输、控制流与实时交互可能需要不同的尺寸策略。

有效值也有硬边界。低于 64 或高于 2^30 - 256 的扩展值会触发致命 illegal_parameter。这证明协商值无效，不授权实现自行猜测一个替代值继续握手。

内存承诺来自平台，不来自握手

声明能够接收大记录，不代表实现已经为每条连接预留等量连续内存。库可以流式处理、共享缓冲池、应用全局配额或背压。反过来，单连接成功接收一次最大记录，也不能证明大量慢速连接同时占用未完成记录时仍然安全。

容量模型要覆盖密文缓存、AEAD 状态、明文保留、padding、上层重组、取消任务和队列驻留。真正危险的往往不是一条最大记录，而是许多记录都只到一半，长期占着资源却尚不能认证完成。

协议最大值只是语法边界，不是生产默认值。部署上限必须来自工作负载、分配器、调度器、并发假设与过载策略，并用压力测试给出证据。

看不见的 padding 也占额度

TLS 1.3 的内部明文包括内容类型，也可能包含 padding。接近上限的应用载荷加上 padding 后可能成为超限记录。只统计“有用数据”会漏掉真正受协议约束、也真正消耗内存与加密工作的字节。

这要求隐私策略、应用切块与 TLS 策略共享同一套计量定义。日志不应保存敏感内容，但必须保存完整长度、padding 策略版本与方向。密文长度、内部明文长度和应用载荷长度也不能混成一个字段。

同样，网络分段与记录边界不同。一个大 TLS 记录仍可能跨越很多 TCP 段。减少记录头部不证明减少网络包，也不证明降低拥塞或重传成本。

TLS 与 DTLS 的越界结果不同

TLS 接收到超过适用上限的记录时，草案要求致命 record_overflow，连接结束。对长连接而言，策略不一致可能直接成为可用性事件。

DTLS 面对超大数据报时，草案提出应该丢弃，并且不应该发送致命告警。数据报模型本来允许丢失；对未经充分验证的输入作出致命响应，还可能放大拒绝服务风险。

所以统一的“超限必须告警”控制并不正确。监控必须先区分协议，再记录 epoch、方向、观察尺寸、适用上限、采取的动作和可能的告警。DTLS 没有致命告警可能是合规行为，而 TLS 没有则需要调查。

更少头部可能换来更晚认证

应用通常要等整条记录通过认证，才能把其中明文当作可信输入。记录越大，从首字节到完整认证的间隔可能越长。在干净、高带宽链路上，头部节省可能占优势；在丢包、弱网、交互业务或紧张队列中，等待与重传成本可能更重要。

草案没有承诺时延下降。运营方应测量认证完成时间、队列驻留、每连接占用、并发半记录数量、控制消息是否被大记录阻挡，以及最终应用时延。平均值也不够，尾部延迟可能在吞吐提升时恶化。

因此，上限可以统一协商，发送策略却应按业务类别分层。大批量数据可以偏向效率；交互控制需要更早刷新；DTLS 大消息还要考虑丢失与重传模型。

密钥预算看的是工作量

AEAD 安全界限依赖具体构造、调用次数与处理数据量。对 AES-GCM，受保护块数尤其重要。草案说明，当记录尺寸超过传统范围时，需要按与 LargeRecordSizeLimit / 2^14 有关的因子调整使用量，并在适用处进行更具体的块计数。

若团队提高上限，却继续使用只按记录数设定的旧 KeyUpdate 阈值，控制面看到的数字可能稳定，实际加密预算却已经改变。应记录密码套件、方向、密钥 epoch、认证字节或保守块计数、记录数和轮换事件。

这不是说大记录天然不安全，而是说安全证明必须与实际允许的封装大小一致。成功握手不会替运营方核算密钥寿命。

分阶段上线保留回退能力

生产环境不应把草案最大值直接当默认值。先按端点与工作负载选择较小上限，在慢发送、大并发、最大 padding、丢包与取消场景中测量，再根据证据上调。TLS 与 DTLS、客户端与服务器方向都要分别验证。

回退也不是把配置数字改小就完成。新的声明只影响新协商，既有连接的状态不会被自动重写。计划需要处理连接排空、兼容路径、密钥策略和如何区分“不支持扩展”与“本地禁用”。

最终看板应呈现多张收据，而不是一个绿色状态：配置值、方向性声明、对端接受、实际尺寸、认证结果、资源曲线、重组结果和应用结果。这样才能评估头部节省，而不让它冒充业务收益。

资料与边界

冻结资料包括第 03 版及其官方记录、历史与引用；TLS 工作组；TLS 1.3 及其修订草案；DTLS 1.3；已有记录尺寸扩展；DTLS/SCTP、MLS、QUIC、AEAD 要求、AES-GCM 套件与 IANA TLS 注册表。

这些资料只确立协议与注册文本，不证明任何实现已发布、部署采用、互操作、吞吐提升、内存节省、时延降低、故障、攻击或应用结果。开篇场景是用于检验证据链的构造案例。

来源