> From: owner-openssl-us...@openssl.org On Behalf Of Prabhat Puroshottam > Sent: Tuesday, December 02, 2014 07:04
> We have a product which uses OpenSSL to connect and transfer > application level data. There are two ways to connect, and get the > application level data from *Agent* to *Client* > > 1. Client (C/C++) -> Agent (C/C++) > 2. Client (C/C++) -> Proxy Server (Java) -> Agent (C/C++) > > *Client* and *Agent* are implemented in C, while *Proxy Server* uses Java > code (This shouldn't really matter). But might be helpful for you to know. > The issue is, connecting *Client* to *Agent* is very fast (that is relatively). > While connecting *Client* to *Proxy Server* is very slow - that is orders of > magnitudes slow. > > I was trying to determine the root cause. From my analysis is appears that, > maximum time on the *Client* side is taken by SSL_Connect during > connection > establishment, while the actual application level data transfer takes very > small time. Similarly, on the *Proxy Server* side (Java Code), maximum > time > is taken in the first read/write whichever happens first. Further, I don't Both the OpenSSL and Java (SSLSocket) APIs have the feature that you can do the handshake explicitly (SSL_connect/accept or .startHandshake) or implicitly on the first read or write (set_connect/accept_state, default). It appears you use explicit in Client but implicit in Proxy. This is valid but may be confusing if you don't keep it firmly in mind. > think this is a network latency issue, as the problem is very pronounced > and all the three boxes are on the same network. Also, the *Client* code > seems to be similar, whether we connect to *Agent* (method 1 above) or > *Proxy Server* (method 2 above). So, the issue is with *Proxy Server*, > IMHO. > It does look like that, see below. And Proxy is Java not OpenSSL, which somewhat reduces the suitability of this group to help. > To further locate the issue, I did some tests using ssldump command, <snip long data> > As you can see the big time difference between the two executions - which > actually involve the same application level data. The largest chunk of On the trace of Client-Proxy connection, once the (delayed) handshake completes Proxy sends some initial data to Client without waiting for data from Client, but Client-Server doesn't. That is not quite the same. > time is spent waiting for handshake from *Proxy Server*. The response time > of *Proxy Server* in replying back with ServerHello, varies greatly > between 1.5 to 11 seconds across different runs. In the present case it is > nearly 3.3 seconds - which IMO is not acceptable. > Yes ServerHello is nearly all of your delay, and that is in Proxy. What does Proxy code do between accepting on the [SSL]ServerSocket (which is Java's way of representing the listen-ing socket) and the first read or write -- apparently write? One particular thing, is it using BufferedReader/Writer on the socket streams? Java code often does buffered because it is more efficient than going to OS each time (at least for real I/O rather than ByteArray Streams). In that case for output you need .flush() to actually send. Or you could try doing .startHandshake() explicitly as soon as convenient after the .accept() and see what difference that makes (although it may only move the problem elsewhere). ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
