How much overhead does SSL impose

Question

I know there s no single hard-and-fast answer  but is there a generic order-of-magnitude estimate approximation for the encryption overhead of SSL versus unencrypted socket communication  I m talking only about the comm processing and wire time  not counting application-level processing   Update  There is a question about HTTPS versus HTTP  but I m interested in looking lower in the stack    I replaced the phrase  order of magnitude  to avoid confusion  I was using it as informal jargon rather than in the formal CompSci sense  Of course if I had meant it formally  as a true geek I would have been thinking binary rather than decimal   -   Update  Per request in comment  assume we re talking about good-sized messages  range of 1k-10k  over persistent connections  So connection set-up and packet overhead are not significant issues

User · Accepted Answer

Order of magnitude  zero   In other words  you won t see your throughput cut in half  or anything like it  when you add TLS  Answers to the  duplicate  question focus heavily on application performance  and how that compares to SSL overhead  This question specifically excludes application processing  and seeks to compare non-SSL to SSL only  While it makes sense to take a global view of performance when optimizing  that is not what this question is asking   The main overhead of SSL is the handshake  That s where the expensive asymmetric cryptography happens  After negotiation  relatively efficient symmetric ciphers are used  That s why it can be very helpful to enable SSL sessions for your HTTPS service  where many connections are made  For a long-lived connection  this  end-effect  isn t as significant  and sessions aren t as useful     Here s an interesting anecdote  When Google switched Gmail to use HTTPS  no additional resources were required  no network hardware  no new hosts  It only increased CPU load by about 1

User · Answer

I second  erickson  The pure data-transfer speed penalty is negligible  Modern CPUs reach a crypto AES throughput of several hundred MBit s  So unless you are on resource constrained system  mobile phone  TLS SSL is fast enough for slinging data around   But keep in mind that encryption makes caching and load balancing much harder  This might result in a huge performance penalty   But connection setup is really a show stopper for many application  On low bandwidth  high packet loss  high latency connections  mobile device in the countryside  the additional roundtrips required by TLS might render something slow into something unusable   For example we had to drop the encryption requirement for access to some of our internal web apps - they where next to unusable if used from china

User · Answer

Assuming you don t count connection set-up  as you indicated in your update   it strongly depends on the cipher chosen  Network overhead  in terms of bandwidth  will be negligible  CPU overhead will be dominated by cryptography  On my mobile Core i5  I can encrypt around 250 MB per second with RC4 on a single core   RC4 is what you should choose for maximum performance   AES is slower  providing  only  around 50 MB s  So  if you choose correct ciphers  you won t manage to keep a single current core busy with the crypto overhead even if you have a fully utilized 1 Gbit line   Edit  RC4 should not be used because it is no longer secure  However  AES hardware support is now present in many CPUs  which makes AES encryption really fast on such platforms    Connection establishment  however  is different  Depending on the implementation  e g  support for TLS false start   it will add round-trips  which can cause noticable delays  Additionally  expensive crypto takes place on the first connection establishment  above-mentioned CPU could only accept 14 connections per core per second if you foolishly used 4096-bit keys and 100 if you use 2048-bit keys   On subsequent connections  previous sessions are often reused  avoiding the expensive crypto   So  to summarize   Transfer on established connection    Delay  nearly none CPU  negligible Bandwidth  negligible   First connection establishment    Delay  additional round-trips Bandwidth  several kilobytes  certificates  CPU on client  medium CPU on server  high   Subsequent connection establishments    Delay  additional round-trip  not sure if one or multiple  may be implementation-dependant  Bandwidth  negligible CPU  nearly none

[performance] How much overhead does SSL impose?

Examples related to performance

Examples related to sockets

Examples related to ssl

Examples related to overhead