My application interacts with many other HTTPS based services. As we use them at considerable frequency, I am worried about the performance impact of using HTTPS.
Is there any mechanism ( time bound or any other permanent) which I can use to prevent the HTTPS handshake and other potential bottlenecks ?
Ofcourse I do not want to go with HTTP :)
In SSL there are connections, and there are sessions.
A connection starts with a handshake, and ends when either party states it by sending a close_notify alert message. Typical Web browsers and servers will maintain connections open for some time, closing them after one or two minutes of inactivity; one or several HTTP requests and responses are sent over that connection. In normal HTTPS contexts, there is a one-to-one mapping between the SSL connections and the underlying TCP connections: for each TCP connection (to port 443), there will be a single SSL connection, and when the SSL connection ends, the underlying TCP connection is closed.
A session relates to the asymmetric cryptography which occurs in a "full handshake". The handshake process, which occurs at the beginning of a connection, is about establishing the cryptographic algorithms and keys which will be used to protect the data for that connection. There are two sorts of handshakes:
The full handshake is what a client and server do when they don't know each other (they have not talked previously, or that was long ago). In the full handshake, certificates are sent, and asymmetric cryptography (RSA, Diffie-Hellman...) occurs.
The abbreviated handshake is what a client and server remember each other; more accurately, they remember the algorithms and keys that they established in a previous full handshake, and agree to reuse them (technically, they reuse the "master secret" and derive from it fresh encryption keys for this connection).
A connection with a full handshake, and the set of connections with abbreviated handshake who reuse that full handshake, constitute together the session.
The abbreviated handshake is more efficient than the full handshake, because it implies one less network round-trips, smaller handshake messages, and no asymmetric cryptography at all.
For performance, in all generality, you want the following:
Keep connections open as much as possible. An "open connection" uses a few memory resources (both parties must remember the keys) and system resources (for the underlying TCP connection, which is kept open). However, there is no network traffic involved in keeping a connection alive, except possibly the optional "TCP keepalive".
When connections cannot be kept open (e.g. to free system resources), it is best if the client and server remember sessions so that they may do abbreviated handshakes if they reconnect. Web servers have various default and configurable policies. For instance, Apache (with mod_ssl) uses a cache which is defined both for size and for duration; the server "forgets" a session when either its cache is full and it needs some extra room, or when the timeout has been reached, whichever condition occurs first.
If you have control over the servers' configuration, then you may want to increase the "inactivity timeout" for connection termination, and also to increase the session cache size and duration. If you do not have control over the servers, then your question is somewhat moot: whatever you do, it will have to be compatible with what the servers offer. You can somehow force a server not to forget a session by regularly opening a new connection with an abbreviated handshake, but that is not necessarily a good idea (usually, when a server forgets sessions, it is for a more-or-less good reason).
Anyway, you shall make measures. This is a question about performance; abstract reasoning cannot give definitive answers. The usual rule of thumb is that performance issues do not exist until they have been duly measured in real life, or at least in a reasonably representative prototype system.
In any case, it is hard to obtain the same security functionalities of SSL with a smaller cost. Replacing SSL with "something custom" is unlikely to provide much improvement performance-wise without sacrificing security in some way.
For a walk-through of SSL, see this answer. Having some knowledge of the SSL internals really helps a lot in thinking about any design involving SSL.
This should be a comment, since there's not enough information in your question to diagnose the problem / propose a definitive answer, but it's a bit long....
It's rather hard to tel from your question what your application looks like. Are you referring to code running on your server which makes HTTPS calls out to other services or are the calls made from the browser? Are the calls to a predictable, smallish number of servers?
If the client for the HTTPS calls is your aplication code then you'll get big benefits from exploiting keepalive (if supported at the HTTPS server). Depending on how your application works this may mean managing a connection pool (which can be tricky) however some reverse proxies will support this.
Maybe you just need to use the caching information already provided by the HTTPS service - routing the requests via a local caching proxy would help.
Alternatively, if you control the remote services then using a VPN instead of TLS would eliminate the handshake overhead (most of the time).
If the convergence is at the client then it becomes a very different question. If the multiple requests are all/mostly addressed to your servers then the solution might be to enable (distributed) ssl session caching. Certainly you should enable keepalive (I know Ralph Engeschall said you shouldn't do this with mod_ssl and MSIE - but that was a very long time ago - since MSIE7 most of the problems are fixed).
