In my current setup I have nginx behind a load balancing router (OSPF)
where each connection to the same address has about 16% chance of
hitting
the same server as the last time.
In a setup like that, does SSL session caching make any difference? I
was
thinking it through this morning and I’m betting that the browser would
toss the old session ID unless it happened to be routed to the same
backend, because in the other cases the backend servers would respond
they
don’t know the session. Is that correct?
Hello!
On Tue, Jun 02, 2015 at 10:29:31AM -0400, CJ Ess wrote:
In my current setup I have nginx behind a load balancing router (OSPF)
where each connection to the same address has about 16% chance of hitting
the same server as the last time.
In a setup like that, does SSL session caching make any difference? I was
thinking it through this morning and I’m betting that the browser would
toss the old session ID unless it happened to be routed to the same
backend, because in the other cases the backend servers would respond they
don’t know the session. Is that correct?
If a server doesn’t know the session, it will simply create a new
one. There is no performance difference between “no session” and
“an unknown session” cases. That is, session cache is still
beneficial in such a setup - but has relatively small chance to
help.
In such a setup, it should also be beneficial to configure shared
session ticket keys, see Module ngx_http_ssl_module.
–
Maxim D.
http://nginx.org/
In my current setup I have nginx behind a load balancing router (OSPF)
where each connection to the same address has about 16% chance of
hitting the same server as the last time.
If you get your router to only hash source and destination IP instead of
5-tuple for the load-balancing, that will fix your issue.
Lukas