概念
我们已经知道什么是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证书集合元素数量需要设置上限。