I understand your concerns. I'm just surprised that extending the timeout beyond five minutes would make any difference. Surely your app can refresh the connection within 5 mins.
On Mon, Aug 27, 2012 at 3:44 AM, Chaitanya Gupta <[email protected]>wrote: > 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 > -- 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
