Go Premium for a chance to win a PS4. Enter to Win

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 9820
  • Last Modified:

What exactly is meant by SSL Transactions Per Second ( TPS ) in an SSL offloading scenario?

I'm evaluating content delivery / load balancing vendors and many measure their appliance's ability to perform by SSL Transactions Per Second or SSL TPS. TPS is higher when there is dedicated hardware to process SSL connections rather than just software (obviously). SSL certificates are installed or terminated on the device, the device negotiates with the client browser and typically the connection from the load balancer to the server is not encrypted.

I'm trying to determine our TPS needs based on our traffic and I don't have a clear way to translate, say requests/sec into SSL TPS. There doesn't seem to be a direct correlation.

Does TPS refer to ONLY the handshake? What happens if someone requests a secure web page with 50 references to images over HTTPS? Is that 1 plus 50 = 51 TPS?

Hutch
0
bigdork
Asked:
bigdork
  • 2
  • 2
1 Solution
 
Dave HoweCommented:
yes, that would be 51 transactions. you have to remember that the hard bit is the SSL handshake - you are using large-number math for the certificate validation step, plus for the PFS symmetric key negotiation. by contrast, the actual data traffic is trivial.

TPS is the number of ssl handshakes, regardless of bytes moved.
0
 
bigdorkAuthor Commented:
Dave thanks for the reply. Just to muddy the question a bit - I was under the impression with TCP Multiplexing that those 51 requests/sec are reduced to a smaller number meaning I don't have as many TPS as I do GETS/Sec. The vendors usually have 2 stats they advertise "Reqs/Sec" and "TPS".

Perhaps to beat the horse here - so you are ultimately saying I should evaluate how many Requests/Sec I recieve over HTTPS and that should roughly be Transactions Per Second?

I appreciate it,

Hutch
0
 
Dave HoweCommented:
With TCP Multiplexing then multiple SSL Transactions are initiated to the offloader/balancer, which then opens a single HTTP 1.1 connection to your backend server and serializes the requests from a single IP down that one channel. as this is usually truely http rather than https, this really only saves you one tcp setup/teardown - not to be sneezed at in today's high load environments, but still not a lot. the bulk of the savings are in offloading the crypto overhead onto the balancer. Of course, if the browser itself can handle TCP Multiplexing, then multiple requests may be bundled into a single ssl transaction before they reach the balancer.

in addition, many balancers (such as the F5 "big ip" device) are also caching servers - so for a number of seconds after an initial response for (for example) a gif, further requests for the same image would be satisfied from cache and not pushed forward to your backend content hosts
0
 
bigdorkAuthor Commented:
Thanks Dave - I appreciate your help on my question and also the follow up question on multiplexing as well.
0

Featured Post

 The Evil-ution of Network Security Threats

What are the hacks that forever changed the security industry? To answer that question, we created an exciting new eBook that takes you on a trip through hacking history. It explores the top hacks from the 80s to 2010s, why they mattered, and how the security industry responded.

  • 2
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now