概念

我们已经知道什么是SNI,以及如何为用户配置SNI。

[nginx] nginx使用SNI功能的方法

问题

通过观察配置文件,可以发现,针对每一个SSL/TLS链接, nginx都会动态的查找(加载),找到正确的证书。

那么在这个过程中,与没有SNI配置的情况下,有什么性能异同呢?

通过对nginx相关部分的源码分析,将给出这个问题的答案。

(不关注源码的话,可以直接翻到后文查看“结论”章节。)

[classic_tong @ 20191023]

有图有真相

[nginx] nginx源码分析--SNI性能分析-LMLPHP

分析

如上图所示

1 模块

nginx使用两个模块(这里只针对http进行分析,stream请自行类推)来完成tls的处理,ngx_openssl_module 与

ngx_http_ssl_module。其中前者为核心模块。后者为http模块。

核心模块会被master进程调用ngx_ssl_init()函数进行加载,完成全局处理,包括对openssl的初始化。

http模块将由http框架完成处理,可以分为配置阶段与connection的解析阶段。

2  配置阶段

见图中的红框“流程二”。这个阶段就是逐行处理配置文件的阶段。在这个阶段里,merge ssl server config的时候,

http_ssl_module将判断是否配置了SNI功能。

如果没有配置,将调用ngx_ssl_certificate()函数加载证书链里边的所有证书

,将其读进内存并保存在全局配置文件的ctx结构体呢。ctx结构体是openssl api中的全局上下文,会作为参数传入

给openssl的api,openssl在处理连接时,会将ctx里的证书链拷贝(由SSL_new接口完成)到connect结构里,

openssl的connect结构的作用域是tls连接级别。

如果配置了SNI,http_ssl_module将不会加载证书链,而是将配置中的变量解析编译好备用,为运行时做好准备。

同时,还会通过openssl的SSL_CTX_set_cert_cb()函数设置一个回调函数 ngx_http_ssl_certificate(), 该函数会在

ssl握手之前进入,给用户一个修改证书信息的机会。该回调是在SSL_do_handshake()中完成的。

# man SSL_CTX_set_cert_cb
cert_cb() is the application defined callback. It is called before a certificate will be used by a client or server.
The callback can then inspect the passed ssl structure and set or clear any appropriate certificates.

[classic_tong @ 20191023]

3 请求阶段

如图红框“流程三”

在请求阶段,“是否启用了SNI功能”是不被nginx感知的。所有与SNI相关的逻辑都会在前文设置的回调函数 ngx_http_ssl_certificate()

中完成。nginx框架与ssl模块只是正常的完成业务逻辑处理。

在回调函数中,首先会申请一个request结构体,作为中间存储。然后通过openssl的BIO接口完成证书链的加载,并关联至

openssl的connect结构里。然后,刚刚申请的request会被释放(这里边新建了一个pool,这个pool是从操作系统申请的内存)。

该过程与配置阶段共同复用了函数 ngx_ssl_load_certificate(), 整个过程都没有全局上下文ctx的参与,链接结束后证书链会被释放掉。

下次新的链接会重新再加载一次证书链。

4 openssl

分别观察有SNI和没有SNI的两个流程,将发现api的调用序列上有如下区别,关键在于是否使用ctx上下文。

无sni的时候,使用SSL_CTX_use_certificate()函数,有sni的时候,使用SSL_use_certificate()函数。

查找文档,对比一下区别:

# man SSL_CTX_use_certificate
The SSL_CTX_* class of functions loads the certificates and keys into the SSL_CTX object ctx. The information is passed
to SSL objects ssl created from ctx with SSL_new() by copying, so that changes applied to ctx do not propagate to already existing SSL objects. The SSL_* class of functions only loads certificates and keys into a specific SSL object. The specific
information is kept, when SSL_clear() is called for this SSL object.

从侧面印证我们的分析结果,感兴趣的可以完整的阅读手册,这里不在赘述。

5 实验

截止到目前所有的分析都是基于nginx的,将openssl作为黑盒。并不能严谨的排除openssl为此做了特别优化,去防止多次加载

