原理
TLS 协议由两层协议组成：TLS 握手协议和 TLS 记录协议（TLS Record），TLS Record 协议在 TLS 握手协议之下。下面是 SSL/TLS 的分层结构：
所有的 TLS 上层数据（包含 TLS 握手协议消息以及更上层的应用协议数据）都由 TLS Record 来封装和传输。下面是 TLS Record 协议的消息封装流程：
一个消息会在 TLS Record 协议层被分段，然后对每个分段分别压缩（已废弃）和加密，最后加上 TLS Record 协议头再通过网络层发送出去，在 Wireshark 中可以看到：
可以看出 TLS/SSL 数据加解密是基于分段的，接收方收到一个完整的分段就可以解密，如果分段过大，那接收方必须要等到接收完整个分段的数据才能解密，当网络不好出现丢包、拥塞、重传等等情况下会严重影响时延，如果分段过小，头部负载比重就会较大，影响吞吐率。所以，怎么分段就比较关键，也就是 TLS Record Size 大小多少合适。这就涉及到两个重要的指标：时延和吞吐率。
- 如果 TLS Record Size 设置较大
假如超过了 MTU，一个分段会被 TCP 层再次分段，拆分成多个包发送，那么时延也相应地增大，但由于记录协议头占比很小，吞吐率也增大。- 如果 TLS Record Size 设置较小
一个分段在 TCP 层没有被再次分段，由一个包发送出去，时延会比较小，但吞吐率也会下降。
所以，对时延敏感的域名，TLS Record Size 建议设置为略小于 MTU 的大小（粗算：MTU - TLS Record Header Length - TCP Header Length - IP Header Length）。对吞吐率敏感的域名，TLS Record Size 建议设置为 16k（上限）。如果同时兼顾时延和吞吐率的话，建议设置为 8k （经验值）。
但是，TCP 有拥塞控制机制，在 TCP 连接刚开始的慢启动阶段，拥塞窗口会比较小，这时较大的 TLS Record Size 会导致 TLS Record 片段被 TCP 分成多个包来发送，从而导致时延较大，可能就会影响网页的首屏时间。在整个 TCP 数据传输过程中，可能启动拥塞避免算法，也可能遇到数据丢失和重传的情况，然后又重新进入慢启动阶段。
因此，更好的做法是动态调整 TLS Record Size 的大小，而不是使用固定的值。在 TCP 连接初期使用较小的值，等传输速度上来之后再使用更大的值。
实现
nginx 本身支持 TLS Record Size 配置，但不支持动态调整，Cloudflare 实现了该功能(patch)。其算法原理是：
# 关键配置
ssl_dyn_rec_enable on;
ssl_dyn_rec_size_lo 1369;
ssl_dyn_rec_size_hi 4229;
ssl_dyn_rec_threshold 40;
ssl_dyn_rec_timeout 1000ms;
- 对于一个新 TCP 连接，使用较小的 TLS Record Size 值（对应指令：ssl_dyn_rec_size_lo，默认值：1369）。
- 发送 40 个记录（对应指令：ssl_dyn_rec_threshold，默认值：40）之后，将 TLS Record Size 值调大到 4229（对应指令：ssl_dyn_rec_size_hi，默认值：4229）。
- 发送 80 个记录（2倍 threshold）之后，将 TLS Record Size 值调大到 16k（对应指令：ssl_buffer_size，默认值：16k）。
- 如果两次数据发送间隔超过 1000 ms，则将 TLS Record Size 值调小到 1369，然后重新从步骤 1 开始。
Tengine 也采用了 Cloudflare 的方式，并将这些配置项通过 lua ffi 接口的方式，让其在 lua 中可以动态设置，这样便可以很方便地在 CDN 配置管理后台根据域名的实际情况来动态配置了。CDN 配置管理后台配置界面截图如下（该功能没有开放到 CDN 用户控制台）：
