概念
我们已经知道什么是SNI,以及如何为用户配置SNI。
[nginx] nginx使用SNI功能的方法
问题
通过观察配置文件,可以发现,针对每一个SSL/TLS链接, nginx都会动态的查找(加载),找到正确的证书。
那么在这个过程中,与没有SNI配置的情况下,有什么性能异同呢?
通过对nginx相关部分的源码分析,将给出这个问题的答案。
(不关注源码的话,可以直接翻到后文查看“结论”章节。)
有图有真相
分析
如上图所示
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.
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证书集合元素数量需要设置上限。