You are viewing a plain text version of this content. The canonical link for it is here.
Posted to soap-dev@ws.apache.org by Leif Nilsson TACMa <le...@tac.se> on 2002/07/04 15:03:20 UTC
Reusing SSL-sessions...
Hi,
Is there a way to reuse the SSL-session for several SOAP-Calls ?
As I've stated before it seems that soap over SSL sooner or later just
fails. By activating the system property javax.net.debug (JSSE)
it is clear that two independant sessions are created for each
Call/SOAPHttpConnection.
As the call fails it is the response that fails (at least those times I've
captured). Somewhere
in between ClientHello and ServerHello for the response the SOAP client just
assumes there is
an answer but there is none so the client SOAP exception for "no
http-status" is raised.
I don't think controlling the sessions would solve the problem (although it
might be less frequent)
but I suspect it would be beneficial from a performance point of view.
/Leif
Leif Nilsson
Software Engineer
TAC AB
Jägershillgatan 18
SE-213 75 Malmö, Sweden
Direct +46 40 38 69 56
Fax +46 40 21 82 87
Mobile +46 xx xxx xx xx
www.tac-global.com
This email is intended only for the use of the individual or entity to whom
it is addressed. It may contain information that is privileged, confidential
or otherwise protected from disclosure under applicable law. If you have
received this transmission in error, please delete it immediately and notify
me by mailing me.
Re: Reusing SSL-sessions...
Posted by Niclas Hedhman <ni...@ewarna.com>.
On Sunday 07 July 2002 07:45, Sanjiva Weerawarana wrote:
> Hi Scott,
>
> Thanks for the useful experiment. It seems to me that if we were
> to implement HTTP 1.1 keep-alive then this problem would go away,
> right? That is, if the same TCP connection is used for a series
> of requests then not its not an issue, right?
>
> I wonder how browsers do it- when I'm using my Internet banking
> stuff does it keep re-negotiating keys?? Or does it keep a single
> socket connection open for the 30 mins say that I'm using it. The
> latter seems extremely resource heavy on the server.
The "former" sounds a lot more resource (CPU + network) heavy for the server.
The "latter" is heavy on memory only, which is cheap nowadays.
The "banking application" is most probably not negoatiating the keys, since
that is something network intensive (something like 3 rounds of TCP traffic).
Since SSL sits on top of TCP, it is only two issues on memory and network
resources.
1. The connection itself stays alive and the server will not "share"
connections between requests so to speak. The server probably have other
scalability problems before running out of connections, so that is probably
not an issue either.
2. The SSL takes up some memory, maybe as much as a couple of 10Ks (I think
more like a couple of Ks), so on a 10000 connected users, they have to throw
in an extra couple of 100Ms. Probably acceptable as well.
Niclas
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
Re: Reusing SSL-sessions...
Posted by Niclas Hedhman <ni...@ewarna.com>.
On Sunday 07 July 2002 07:45, Sanjiva Weerawarana wrote:
> Hi Scott,
>
> Thanks for the useful experiment. It seems to me that if we were
> to implement HTTP 1.1 keep-alive then this problem would go away,
> right? That is, if the same TCP connection is used for a series
> of requests then not its not an issue, right?
>
> I wonder how browsers do it- when I'm using my Internet banking
> stuff does it keep re-negotiating keys?? Or does it keep a single
> socket connection open for the 30 mins say that I'm using it. The
> latter seems extremely resource heavy on the server.
The "former" sounds a lot more resource (CPU + network) heavy for the server.
The "latter" is heavy on memory only, which is cheap nowadays.
The "banking application" is most probably not negoatiating the keys, since
that is something network intensive (something like 3 rounds of TCP traffic).
Since SSL sits on top of TCP, it is only two issues on memory and network
resources.
1. The connection itself stays alive and the server will not "share"
connections between requests so to speak. The server probably have other
scalability problems before running out of connections, so that is probably
not an issue either.
2. The SSL takes up some memory, maybe as much as a couple of 10Ks (I think
more like a couple of Ks), so on a 10000 connected users, they have to throw
in an extra couple of 100Ms. Probably acceptable as well.
Niclas
Re: Reusing SSL-sessions...
Posted by Scott Nichol <sn...@scottnichol.com>.
> Thanks for the useful experiment. It seems to me that if we were
> to implement HTTP 1.1 keep-alive then this problem would go away,
> right? That is, if the same TCP connection is used for a series
> of requests then not its not an issue, right?
I altered the sample I was running to include a Connection: Keep-Alive
header. The server (www.verisign.com) responds with a Connection: close
header. I don't know whether this is typical for public commercial servers
running SSL, of course, but it does remind us that at least some hosts will
not enable keep-alive processing.
> I wonder how browsers do it- when I'm using my Internet banking
> stuff does it keep re-negotiating keys?? Or does it keep a single
> socket connection open for the 30 mins say that I'm using it. The
> latter seems extremely resource heavy on the server.
I would like to know this as well. I have tested IE 5.5 and Mozilla 1.0 to
a mutual fund company and found that connections are not being re-used.
Since I cannot see the decrypted data, I cannot tell whether there was some
attempt on the part of the browser to use keep-alive. What I'd really like
to know is whether each connection has re-used the SSL session created for
the first connection.
Scott Nichol
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
Re: Reusing SSL-sessions...
Posted by Scott Nichol <sn...@scottnichol.com>.
> Thanks for the useful experiment. It seems to me that if we were
> to implement HTTP 1.1 keep-alive then this problem would go away,
> right? That is, if the same TCP connection is used for a series
> of requests then not its not an issue, right?
I altered the sample I was running to include a Connection: Keep-Alive
header. The server (www.verisign.com) responds with a Connection: close
header. I don't know whether this is typical for public commercial servers
running SSL, of course, but it does remind us that at least some hosts will
not enable keep-alive processing.
> I wonder how browsers do it- when I'm using my Internet banking
> stuff does it keep re-negotiating keys?? Or does it keep a single
> socket connection open for the 30 mins say that I'm using it. The
> latter seems extremely resource heavy on the server.
I would like to know this as well. I have tested IE 5.5 and Mozilla 1.0 to
a mutual fund company and found that connections are not being re-used.
Since I cannot see the decrypted data, I cannot tell whether there was some
attempt on the part of the browser to use keep-alive. What I'd really like
to know is whether each connection has re-used the SSL session created for
the first connection.
Scott Nichol
Re: Reusing SSL-sessions...
Posted by Sanjiva Weerawarana <sa...@watson.ibm.com>.
Hi Scott,
Thanks for the useful experiment. It seems to me that if we were
to implement HTTP 1.1 keep-alive then this problem would go away,
right? That is, if the same TCP connection is used for a series
of requests then not its not an issue, right?
I wonder how browsers do it- when I'm using my Internet banking
stuff does it keep re-negotiating keys?? Or does it keep a single
socket connection open for the 30 mins say that I'm using it. The
latter seems extremely resource heavy on the server.
Bye,
Sanjiva.
----- Original Message -----
From: "Scott Nichol" <sn...@scottnichol.com>
To: <so...@xml.apache.org>
Sent: Saturday, July 06, 2002 9:45 AM
Subject: Re: Reusing SSL-sessions...
> Here are some results I got looking into SSL sessions. Using JDK 1.3.1_01
> with JSSE 1.0.3 on Win2k, I changed the SSLSocketClient sample to loop 10
> times. I ran the app with -Djavax.net.debug=ssl,handshake,session. The
> debug output showed that a total of 6 sessions were created to perform the
> 10 loops. Sometimes when the client tried to resume a session, the
session
> was resumed. Sometimes, the server forced a new session to start.
> Sometimes, the client said "no cached client session". I removed the
> startHandshake call and re-ran the test. This time a total of 5 sessions
> were created to perform the 10 loops, but I would guess that the different
> between the 6 result and the 5 result is pretty random (I will re-run the
> tests).
>
> Having never written my own SSL client or analyzed the operation of one
> before, I do not know if this is "normal". However, since I am seeing new
> sessions created when executing this simple piece of code, I am not
> surprised that new sessions are being created when running Apache SOAP
over
> SSL.
>
> Scott Nichol
>
>
>
> --
> To unsubscribe, e-mail: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
Re: Reusing SSL-sessions...
Posted by Sanjiva Weerawarana <sa...@watson.ibm.com>.
Hi Scott,
Thanks for the useful experiment. It seems to me that if we were
to implement HTTP 1.1 keep-alive then this problem would go away,
right? That is, if the same TCP connection is used for a series
of requests then not its not an issue, right?
I wonder how browsers do it- when I'm using my Internet banking
stuff does it keep re-negotiating keys?? Or does it keep a single
socket connection open for the 30 mins say that I'm using it. The
latter seems extremely resource heavy on the server.
Bye,
Sanjiva.
----- Original Message -----
From: "Scott Nichol" <sn...@scottnichol.com>
To: <so...@xml.apache.org>
Sent: Saturday, July 06, 2002 9:45 AM
Subject: Re: Reusing SSL-sessions...
> Here are some results I got looking into SSL sessions. Using JDK 1.3.1_01
> with JSSE 1.0.3 on Win2k, I changed the SSLSocketClient sample to loop 10
> times. I ran the app with -Djavax.net.debug=ssl,handshake,session. The
> debug output showed that a total of 6 sessions were created to perform the
> 10 loops. Sometimes when the client tried to resume a session, the
session
> was resumed. Sometimes, the server forced a new session to start.
> Sometimes, the client said "no cached client session". I removed the
> startHandshake call and re-ran the test. This time a total of 5 sessions
> were created to perform the 10 loops, but I would guess that the different
> between the 6 result and the 5 result is pretty random (I will re-run the
> tests).
>
> Having never written my own SSL client or analyzed the operation of one
> before, I do not know if this is "normal". However, since I am seeing new
> sessions created when executing this simple piece of code, I am not
> surprised that new sessions are being created when running Apache SOAP
over
> SSL.
>
> Scott Nichol
>
>
>
> --
> To unsubscribe, e-mail: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
Re: Reusing SSL-sessions...
Posted by Scott Nichol <sn...@scottnichol.com>.
Here are some results I got looking into SSL sessions. Using JDK 1.3.1_01
with JSSE 1.0.3 on Win2k, I changed the SSLSocketClient sample to loop 10
times. I ran the app with -Djavax.net.debug=ssl,handshake,session. The
debug output showed that a total of 6 sessions were created to perform the
10 loops. Sometimes when the client tried to resume a session, the session
was resumed. Sometimes, the server forced a new session to start.
Sometimes, the client said "no cached client session". I removed the
startHandshake call and re-ran the test. This time a total of 5 sessions
were created to perform the 10 loops, but I would guess that the different
between the 6 result and the 5 result is pretty random (I will re-run the
tests).
Having never written my own SSL client or analyzed the operation of one
before, I do not know if this is "normal". However, since I am seeing new
sessions created when executing this simple piece of code, I am not
surprised that new sessions are being created when running Apache SOAP over
SSL.
Scott Nichol
Re: Reusing SSL-sessions...
Posted by Scott Nichol <sn...@scottnichol.com>.
Here are some results I got looking into SSL sessions. Using JDK 1.3.1_01
with JSSE 1.0.3 on Win2k, I changed the SSLSocketClient sample to loop 10
times. I ran the app with -Djavax.net.debug=ssl,handshake,session. The
debug output showed that a total of 6 sessions were created to perform the
10 loops. Sometimes when the client tried to resume a session, the session
was resumed. Sometimes, the server forced a new session to start.
Sometimes, the client said "no cached client session". I removed the
startHandshake call and re-ran the test. This time a total of 5 sessions
were created to perform the 10 loops, but I would guess that the different
between the 6 result and the 5 result is pretty random (I will re-run the
tests).
Having never written my own SSL client or analyzed the operation of one
before, I do not know if this is "normal". However, since I am seeing new
sessions created when executing this simple piece of code, I am not
surprised that new sessions are being created when running Apache SOAP over
SSL.
Scott Nichol
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
Re: Reusing SSL-sessions...
Posted by Scott Nichol <sn...@scottnichol.com>.
>>>>
Is there a way to reuse the SSL-session for several SOAP-Calls ?
As I've stated before it seems that soap over SSL sooner or later just
fails. By activating the system property javax.net.debug (JSSE)
it is clear that two independant sessions are created for each
Call/SOAPHttpConnection.
<<<<
I just looked at SSLUtils for the first time. It calls startHandshake on
the socket for each connection. I don't quite understand why: the comment
mentions PrintWriter and exceptions, but PrintWriter is not used in
HttpUtils, where the packets are written and read. I will look into this.
>>>>
As the call fails it is the response that fails (at least those times I've
captured). Somewhere
in between ClientHello and ServerHello for the response the SOAP client just
assumes there is
an answer but there is none so the client SOAP exception for "no
http-status" is raised.
<<<<
This sounds bad. There may be a bug in the SSL implementation: too bad Sun
does not provide source for us to look at.
>>>>
I don't think controlling the sessions would solve the problem (although it
might be less frequent)
but I suspect it would be beneficial from a performance point of view.
<<<<
I agree. When I get a chance, I will research startHandshake and possibly
remove it and test the result locally. However, please understand that any
change I might make will be in a release after 2.3.1, so if you are limited
to using version 2.2, it won't help you.
Scott Nichol
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
Re: Reusing SSL-sessions...
Posted by Scott Nichol <sn...@scottnichol.com>.
>>>>
Is there a way to reuse the SSL-session for several SOAP-Calls ?
As I've stated before it seems that soap over SSL sooner or later just
fails. By activating the system property javax.net.debug (JSSE)
it is clear that two independant sessions are created for each
Call/SOAPHttpConnection.
<<<<
I just looked at SSLUtils for the first time. It calls startHandshake on
the socket for each connection. I don't quite understand why: the comment
mentions PrintWriter and exceptions, but PrintWriter is not used in
HttpUtils, where the packets are written and read. I will look into this.
>>>>
As the call fails it is the response that fails (at least those times I've
captured). Somewhere
in between ClientHello and ServerHello for the response the SOAP client just
assumes there is
an answer but there is none so the client SOAP exception for "no
http-status" is raised.
<<<<
This sounds bad. There may be a bug in the SSL implementation: too bad Sun
does not provide source for us to look at.
>>>>
I don't think controlling the sessions would solve the problem (although it
might be less frequent)
but I suspect it would be beneficial from a performance point of view.
<<<<
I agree. When I get a chance, I will research startHandshake and possibly
remove it and test the result locally. However, please understand that any
change I might make will be in a release after 2.3.1, so if you are limited
to using version 2.2, it won't help you.
Scott Nichol
Re: Reusing SSL-sessions...
Posted by Sanjiva Weerawarana <sa...@watson.ibm.com>.
Did you mean to say "timeout the connection" and not "timeout
the session"?? If you did mean it, you're mixing session support
and keep-alive support. Apache SOAP does not have keep-alive
support, but it does have HTTP session support.
What I described is the mechanism to use HTTP session support.
Sanjiva.
----- Original Message -----
From: "Niclas Hedhman" <ni...@ewarna.com>
To: <so...@xml.apache.org>
Sent: Friday, July 05, 2002 7:32 AM
Subject: Re: Reusing SSL-sessions...
> On Thursday 04 July 2002 23:50, Sanjiva Weerawarana wrote:
> > You should just re-use the Call object to hold a session. See
> > the addressbook2 sample for an example.
>
> And I assume that if you don't do a call within a reasonable time period,
it
> will timeout the connection.
>
> Niclas
>
> --
> To unsubscribe, e-mail: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
Re: Reusing SSL-sessions...
Posted by Scott Nichol <sn...@scottnichol.com>.
I would think any timeout would be set on the server, specifically a session
timeout, the length of which is probably configurable.
Scott Nichol
----- Original Message -----
From: "Niclas Hedhman" <ni...@ewarna.com>
To: <so...@xml.apache.org>
Sent: Thursday, July 04, 2002 9:32 PM
Subject: Re: Reusing SSL-sessions...
> On Thursday 04 July 2002 23:50, Sanjiva Weerawarana wrote:
> > You should just re-use the Call object to hold a session. See
> > the addressbook2 sample for an example.
>
> And I assume that if you don't do a call within a reasonable time period,
it
> will timeout the connection.
>
> Niclas
>
> --
> To unsubscribe, e-mail: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
>
>
Re: Reusing SSL-sessions...
Posted by Sanjiva Weerawarana <sa...@watson.ibm.com>.
Did you mean to say "timeout the connection" and not "timeout
the session"?? If you did mean it, you're mixing session support
and keep-alive support. Apache SOAP does not have keep-alive
support, but it does have HTTP session support.
What I described is the mechanism to use HTTP session support.
Sanjiva.
----- Original Message -----
From: "Niclas Hedhman" <ni...@ewarna.com>
To: <so...@xml.apache.org>
Sent: Friday, July 05, 2002 7:32 AM
Subject: Re: Reusing SSL-sessions...
> On Thursday 04 July 2002 23:50, Sanjiva Weerawarana wrote:
> > You should just re-use the Call object to hold a session. See
> > the addressbook2 sample for an example.
>
> And I assume that if you don't do a call within a reasonable time period,
it
> will timeout the connection.
>
> Niclas
>
> --
> To unsubscribe, e-mail: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
Re: Reusing SSL-sessions...
Posted by Scott Nichol <sn...@scottnichol.com>.
I would think any timeout would be set on the server, specifically a session
timeout, the length of which is probably configurable.
Scott Nichol
----- Original Message -----
From: "Niclas Hedhman" <ni...@ewarna.com>
To: <so...@xml.apache.org>
Sent: Thursday, July 04, 2002 9:32 PM
Subject: Re: Reusing SSL-sessions...
> On Thursday 04 July 2002 23:50, Sanjiva Weerawarana wrote:
> > You should just re-use the Call object to hold a session. See
> > the addressbook2 sample for an example.
>
> And I assume that if you don't do a call within a reasonable time period,
it
> will timeout the connection.
>
> Niclas
>
> --
> To unsubscribe, e-mail: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
>
>
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
Re: Reusing SSL-sessions...
Posted by Niclas Hedhman <ni...@ewarna.com>.
On Thursday 04 July 2002 23:50, Sanjiva Weerawarana wrote:
> You should just re-use the Call object to hold a session. See
> the addressbook2 sample for an example.
And I assume that if you don't do a call within a reasonable time period, it
will timeout the connection.
Niclas
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>
Re: Reusing SSL-sessions...
Posted by Niclas Hedhman <ni...@ewarna.com>.
On Thursday 04 July 2002 23:50, Sanjiva Weerawarana wrote:
> You should just re-use the Call object to hold a session. See
> the addressbook2 sample for an example.
And I assume that if you don't do a call within a reasonable time period, it
will timeout the connection.
Niclas
Re: Reusing SSL-sessions...
Posted by Sanjiva Weerawarana <sa...@watson.ibm.com>.
You should just re-use the Call object to hold a session. See
the addressbook2 sample for an example.
Sanjiva.
----- Original Message -----
From: "Leif Nilsson TACMa" <le...@tac.se>
To: <so...@xml.apache.org>
Sent: Thursday, July 04, 2002 7:03 PM
Subject: Reusing SSL-sessions...
> Hi,
>
> Is there a way to reuse the SSL-session for several SOAP-Calls ?
>
> As I've stated before it seems that soap over SSL sooner or later just
> fails. By activating the system property javax.net.debug (JSSE)
> it is clear that two independant sessions are created for each
> Call/SOAPHttpConnection.
>
> As the call fails it is the response that fails (at least those times I've
> captured). Somewhere
> in between ClientHello and ServerHello for the response the SOAP client
just
> assumes there is
> an answer but there is none so the client SOAP exception for "no
> http-status" is raised.
>
> I don't think controlling the sessions would solve the problem (although
it
> might be less frequent)
> but I suspect it would be beneficial from a performance point of view.
>
> /Leif
>
> Leif Nilsson
> Software Engineer
>
> TAC AB
> Jägershillgatan 18
> SE-213 75 Malmö, Sweden
> Direct +46 40 38 69 56
> Fax +46 40 21 82 87
> Mobile +46 xx xxx xx xx
> www.tac-global.com
>
> This email is intended only for the use of the individual or entity to
whom
> it is addressed. It may contain information that is privileged,
confidential
> or otherwise protected from disclosure under applicable law. If you have
> received this transmission in error, please delete it immediately and
notify
> me by mailing me.
>
>
>
> --
> To unsubscribe, e-mail: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
Re: Reusing SSL-sessions...
Posted by Sanjiva Weerawarana <sa...@watson.ibm.com>.
You should just re-use the Call object to hold a session. See
the addressbook2 sample for an example.
Sanjiva.
----- Original Message -----
From: "Leif Nilsson TACMa" <le...@tac.se>
To: <so...@xml.apache.org>
Sent: Thursday, July 04, 2002 7:03 PM
Subject: Reusing SSL-sessions...
> Hi,
>
> Is there a way to reuse the SSL-session for several SOAP-Calls ?
>
> As I've stated before it seems that soap over SSL sooner or later just
> fails. By activating the system property javax.net.debug (JSSE)
> it is clear that two independant sessions are created for each
> Call/SOAPHttpConnection.
>
> As the call fails it is the response that fails (at least those times I've
> captured). Somewhere
> in between ClientHello and ServerHello for the response the SOAP client
just
> assumes there is
> an answer but there is none so the client SOAP exception for "no
> http-status" is raised.
>
> I don't think controlling the sessions would solve the problem (although
it
> might be less frequent)
> but I suspect it would be beneficial from a performance point of view.
>
> /Leif
>
> Leif Nilsson
> Software Engineer
>
> TAC AB
> Jägershillgatan 18
> SE-213 75 Malmö, Sweden
> Direct +46 40 38 69 56
> Fax +46 40 21 82 87
> Mobile +46 xx xxx xx xx
> www.tac-global.com
>
> This email is intended only for the use of the individual or entity to
whom
> it is addressed. It may contain information that is privileged,
confidential
> or otherwise protected from disclosure under applicable law. If you have
> received this transmission in error, please delete it immediately and
notify
> me by mailing me.
>
>
>
> --
> To unsubscribe, e-mail: <ma...@xml.apache.org>
> For additional commands, e-mail: <ma...@xml.apache.org>
--
To unsubscribe, e-mail: <ma...@xml.apache.org>
For additional commands, e-mail: <ma...@xml.apache.org>