优化 Tengine HTTPS 握手时间

本文涉及的产品
Redis 开源版,标准版 2GB
推荐场景:
搭建游戏排行榜
云数据库 Tair(兼容Redis),内存型 2GB
简介: ## 背景 网络延迟是网络上的主要性能瓶颈之一。在最坏的情况下,客户端打开一个链接需要DNS查询(1个 RTT),TCP握手(1个 RTT),TLS 握手(2个RTT),以及最后的 HTTP 请求和响应,可以看出客户端收到第一个 HTTP 响应的首字节需要5个 RTT 的时间,而首字节时间对 web 体验非常重要,可以体现在网站的首屏时间,直接影响用户判断网站的快慢,所以首字节时间(TTFB)是

背景

网络延迟是网络上的主要性能瓶颈之一。在最坏的情况下,客户端打开一个链接需要DNS查询(1个 RTT),TCP握手(1个 RTT),TLS 握手(2个RTT),以及最后的 HTTP 请求和响应,可以看出客户端收到第一个 HTTP 响应的首字节需要5个 RTT 的时间,而首字节时间对 web 体验非常重要,可以体现在网站的首屏时间,直接影响用户判断网站的快慢,所以首字节时间(TTFB)是网站和服务器响应速度的重要指标,下面我们来看影响 SSL 握手的几个方面:

TCP_NODELAY

我们知道,小包的载荷率非常小,若网络上出现大量的小包,则网络利用率比较低,就像客运汽车,来一个人发一辆车,可想而知这效率将会很差,这就是典型的 TCP 小包问题,为了解决这个问题所以就有了 Nigle 算法,算法思想很简单,就是将多个即将发送的小包,缓存和合并成一个大包,然后一次性发送出去,就像客运汽车满员发车一样,这样效率就提高了很多,所以内核协议栈会默认开启 Nigle 算法优化。Night 算法认为只要当发送方还没有收到前一次发送 TCP 报文段的的 ACK 时,发送方就应该一直缓存数据直到数据达到可以发送的大小(即 MSS 大小),然后再统一合并到一起发送出去,如果收到上一次发送的 TCP 报文段的 ACK 则立马将缓存的数据发送出去。虽然效率提高了,但对于急需交付的小包可能就不适合了,比如 SSL 握手期间交互的小包应该立即发送而不应该等到发送的数据达到 MSS 大小才发送,所以,SSL 握手期间应该关闭 Nigle 算法,内核提供了关闭 Nigle 算法的选项: TCP_NODELAY,对应的 tengine/nginx 代码如下:
image.png
image.png
需要注意的是这块代码是2017年5月份才提交的代码,使用老版本的 tengine/nginx 需要自己打 patch。

TCP Delay Ack

与 Nigle 算法对应的网络优化机制叫 TCP 延迟确认,也就是 TCP Delay Ack,这个是针对接收方来讲的机制,由于 ACK 包是有效 payload 比较少的小包,如果频繁的发 ACK 包也会导致网络额外的开销,同样出现前面提到的小包问题,效率低下,因此延迟确认机制会让接收方将多个收到数据包的 ACK 打包成一个 ACK 包返回给发送方,从而提高网络传输效率,跟 Nigle 算法一样,内核也会默认开启 TCP Delay Ack 优化。进一步讲,接收方在收到数据后,并不会立即回复 ACK,而是延迟一定时间,一般ACK 延迟发送的时间为 200ms(每个操作系统的这个时间可能略有不同),但这个 200ms 并非收到数据后需要延迟的时间,系统有一个固定的定时器每隔 200ms 会来检查是否需要发送 ACK 包,这样可以合并多个 ACK 从而提高效率,所以,如果我们去抓包时会看到有时会有 200ms 左右的延迟。但是,对于 SSL 握手来说,200ms 的延迟对用户体验影响很大,如下图:
image.png
9号包是客户端的 ACK,对 7号服务器端发的证书包进行确认,这两个包相差了将近 200ms,这个就是客户端的 delay ack,这样这次 SSL 握手时间就超过 200ms 了。那怎样优化呢?其实只要我们尽量少发送小包就可以避免,比如上面的截图,只要将7号和10号一起发送就可以避免 delay ack,这是因为内核协议栈在回复 ACK 时,如果收到的数据大于1个 MSS 时会立即 ACK,内核源码如下:
image.png
知道了问题的原因所在以及如何避免,那就看应用层的发送数据逻辑了,由于是在 SSL 握手期间,所以应该跟 SSL 写内核有关系,查看 openssl 的源码:
image.png
默认写 buffer 大小是 4k,当证书比较大时,就容易分多次写内核,从而触发客户端的 delay ack。
接下来查看 tengine 有没有调整这个 buffer 的地方,还真有(下图第903行):
image.png
那不应该有 delay ack 啊……
无奈之下只能上 gdb 大法了,调试之后发现果然没有调用到 BIO_set_write_buffer_size,原因是 rbio 和 wbio 相等了,那为啥以前没有这种情况现在才有呢?难道是升级 openssl 的原因?继续查 openssl-1.0.2 代码:
image.png
openssl-1.1.1 的 SSL_get_wbio 有了变化:
image.png
原因终于找到了,使用老版本就没有这个问题。就不细去看 bbio 的实现了,修复也比较简单,就用老版本的实现即可,所以就打了个 patch:
image.png
重新编译打包后测试,问题得到了修复。使用新版 openssl 遇到同样问题的同学可以在此地方打 patch。

