Hi.
Am 17-03-2016 11:51, schrieb Gary Barrueto:
Hi.
On Mar 16, 2016 10:06 PM, "Willy Tarreau" <
Here I don't know. TLS handshakes are one large part of what made me
think
that we must go multi-threaded instead of multi-process over the long
term,
just because I want to be able to pin some tasks to some CPUs. Ie when
TLS
says "handshake needed", we want to be able to migrate the task to
another
CPU to avoid the huge latency imposed to all other processing (eg: 7ms
in
your case).
While that would help a single server, how about when dealing with
multi
servers + anycast: Has there been any thoughts about sharing ssl/tls
session cache between servers? Like how apache can use memcache to
store
its cache or how cloudfare used/patched openresty to do the same
recently.
I have asked this also but I think the answer is not that easy.
As willy have written above there should be a hook in the ssl-handshake
flow to be able to call external data.
Maybe similar like the peers handling for sessions.
even nginx have only shared session store between processes not servers.
http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_cache
Maybe the session tickets concept could help but I haven't dig to deep
into this topic.
http://tools.ietf.org/html/rfc5077
BR Aleks
http://nginx.org/en/docs/http/ngx_http_ssl_module.html#ssl_session_tickets
