snit (SNI Termination Library) to replace Nginx

Dave Cottlehuber dch@REDACTED
Sat Nov 9 17:30:01 CET 2019

On Sat, 9 Nov 2019, at 07:22, Frank Muller wrote:
> We mainly upload large files (20mB to 100mB) to our two webapps behind Nginx.
> ssl_prefer_server_ciphers on;
> ssl_ecdh_curve
> secp384r1


- use TLS1.3 if you can - most of the decisions have been made for you
- ensure your cipher choice is hardware accelerated in your openssl
- look at actual network traffic to see if there's any issues there
- no easy answers, benchmark your setup

I hope this helps point you in the right direction.

"SSL/TLS accounts for less than 1% of the CPU load, less than 10 KB of
memory per connection and less than 2% of network overhead."


It should be possible to transfer traffic over TLS at rates significantly
faster than what you're reporting, obviously. However, I would be surprised
if nginx itself is the problem, given netflix can saturate their pipes with
nginx, admittedly with a lot of tweaking [1], [2] and a custom FreeBSD build.

I would first look to see if you can restrict your ciphers to provide better
performance for your hardware, and highly recommend capturing data with
tcpdump & wireshark to do some network level analysis. This will vary a lot
depending on what control you have over client TLS capabilities [3], and
if you have OpenSSL 1.1.x available, and perhaps http2 on clients also.

Intel's notes from 2016 [4] show a noticeable difference between algorithms
so you need to benchmark your load on your hardware.

Personally, for TLS termination I prefer haproxy[5] but all of hitch, nginx,
snit, haproxy should be able to achieve similar results.[6] is interesting
but 2.x haproxy handles multiple processes itself.

You can use or to help validate protocol choices.

Useful references:

- get the ebook
direct as amazon seems to have an out of date version


More information about the erlang-questions mailing list