- From: Nico Williams <nico@cryptonector.com>
- Date: Wed, 8 Jun 2011 17:30:16 -0500
- To: Breno de Medeiros <breno@google.com>
- Cc: Tim <tim-projects@sentinelchicken.org>, OAuth WG <oauth@ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>, "apps-discuss@ietf.org" <apps-discuss@ietf.org>, "http-state@ietf.org" <http-state@ietf.org>
On Wed, Jun 8, 2011 at 5:26 PM, Breno de Medeiros <breno@google.com> wrote: > On Tue, Jun 7, 2011 at 17:07, Nico Williams <nico@cryptonector.com> wrote: >> Here's another issue: some of you are saying that an application using >> this extension will be using TLS for some things but not others, which >> presumes a TLS session. Does using TLS _with_ session resumption >> _and_ HTTP/1.1 pipelining for all requests really cost that much more >> in latency and compute (and electric) power than the proposed >> alternative? I seriously doubt it, and I'd like to see some real >> analysis showing that I'm wrong before I'd accept such a rationale for >> this sort of proposal. > > Google has performed detailed analysis of SSL performance after > several optimizations and we have concluded that the answer is 'no > significant overhead' as you suggest. Indeed, in some workload > situations it may be actually cheaper to serve SSL traffic because > there is reduction in network latency by avoiding bad proxies. We have > published some results here: > http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html Sweet! Thanks for confirming my intuition, and then some. I like the idea that using TLS actually reduces latency -- I'd not have imagined it. Nico --
Received on Wednesday, 8 June 2011 22:30:41 UTC