- From: Martin Thomson <martin.thomson@gmail.com>
- Date: Tue, 8 Oct 2013 13:52:24 -0700
- To: William Chan (陈智昌) <willchan@chromium.org>
- Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Mark Nottingham <mnot@mnot.net>, "ietf-http-wg@w3.org WG" <ietf-http-wg@w3.org>
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. 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.
Received on Tuesday, 8 October 2013 20:52:52 UTC