
Optimizing HTTPS performance - sshravan
https://istlsfastyet.com/
======
nickpsecurity
Good points. The author focuses on (a) have server do everything itself or (b)
use SSL accelerator hardware. There's a middle ground which has other benefits
depending on your use-case: I/O offloading hardware that also handles SSL.
These are often PCI networking cards that handle the packet processing,
firewall, IDS, maybe management, SSL/VPN, etc. The host CPU works at a high
level where it's only interrupted upon significant events or with most work
done. The load on an I/O-bound server is so small that cheap, embedded CPU's
can handle it. A CPU-bound server gets a great boost in performance for not
worrying about massive I/O load.

So, there's still potential with that model. Use host CPU if that's all you
need, though. Just remember that a few $200-300 networking cards might be a
better deal than whatever HSM vendors charge these days.

------
Ono-Sendai
I'm currently adding https (TLS) support to my blog, using LibTLS (part of
LibreSSL).

My initial impressions are that TLS handshake is very computationally
expensive.

Stress testing my webserver with plain HTTP connections:

7980.2744 queries/s

With HTTPS (TLS) connections:

23.059916 queries/s

The slowdown is due to high CPU usage.

I certainly wouldn't classify that as fast!

I've only done a bit of work on this so it's possible I'm misusing the LibTLS
API however.

~~~
Zr40
How did you measure this?

When measuring on one of my servers that exposes both HTTP and HTTPS, there
doesn't appear to be any significant difference.

HTTP:

    
    
      % wrk http://hostname
      Running 10s test @ http://hostname
        2 threads and 10 connections
        Thread Stats   Avg      Stdev     Max   +/- Stdev
          Latency     5.11ms    5.42ms  62.85ms   96.08%
          Req/Sec     1.10k   224.03     1.31k    87.04%
        17703 requests in 10.01s, 6.89MB read
      Requests/sec:   1768.57
      Transfer/sec:    704.58KB
    

HTTPS:

    
    
      % wrk https://hostname
      Running 10s test @ https://hostname
        2 threads and 10 connections
        Thread Stats   Avg      Stdev     Max   +/- Stdev
          Latency     4.75ms    4.09ms  50.37ms   96.48%
          Req/Sec     1.10k   228.86     1.34k    79.35%
        17014 requests in 10.01s, 8.39MB read
      Requests/sec:   1700.32
      Transfer/sec:    858.38KB

~~~
Ono-Sendai
I tested it with some of my own code, 8 threads making requests to my server
at localhost.

Does this program 'wrk' re-establish a connection for each request, or is it
re-using them?

~~~
Zr40
wrk[1] does appear to reuse a connection for each request.

[1] [https://github.com/wg/wrk](https://github.com/wg/wrk)

------
scarmig
Stupid question:

A lot of HTTPS's value comes from authentication, not encryption. Has anyone
investigated using something like the TLS_RSA_WITH_NULL_SHA cipher suite for
HTTPS, to provide auth and integrity without the computational cost of
symmetric encryption? Would that even provide a meaningful performance
benefit?

I'm guessing that it's disabled by default in most browsers, and figuring out
a sane user experience to allow users to differentiate between encrypted and
non-encrypted secure traffic seems like a very hard problem.

~~~
pjc50
I keep proposing "<a href="..." hash="sha256:abcdefg..."> as the quick, easy
80% solution to this. Works across sites and lets you authenticate resources
you don't own.

~~~
geofft
The hard part is delivering the initial page with those hashes. If you can
deliver it over HTTPS, why can't you deliver everything over HTTPS? (There are
good answers to that question, to be fair.) And if you can't, what use are the
hashes?

~~~
minitech
> If you can deliver it over HTTPS, why can't you deliver everything over
> HTTPS?

> Works across sites and lets you authenticate resources you don't own.

------
raimue
They probably need to automate the "upgrade to latest" box, current version
would be OpenSSL 1.0.2f 28 Jan 2016.

Anyway, I am not convinced the `openssl speed` benchmark output conveys
anything to the people addressed by the site.

~~~
jsingleton
You could always fix it and submit a pull request. Then automate that.

[https://github.com/igrigorik/istlsfastyet.com/pulls](https://github.com/igrigorik/istlsfastyet.com/pulls)

~~~
raimue
Thanks for the hint, I did not realize it was on GitHub. Pull request sent.

[https://github.com/igrigorik/istlsfastyet.com/pull/97](https://github.com/igrigorik/istlsfastyet.com/pull/97)

------
mattiemass
Love stuff like this. There's so much momentum around TLS lately, so great to
see.

------
ranrub
TLS is still slow, for users on 3G phones, remote areas, and 3rd world
countries. But who cares about them? They're poor! They can cope with a slow
web.

------
smackfu
If I go to a site called IsTLSFastYet.com, I expect a huge bit of text that
says "yes" or "no". Otherwise why use that format?

------
piyushco
thanks for sharing. useful.

