- From: Brian Pane <brianp@brianp.net>
- Date: Wed, 18 Jul 2012 10:52:40 -0700
- To: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
- Message-ID: <CAAbTgTv70M2KAdQ6Kg8mZLDvXgQfto6+Nm=-xFxsC3qo3X2Hdw@mail.gmail.com>
On Wednesday, July 18, 2012, Roberto Peon wrote: > #1 isn't obvious one way or another. For the first request TLS potentially > harms latency as compared to http/1.1. For subsequent requests it comes out > as better (given application protocol changes). More interestingly, > negotiating http/2 over port 80 will require a round trip, which is the > same latency penalty one will pay for using TLS at a site that you have > recently visited assuming we use false-start. > This is a point that I think is worth highlighting: if browsers use the presence of the NPN extension in the ServerHello to determine whether the server can handle false start, the result is that the latency for TCP+TLS+NPN is no greater than that of TCP+HTTP Upgrade. I believe that's what the latest version of Chrome does. I think it would be useful for the NPN spec to say something like, "If a server does not support False Start, it MUST NOT send the NPN protocol list extension." That would elevate Chrome's current heuristic to a standard. -Brian
Received on Wednesday, 18 July 2012 17:53:14 UTC