Re: New Version Notification for draft-nottingham-http2-encryption-00.txt

On Tue, Oct 8, 2013 at 1:52 PM, Martin Thomson <martin.thomson@gmail.com>wrote:

> On 8 October 2013 13:44, William Chan (陈智昌) <willchan@chromium.org> wrote:
> > I can tell you that before I implemented this racing for Chromium, we
> > definitely noticed the perf hit, which is why I implemented it.
>
> I'd be interested in learning under what conditions a round trip
> followed by the improved parallelism of HTTP/2 is still worse than
> having to wait for new connections to be established in HTTP/1.1.  I
> know that browsers tend to aggressively open multiple connections as
> soon as they see a need for a connection to a host, but at some point
> parallelism you are going to be paying round trips for connection
> setup anyway.
>

I'm not sure what details I'm able to provide, but speaking vaguely, a
vendor deployed SPDY by putting a reverse proxy in front of the normal
origin server and adding Alternate-Protocol. And then asked why it made
things slower. Upon analysis, we traced the cause to this mechanism. SPDY's
multiplexing improved the rest of the page load (and the next page
navigations), but the initial cold page load did suffer a hit.


>
> Note also that we're talking about paying round trips to get TLS live
> anyway.  So this IS going to hurt performance.  And, in many cases,
> I'd have to assume that the security guarantees required for
> /index.html are going to need to be higher than those around /foo.jpg.
>  I don't want to get into a position where we secure just the
> uninteresting stuff.
>

I appreciate the comment and just want to emphasize that I am only sharing
previous experience with a similar method to the proposed I-D. My intent
was not to judge, but just to share information. It's not clear to me what
the exact goals of the I-D are, but I hope that the information I provided
can help guide discussion around the tradeoffs between performance and
security.