SSL negotiation starts with client hello and finished with CipherSpec Change. The handShake has 2 mechanisms: Full handshake vs. Abbreviated handshake (RFC 2246)
The difference is abbreviated handshake is using 32 bit existing SSL session ID for Client Hello. If SSL server agreed on this session, server doesn't need to send the public key of certificate back to client. Also, client doesn't need to take time to validate the server cert as it is an existing session. If server doesn't agree on the SSL session, server needs to push a new session ID and then go to full handshake.
Here is the table for the time SSL session been cached:
|Windows NT 4.0 SP6a||2 minutes||2 minutes|
|Windows NT 4.0 SP6a||60 minutes||5 minutes|
|Windows 2000 SP1||2 minutes||2 minutes|
|Windows 2000 SP2||10 hours||10 hours|
|Windows XP or After||10 hours||10 hours|
If SSL server side doesn't understand the abbreviated SSL handshake and doesn't handle it correctly, you may see some random issue for SSL connection drop. Framework System.Net trace or Network sniffer trace can help to identify whether the current SSL handshake is trying to go through cached session. The key difference is: no certificate payload in server hello message.
Windows gives the choice for disable SSL cache session reuse through Reg Key.
ClientCacheTime is DWORD in millisecond unit. When you set the key as 0 and reboot machine, SSL cached session will not be reused.