How can I optimize SSL session so I can reuse it later (if needed) to improve Client Server performance

Question

I have a server running on Windows Azure here with a large key (link is intended to demonstrate large key in SSL cert). Based on this Security.SE conversation the larger key will be more expensive to setup and tear down from a CPU perspective.

Assuming I'm using a .NET client and a .NET server; what changes should I make (if any) to reduce the overhead of connecting / disconnecting an SSL perspective.

For the purpose of this conversation let's include these scenarios (add more if you can think of them)

• WebBrowser to IIS
• WCF client to WCF Server (IIS)
• WCF client to WCF TCP
• Sockets-based client to Sockets-based server

Answer 1

The cost of an initial handshake is basically fixed (given certain parameters). The cost of a resumed handshake is approximately zero.

The way to improve performance is to increase the amount of sessions that are resumed sessions, and not initial sessions. This amortizes the cost of the initial handshake across the resumed handshakes, reducing the average handshake cost.

The easiest way to increase the resumed handshake rate is to have a larger session cache size/timeout. Of course, having a large session cache can create its own performance issues. One needs to find a good balance between these two, and the best way to do that is with testing.

Answer 2

If the application is made to keep the WCF connections open, it may make sense to enable KeepAlive (it's disabled by default).

The TCP connection will be reused automatically when the keep-alive switch is turned on. For the 'ServicePoint Manager, you can use theSetTcpKeepAlive method to turn on the keep-alive option for a TCP connection. Refer to the following MSDN article:

ServicePointManager.SetTcpKeepAlive Method http://msdn.microsoft.com/en-us/library/system.net.servicepointmanager.settcpkeepalive.aspx

From Microsoft:

Generally the difference, in the perspective of performance, between common HTTP and HTTPS lies in the handshake of a TCP connection. It takes longer time for an HTTPS handshake, than HTTP. However, after the TCP connection is established, their difference is very trivial as a block cipher will be used in this connection. And the difference between a 'very high bit' cert and a common cert is more trivial. We've dealt with a lot of slow performance cases, but we seldom haves cases whose slow-performance problem is caused by more stronger cert, as the network congestion, the CPU high utilization, a large portion of ViewState data etc. are main characters of slow performance.

In the perspective of IIS, notice that in the IIS manager, there will be an option checked by default for a website, as 'Enable HTTP Keep-Alives'. This option ensures that the IIS and the client browser would keep the TCP connection alive for a time for certain HTTP requests. That is to say, for round-trips between an IIS server and the client, only the first request will be obviously slower than others, while the rest won't.

You can refer to following article about this setting: http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/d7e13ea5-4350-497e-ba34-b25c0e9efd68.mspx?mfr=true

Of course, I know for WCF, IIS is not a must to host applications for many scenarios, but on this point, I think they work similarly.