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

标签: | 发表时间:2017-11-24 17:10 | 作者:
出处:https://zhuanlan.zhihu.com

笔者在过去分析了诸多可以减少 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 传送到客户端。

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

1. TLS Record Size 越大,被拆分的 TCP 包会过多,在传输过程中,如果 TCP 出现丢包情况,那么 TLS Record 到达客户端的时间就会变长,而客户端必须等到收到完整的 TLS Record 才能够进行解密;TLS Record 及 TCP 包的关系如下图所示:

△ 图片来源:igvita.com

2. 如果 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)。

大致的算法规则为:

  1. 在新连接以及 TCP 慢启动阶段,将 TLS Record 大小调整为大约 1 个 TCP 包的大小;
  2. 在一定的阶段,也即发送一定数量的 Record Size 之后,采用较大的 TLS Record Size ;
  3. 随着时间的推移,采用最大的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,让网站传输速度更快,给用户更好的体验。

推荐阅读:

从 HTTP 到 HTTPS 再到 HSTS

HTTPS系列干货(一):HTTPS 原理详解

相关 [https 传输 优化] 推荐:

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

- -
笔者在过去分析了诸多可以减少 HTTPS 传输延迟的方法,如分布式 Session 的复用;. 启用 HSTS,客户端默认开启 HTTPS 跳转;采用 HTTP/2 传输协议;使用 ChaCha20-Poly1305 算法减少移动端 CPU 运算时间等. 通过这些方法,可以在很大程度上优化 HTTPS 在传输上的延迟,给网站用户带来较好的访问体验.

Picasa Web Albums 支持 HTTPS 加密传输,在景德镇复出

- LingBo - 谷奥——探寻谷歌的奥秘
Picasa Web Albums今天终于也像网页搜索、Google Docs和Gmail一样推出了HTTPS的加密传输版本,只要访问https://picasaweb.google.com即可,方便你在不安全的WiFi连接下传输私人艳照,当然在景德镇HTTPS有更特殊的意义──任何卑鄙的伎俩都不应该阻碍人们对互联网的访问.

https协议

- - 互联网 - ITeye博客
SSL 协议的握手过程   .       为了便于更好的认识和理解 SSL 协议,这里着重介绍 SSL 协议的握手协议. SSL 协议既用到了公钥加密技术(非对称加密)又用到了对称加密技术,SSL对传输内容的加密是采用的对称加密,然后对对称加密的密钥使用公钥进行非对称加密. 这样做的好处是,对称加密技术比公钥加密技术的速度快,可用来加密较大的传输内容,公钥加密技术相对较慢,提供了更好的身份认证技术,可用来加密对称加密过程使用的密钥.

Go和HTTPS

- - Tony Bai
近期在构思一个产品,考虑到安全性的原因,可能需要使用到 HTTPS协议以及双向数字证书校验. 之前只是粗浅接触过HTTP( 使用Golang开 发微信系列). 对HTTPS的了解则始于那次 自行搭建ngrok服务,在那个过程中照猫画虎地为服务端生成了一些私钥和证书,虽然结果是好 的:ngrok服务成功搭建起来了,但对HTTPS、数字证书等的基本原理并未求甚解.

Google https被屏蔽

- - 月光博客
  根据Google透明度报告 显示,从上周(5月27日)开始,Google的部分服务开始被屏蔽,其中最主要的是HTTPS搜索服务和Google登录服务,所有版本的Google都受到影响,包括Google.hk和Google.com等.   此次屏蔽的方法主要屏蔽Google部分IP地址的443端口,包括google.com.hk,accounts.google.com的部分IP的443端口被封,导致部分中国用户无法访问Google搜索和Gmail,由于Google的IP地址非常多,而被屏蔽的只是其中部分IP,因此只有部分用户受到了影响.

HTTPS的二三事

- - 细语呢喃
前几篇博文都是有关HTTPS的东西,有人可能会问,什么是HTTPS. 因此,本文主要来解答这些疑惑. Alice和Bob是情人,他们每周都要写信. Alice 写好后,送到邮局,邮局通过若干个快递员到Bob,Bob回信过程类似. 这是可以看成的简单的http的传输. 有一天,Alice觉得,要是写的信中途被人拆开了呢.

如何优化与外部设备传输数据的速度?

- - 极客范 - GeekFan.net
在电脑和外部设备之间传输数据是一项常见的任务,照片,视频,重要文件,数据备份,它们时常会被来来回回传输很多次. 这就是为什么传输速度会让人不爽. 如果你需要马上带着几个GB的数据去参加一个会议,没人想等上十分钟来拷贝这些数据,马上就要迟到了. 幸运的是,有几种简单的方法来提高数据传输的速度. Windows的默认USB驱动使用“快速移除”数据传输策略,它会关闭写入缓存,导致数据传输变慢.

最新网址 https://72.52.124.208

- chanjw - 电驴下载基地
精彩世界 cmule.com 我们传递.

最新网址 https://72.52.124.209

- Asker - 电驴下载基地
精彩世界 cmule.com 我们传递.

Google升级HTTPS加密

- 请叫我火矞弟 - Solidot
民不拜天又不拜孔子留此膝何为 写道 "Google 修改了启用HTTPS服务的加密方法,以应对未来技术发展后可能造成的解密行为. 这项升级适用于Gmail、Docs和Google+. 现在的HTTPS实现借助于只有域名主人所掌握的私钥生成的session key来加密服务器和客户端之间的流量. 这种方法使得连接可能被所谓“追溯式解密攻击”(retrospective decryption attack)破解.