为了账号安全,请及时绑定邮箱和手机立即绑定

优化 Tengine HTTPS 握手时间

2019.08.13 16:00 111浏览

背景

网络延迟是网络上的主要性能瓶颈之一。在最坏的情况下,客户端打开一个链接需要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 代码如下: 

需要注意的是这块代码是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 的延迟对用户体验影响很大,如下图: 

9号包是客户端的 ACK,对 7号服务器端发的证书包进行确认,这两个包相差了将近 200ms,这个就是客户端的 delay ack,这样这次 SSL 握手时间就超过 200ms 了。那怎样优化呢?其实只要我们尽量少发送小包就可以避免,比如上面的截图,只要将7号和10号一起发送就可以避免 delay ack,这是因为内核协议栈在回复 ACK 时,如果收到的数据大于1个 MSS 时会立即 ACK,内核源码如下: 

知道了问题的原因所在以及如何避免,那就看应用层的发送数据逻辑了,由于是在 SSL 握手期间,所以应该跟 SSL 写内核有关系,查看 openssl 的源码: 

默认写 buffer 大小是 4k,当证书比较大时,就容易分多次写内核,从而触发客户端的 delay ack。
接下来查看 tengine 有没有调整这个 buffer 的地方,还真有(下图第903行): 

那不应该有 delay ack 啊……
无奈之下只能上 gdb 大法了,调试之后发现果然没有调用到 BIO_set_write_buffer_size,原因是 rbio 和 wbio 相等了,那为啥以前没有这种情况现在才有呢?难道是升级 openssl 的原因?继续查 openssl-1.0.2 代码: 

openssl-1.1.1 的 SSL_get_wbio 有了变化: 

原因终于找到了,使用老版本就没有这个问题。就不细去看 bbio 的实现了,修复也比较简单,就用老版本的实现即可,所以就打了个 patch: 

重新编译打包后测试,问题得到了修复。使用新版 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字节)一致

(全文完)


点击查看更多内容
0人点赞

若觉得本文不错,就分享一下吧!

评论

相关文章推荐

正在加载中
意见反馈 邀请有奖 帮助中心 APP下载
官方微信

举报

0/150
提交
取消