Session 复用

完整的 SSL 握手需要2个 RTT,SSL Session 复用则只需要1个 RTT,大大缩短了握手时间,另外 Session 复用避免了密钥交换的 CPU 运算,大大降低 CPU 的消耗,所以服务器必须开启 Session 复用来提高服务器的性能和减少握手时间,SSL 中有两种 Session 复用方式:

  • 服务端 Session Cache
    大概原理跟网页 SESSION 类似,服务端将上次完整握手的会话信息缓存在服务器上,然后将 session id 告知客户端,下次客户端会话复用时带上这个 session id,即可恢复出 SSL 握手需要的会话信息,然后客户端和服务器采用相同的算法即可生成会话密钥,完成握手。

这种方式是最早优化 SSL 握手的手段,在早期都是单机模式下并没有什么问题,但是现在都是分布式集群模式,这种方式的弊端就暴露出来了,拿 CDN 来说,一个节点内有几十台机器,前端采用 LVS 来负载均衡,那客户端的 SSL 握手请求到达哪台机器并不是固定的,这就导致 Session 复用率比较低。所以后来出现了 Session Ticket 的优化方案,之后再细讲。那服务端 Session Cache 这种复用方式如何在分布式集群中优化呢,无非有两种手段:一是 LVS 根据 Session ID 做一致性 hash,二是 Session Cache 分布式缓存;第一种方式比较简单,修改一下 LVS 就可以实现,但这样可能导致 Real Server 负载不均,我们用了第二种方式,在节点内部署一个 redis,然后 Tengine 握手时从 redis 中查找是否存在 Session,存在则复用,不存在则将 Session 缓存到 redis 并做完整握手,当然每次与 redis 交互也有时间消耗,需要做多级缓存,这里就不展开了。核心的实现主要用到 ssl_session_fetch_by_lua_file 和 ssl_session_store_by_lua_file,在 lua 里面做一些操作 redis 和缓存即可。

  • Session Ticket
    上面讲到了服务端 Session Cache 在分布式集群中的弊端,Session Ticket 是用来解决该弊端的优化方式,原理跟网页的 Cookie 类似,客户端缓存会话信息(当然是加密的,简称 session ticket),下次握手时将该 session ticket 通过 client hello 的扩展字段发送给服务器,服务器用配置好的解密 key 解密该 ticket,解密成功后得到会话信息,可以直接复用,不必再做完整握手和密钥交换,大大提高了效率和性能,(那客户端是怎么得到这个 session ticket 的呢,当然是服务器在完整握手后生成和用加密 key 后给它的)。可见,这种方式不需要服务器缓存会话信息,天然支持分布式集群的会话复用。这种方式也有弊端,并不是所有客户端或者 SDK 都支持(但主流浏览器都支持)。所以,目前服务端 Session Cache 和 Session Ticket 都会存在,未来将以 Session Ticket 为主。

