TLS session resumption (identifier)

Igor Sysoev igor at sysoev.ru
Fri Mar 4 10:19:21 UTC 2016


On 04 Mar 2016, at 12:55, B.R. <reallfqq-nginx at yahoo.fr> wrote:

> On Fri, Mar 4, 2016 at 10:33 AM, Igor Sysoev <igor at sysoev.ru> wrote:
>> But still, advertising something without actually supporting it must lead to cases where sessions reuse is believed to take place without ever happening, harming performance... that was probably happening in versions < 1.5.9.
> 
> I do not think that it should harm performance.
> 
> ​Oh yes it does​... I am surprised by your stance and I beg to differ.
> Having quite some load from many clients on a web-server delivering content over HTTPS, it relieves a lot of pain to save CPU cycles by avoiding a full handshake.
> When a client browses a website, (s)he will initiate many connections. Beyond the first one (ones with multiplexing?), session reuse kicks in. Repeat that for each client and sum all the saved CPU cycles. Even an improper (non-scientific) benchmark will show you improvement.
> 
> Session reuse is part of the effort of optimizing TLS trafic to minimize its overhead. Have a talk about it with the W3C webperf group if you wish, to which Ilya Grigorik (participated at nginxconf 2014) belongs. Have a look at his checklist too.​

Sorry, I meant there is no performance difference between “none” and “off” settings.

As to default value, builtin session cache was by default initially but it turned out that
it leads to memory fragmentation. So the default value has been changed to “off” and
later to “none”.

Of course shared cache is certainly better as default value but there is no good understanding
what default cache size should be used. And now it becomes less important with ticket introduction. 


-- 
Igor Sysoev
http://nginx.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx/attachments/20160304/e0433ced/attachment.html>


More information about the nginx mailing list