On Aug 25, 11:38 pm, Mark Hahn <[email protected]> wrote:
> What is the "convincing use case"?
The objective is to reduce latency. Assume that you have a simple
request-response protocol where the client sends a message "Ping" in
response to which the server sends a response "Pong". If client
doesn't have a prior socket open with the server, how many round-trips
does it take before the user can see the response "Pong"?
For plain TCP sockets, it takes about two round trips:
Client Server
SYN -------->
<-------- SYN-ACK
ACK -------->
Ping -------->
<-------- Pong
For a full TLS handshake, it takes about four round trips:
Client Server
SYN -------->
<-------- SYN-ACK
ACK -------->
ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec] -------->
NewSessionTicket
<-------- [ChangeCipherSpec]
Ping -------->
<-------- Pong
For TLS with session resumption, it is three round-trips:
Client Server
SYN -------->
<-------- SYN-ACK
ACK -------->
(SessionTicket extension) -------->
ServerHello
(empty SessionTicket extension)
NewSessionTicket
<-------- [ChangeCipherSpec]
[ChangeCipherSpec] -------->
Ping -------->
<-------- Pong
Now, assume that this ping-pong protocol that you have invented is for
a mobile app. Which means that a lot of your users will be accessing
the app from slow wireless networks like EDGE. From where I live, the
round-trip time (RTT) on an EDGE network to a server in the US varied
between 800-900 ms last morning. This works out to the following
costs just taking into account the RTTs:
Plain TCP: 1.6-1.8s
TLS with handshake: 3.2-3.6s
TLS with resumption: 2.4-2.7s
Nothing beats plain TCP but since we don't want anyone snooping in on
this traffic we have to use TLS. TLS with session resumption is not
great but it is still atleast 800-900 ms faster than TLS with full
handshake. And we haven't even taken into account the bandwidth costs
yet: assuming ~1500 bytes per certificate and a chain of three certs,
on a 70 kbps connection you can add another 0.5 seconds to the cost
for a full TLS handshake (and we have still not looked at
retransmission costs -- 2.5G/3G networks are quite lossy).
Now, the first time a user connects we will have go through the
complete TLS handshake -- we can't avoid it. But subsequently, the
costs reduce greatly. You may ask, instead of trying to reconnect, can
we keep the socket open indefinitely? Sure we can, but if the user is
on an iOS device, the moment he takes the app into background, two
things will happen:
1. Your app gets suspended
2. Your socket can be torn down by the OS at any time
This means that, whenever the user brings your app to the foreground
again, its quite possible that we will need to establish a new socket.
And here we would like to reduce the latency as much as possible.
While the typical user might bring the app into the foreground several
times a day, he would not do so every five minutes.
That is why it would be great if we can extend TLS session timeout.
While the latency costs are not so visible on a fast fixed line
connection, they are very much so on slow wireless networks.
Thanks,
Chaitanya
>
> On Sat, Aug 25, 2012 at 11:18 AM, Satyam Shekhar
> <[email protected]>wrote:
>
>
>
>
>
>
>
> > Hi,
>
> > On Sat, Aug 25, 2012 at 5:22 PM, Ben Noordhuis <[email protected]> wrote:
>
> >> On Sat, Aug 25, 2012 at 10:52 AM, Chaitanya Gupta
> >> <[email protected]> wrote:
> >> > I need to support TLS session resumption in my node.js app. I am
> >> > creating a TLS server usingrequire('tls').createServer(). By default,
> >> > the server has a session ticket lifetime of 300 seconds (as seen with
> >> > OpenSSL's s_client).
>
> >> > I need the session timeout to be beyond 300 seconds. How can I do
> >> > this? I couldn't find anything in node's API docs that could help.
>
> >> Node doesn't let you do that. If you have a convincing use case,
> >> please open an issue and we'll add it.
>
> > I want to contribute this.
>
> > I was thinking of implementing it in one of the following ways -
>
> > 1.
> > i) Take sessionTimeout as an option to createServer
> > ii) Expose a method setTimeout on SecureContext in node_crypto.cc which
> > calls SSL_CTX_set_timeout, and use that to set default session timeout for
> > the context, from the "connection" event callback inside createServer.
>
> > 2.
> > i) Expose setSessionTimeout on CryptoStream in tls.js which again calls
> > setSessionTimeout exposed by Connection in node_crypto.cc. This
> > calls SSL_SESSION_set_timeout to set the timeout for that session. Now, the
> > user can call setSessionTimeout on the exposed CleartextStream to set the
> > timeout.
>
> > What do you think?
>
> > -- satyam
>
> >> --
> >> Job Board:http://jobs.nodejs.org/
> >> Posting guidelines:
> >>https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> >> You received this message because you are subscribed to the Google
> >> Groups "nodejs" group.
> >> To post to this group, send email to [email protected]
> >> To unsubscribe from this group, send email to
> >> [email protected]
> >> For more options, visit this group at
> >>http://groups.google.com/group/nodejs?hl=en?hl=en
>
> > --
> > Job Board:http://jobs.nodejs.org/
> > Posting guidelines:
> >https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> > You received this message because you are subscribed to the Google
> > Groups "nodejs" group.
> > To post to this group, send email to [email protected]
> > To unsubscribe from this group, send email to
> > [email protected]
> > For more options, visit this group at
> >http://groups.google.com/group/nodejs?hl=en?hl=en
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
