Initial load times with SSL relatively high

[barbar80]

The initial loadtimes for new connections/requests are very high, and it seems that connections are not kept open? After every connection the SSL handshake is done, which usually adds between 40 to 100ms per request, even running everything from localhost.

Are there settings that can improve this? Typically a SSL connection is negotiated once, and used for several minutes, drastically cutting down on request times. Is this special behavior that can be added somewhere?

[justcoding121]

Currently for each client connection we create a new connection to server, and then it is used until client or server terminates the connection.

I think reusing existing connections/preemptively creating connections to server sounds like an idea, but not sure how exactly it should be implemented.

[barbar80]

Thanks for your reply. I noticed that when I have one endpoint with a generic certificate set, the initial connection setup happens much faster than with two endpoints and only one root certificate. I will see if I can find why that is. It seems the certificates might not be cached correctly, resulting in new certificate signing every time.

[chancity]

Not to hijack the issue. This might be relevant.

I currently have 400k plus connection (between 8 instances of titanium proxy) transversing through titanium proxy. After running for 15 minutes or so all the new https clients receive a tcp reset and the proxy has to be restarted.

The clients are only allowed to connect to a single https website.

[justcoding121]

@chancity That sounds like a serious problem. Do you see any specific exceptions? Does memory usage looks okay when this occur?

[justcoding121]

Also does this occur with less number of connections?

[chancity]

@justcoding121 I haven't tried to debug anything yet. I created a workaround, but I can set up a test environment this weekend. Send me a message on skype "chancey.hawbaker".

Edit: -No exceptions because I haven't tried to debug the issue. -Memory usage is on the high side ~1gb

[justcoding121]

I will have to re look the code first for issues with TCP connection close, error handling and GC. After that may be it would be easy to debug.

[justcoding121]

@aricih In case you found any issues specific to memory leaks or connection not closed properly, appreciate your input.

[justcoding121]

@chancity Would appreciate if you can give a try now on latest release. There was a major bug in connection reuse we just fixed.

[chancity]

@justcoding121 I'll try it out right now

[chancity]

@justcoding121 Memory usage is still creeping up. I haven't had any SSL issues yet. I'll check in again in about 60 minutes.

Edit 1-

There are a lot of inactive connections when viewing netstat -an (TIME_WAIT, CLOSE_WAIT). Also, the windows state table never decreases in connections, only increases. No SSL issues after 90 minutes of running and memory usage at 1.6GB and climbing.

Edit 2 - Server connection count is going negative Console.WriteLine("Active Server Connections:" + ((ProxyServer)sender).ServerConnectionCount);

[chancity]

memory usage is way better on the new stable release.

[justcoding121]

I noticed that .Net core version of the project is much faster for Ssl negotiation, and further researching I think the PCL version of BouncyCastle made the difference. So I am making it as the default Certification Generation library for .Net 4.5 as well instead of COM interop calls.