Tengine 开启 Session Ticket 也很简单:

    ssl_session_tickets on;
    ssl_session_timeout 48h;
    ssl_session_ticket_key ticket.key;  #需要集群内所有机器的 ticket.key 内容(48字节)一致

(全文完)

相关实践学习
通过Ingress进行灰度发布
本场景您将运行一个简单的应用,部署一个新的应用用于新的发布,并通过Ingress能力实现灰度发布。
容器应用与集群管理
欢迎来到《容器应用与集群管理》课程,本课程是“云原生容器Clouder认证“系列中的第二阶段。课程将向您介绍与容器集群相关的概念和技术,这些概念和技术可以帮助您了解阿里云容器服务ACK/ACK Serverless的使用。同时,本课程也会向您介绍可以采取的工具、方法和可操作步骤,以帮助您了解如何基于容器服务ACK Serverless构建和管理企业级应用。 学习完本课程后,您将能够: 掌握容器集群、容器编排的基本概念 掌握Kubernetes的基础概念及核心思想 掌握阿里云容器服务ACK/ACK Serverless概念及使用方法 基于容器服务ACK Serverless搭建和管理企业级网站应用
目录
相关文章
|
域名解析 缓存 网络协议
HTTP 的基本优化策略
HTTP 的基本优化策略
95 0
|
Web App开发 tengine 网络协议
Tengine 使用 Brotli 开启TLS1.3 并优化 HTTPS 访问速度
本文介绍 Tengine 的编译安装,并启用 Brotli 压缩,配置开启 https。
416 0
Tengine 使用 Brotli 开启TLS1.3 并优化 HTTPS 访问速度
|
存储 缓存 安全
HTTPS 优化总结
HTTPS 优化总结
434 0
|
弹性计算 前端开发 数据建模
VuePress 博客优化之开启 HTTPS
在 《一篇带你用 VuePress + Github Pages 搭建博客》中,我们使用 VuePress 搭建了一个博客,最终的效果查看:TypeScript4 中文文档。注意此时,我们的域名还是 ts.yayujs.com,众所周知,开启 HTTPS 有很多好处,比如可以实现数据加密传输等,那我们如何开启 HTTPS 配置呢?
197 0
VuePress 博客优化之开启 HTTPS
|
缓存 负载均衡 算法
|
存储 缓存 负载均衡
RH358优化Web服务器流量--使用HAProxy终止HTTPS流量和并进行负载均衡
RH358优化Web服务器流量--使用HAProxy终止HTTPS流量和并进行负载均衡
544 0
RH358优化Web服务器流量--使用HAProxy终止HTTPS流量和并进行负载均衡
|
缓存 网络协议 定位技术
优化HTTP请求和响应的方法
优化HTTP请求和响应的方法
172 0
|
Web App开发 前端开发 JavaScript
Cloudflare的HTTP/2优化策略
Cloudflare针对HTTP/2优先级的进一步优化,将网页控制权尽可能地交给网站所有者,可根据具体需求与场景,定制化网页加载优先级策略,提供更快速,更优质的用户Web访问与交互体验。
618 0
Cloudflare的HTTP/2优化策略
|
Web App开发 安全 算法
【大量干货】史上最完整的Tengine HTTPS原理解析、实践与调试
本文邀请阿里云CDN HTTPS技术专家金九,分享Tengine的一些HTTPS实践经验。内容主要有四个方面:HTTPS趋势、HTTPS基础、HTTPS实践、HTTPS调试。 一、HTTPS趋势 这一章节主要介绍近几年和未来HTTPS的趋势,包括两大浏览器chrome和firefix对HTTPS的态度,以及淘宝天猫和阿里云CDN的HTTPS实践情况。
11210 0
|
tengine 缓存 算法
优化 Tengine HTTPS 握手时间
背景 网络延迟是网络上的主要性能瓶颈之一。在最坏的情况下,客户端打开一个链接需要DNS查询(1个 RTT),TCP握手(1个 RTT),TLS 握手(2个RTT),以及最后的 HTTP 请求和响应,可以看出客户端收到第一个 HTTP 响应的首字节需要5个 RTT 的时间,而首字节时间对 web 体.
3535 0