证书链的可能。 为了印证分析,做如下实验,配置SNI后,使用相同的证书多次请求。通过gdb观察,是否每次都进入回调函数并重新加载

证书链。

         if (ngx_strncmp(cert->data, "data:", sizeof("data:") - ) == ) {
(gdb) n
if (ngx_get_full_name(pool, (ngx_str_t *) &ngx_cycle->conf_prefix, cert)
(gdb)
bio = BIO_new_file((char *) cert->data, "r");
(gdb)
if (bio == NULL) {
(gdb)
x509 = PEM_read_bio_X509_AUX(bio, NULL, NULL, NULL);
(gdb) bt
# ngx_ssl_load_certificate (pool=0x55825f636240, err=0x7ffd32750868, cert=0x7ffd32750900, chain=0x7ffd32750870) at src/event/ngx_event_openssl.c:
# 0x000055825ed31d79 in ngx_ssl_connection_certificate (c=0x55825f64c0c0, pool=0x55825f636240, cert=0x7ffd32750900, key=0x7ffd32750910, passwords=0x55825f0df860 <empty_passwords.>) at src/event/ngx_event_openssl.c:
# 0x000055825ee378ef in ngx_stream_ssl_certificate (ssl_conn=0x55825f632c70, arg=0x55825f63def0) at src/stream/ngx_stream_ssl_module.c:
# 0x00007efed0277b3c in tls_post_process_client_hello () from /opt/openssl/lib/libssl.so.1.1
# 0x00007efed026d362 in state_machine () from /opt/openssl/lib/libssl.so.1.1
# 0x00007efed0265991 in SSL_do_handshake () from /opt/openssl/lib/libssl.so.1.1
# 0x000055825ed33f27 in ngx_ssl_handshake (c=0x55825f64c0c0) at src/event/ngx_event_openssl.c:
# 0x000055825ed34671 in ngx_ssl_handshake_handler (ev=0x55825f66dec0) at src/event/ngx_event_openssl.c:
# 0x000055825ed2dae8 in ngx_epoll_process_events (cycle=0x55825f62d4a0, timer=, flags=) at src/event/modules/ngx_epoll_module.c:
# 0x000055825ed185cf in ngx_process_events_and_timers (cycle=0x55825f62d4a0) at src/event/ngx_event.c:
# 0x000055825ed2a4d4 in ngx_worker_process_cycle (cycle=0x55825f62d4a0, data=0x0) at src/os/unix/ngx_process_cycle.c:
# 0x000055825ed26305 in ngx_spawn_process (cycle=0x55825f62d4a0, proc=0x55825ed2a3d4 <ngx_worker_process_cycle>, data=0x0, name=0x55825ee6e4fb "worker process", respawn=-) at src/os/unix/ngx_process.c:
# 0x000055825ed29018 in ngx_start_worker_processes (cycle=0x55825f62d4a0, n=, type=-) at src/os/unix/ngx_process_cycle.c:
# 0x000055825ed284fb in ngx_master_process_cycle (cycle=0x55825f62d4a0) at src/os/unix/ngx_process_cycle.c:
# 0x000055825ecdf1d9 in main (argc=, argv=0x7ffd327511a8) at src/core/nginx.c:
(gdb)

(留个调用栈,方便以后看。)

通过实验,证书每次都会通过api BIO_new_file 进行重新加载,除非该函数做了优化,否则每次链接的每个证书都将发生磁盘IO操作。

结论

配置了SNI功能之后,nginx对TLS链接请求的处理将产生性能损失。损失的粒度为每链接级别。

每个ssl/tls链接都将额外发生:一次内存申请与释放;一组加载证书链上全部证书的磁盘IO。

改进方案

我认为内存的申请可以忽略,因为原本处理request的时候也是需要向OS申请内存的。比较关键的在于磁盘IO。

第一个方案,可以将所有证书放置在内存文件系统中,此方案不需要调整代码。

第二个方案,重写ngx_http_ssl_certificate(), 虽然证书是动态选择的,但是只要在备选集合确定的情况下,我们依然

可以进行预加载,去除掉运行时的IO。引入的限制为:1备选集合不能实时变更,2证书集合元素数量需要设置上限。

[classic_tong @ 20191023]

05-08 14:50