HTTPS 传输优化详解之动态 TLS Record Size

笔者在过去分析了诸多能够减小 HTTPS 传输延迟的方法，如分布式 Session 的复用；

启用 HSTS，客户端默认开启 HTTPS 跳转；采用 HTTP/2 传输协议；使用 ChaCha20-Poly1305 算法减小移动端 CPU 运算时间等。

经过这些方法，能够在很大程度上优化 HTTPS 在传输上的延迟，给网站用户带来较好的访问体验。

最近笔者又在考虑经过动态调节 TLS Record Size 来减小 HTTPS 传输延迟。

TLS 与 TCP

TLS 协议是由记录层（TLS Record Layer）和握手层（TLS Handshake Layer）组成的，记录层处于协议的最底层，为 TLS 协议提供安全可靠的链接，为高层协议提供数据封装、压缩、加密等基本功能的支持。握手层协议处于记录层协议之上，握手层协议的做用在真正的应用数据传输以前，可使客户端和服务器互相进行身份认证，协商加密算法以及生成加密密钥。通常来讲，最大的 TLS Record 的大小为 16KB，而每一个 TLS Record 包含一个 5Byte 的头部。

TCP（Transmission Control Protocol 传输控制协议）是一种面向链接（链接导向）的、可靠的、 基于 IP 的传输层协议。

TLS 是创建在可靠的数据传输的基础之上，运行在 TCP 层之上，一个 TLS Record Size 由多个 TCP 包组成，经过 WireShark 抓包能够看出，一个 TLS Record 大小为 16408 Byte ，被分为了 12 个 TCP 包。

△ WireShark 抓包

动态 TLS Record Size 调整原理

Nginx 默认的 ssl_buffer_size 大小为 16KB（不支持动态调整），这就是一个 TLS Record Size 的大小。举例说明， 假如资源文件的大小为 1600KB，那么就会被拆分为 100 个 TLS Record 传送到客户端。

在传输过程当中此时会出现这样的问题：

一、TLS Record Size 越大，被拆分的 TCP 包会过多，在传输过程当中，若是 TCP 出现丢包状况，那么 TLS Record 到达客户端的时间就会变长，而客户端必须等到收到完整的 TLS Record 才可以进行解密；TLS Record 及 TCP 包的关系以下图所示：

△ 图片来源：igvita.com

二、若是 TLS Record Size 较小，则 TCP 丢包对 TLS Record 的影响就较小了，可是于此同时，TLS Record 头部就变多了，可能还会下降链接的吞吐量。

综上所述，能够知道切割太小的 Record Size 会产生额外的消耗；而切割过大的 Record Size 会致使延迟。笔者认为能够根据 TCP 窗口大小来合理调整 TLS Record 大小能够有效下降 HTTPS 传输时形成的延迟。

如何进行 Record Size 大小调整

根据以上的论点，咱们能够得出这样的结论：在 TCP 慢启动的过程当中，能够将 TLS Record Size 调整小点；由于这个过程当中 TCP 连接的拥塞窗口（cwnd ）较小，TCP 连接的吞吐量也较小；在 TCP 链接结束慢启动以后，TLS Record 的大小能够增大一些，随着时间的推移，最终将 TLS Record 的大小调整到最大（也即 16KB）。

大体的算法规则为：

一、在新链接以及 TCP 慢启动阶段，将 TLS Record 大小调整为大约 1 个 TCP 包的大小；
二、在必定的阶段，也即发送必定数量的 Record Size 以后，采用较大的 TLS Record Size ；
三、随着时间的推移，采用最大的TLS Record Size 大小，也即 16KB。

WireShark 抓包验证

经过 WireShark 抓包，对这个过程进行验证：

阶段一：在刚开始，TLS Record Size 为 1393 Byte。

阶段二：一段时间以后，TLS Record Size 为 4253 Byte。

阶段三：最后，TLS Record Size 动态变为 16408 Byte。

上图三个阶段的抓包结果验证了动态 TLS Record Size 的算法规则，经过对动态调节 TLS Record Size 能够有效下降 HTTPS 传输时的延迟，为客户带来更好的体验。

目前，又拍云 CDN 平台已经彻底支持动态调整 TLS Record Size ，对网站速度有更高要求的朋友能够经过开启又拍云 CDN，来使用动态 TLS Record Size，让网站传输速度更快，给用户更好的体验。