- From: Brian Pane <brianp@brianp.net>
- Date: Thu, 1 Mar 2012 08:22:55 -0800
- To: Willy Tarreau <w@1wt.eu>
- Cc: ietf-http-wg@w3.org
On Wed, Feb 29, 2012 at 11:40 PM, Willy Tarreau <w@1wt.eu> wrote: > On Wed, Feb 29, 2012 at 07:52:04PM -0800, Brian Pane wrote: >> On Wed, Feb 29, 2012 at 5:40 PM, Amos Jeffries <squid3@treenet.co.nz> wrote: >> > On 01.03.2012 13:39, Mike Belshe wrote: >> >> >> >> If the protocol is allowed to be slower than HTTP/1.1, then you could do >> >> this. But, a lot of server operators that care about performance aren't >> >> going to want to take that hit. >> > >> > >> > That is what bothers me about all the arguments against Upgrade: based on >> > extra RTT and lag. >> > >> > today: HTTP/1.1 request + HTTP/1.1 response == 1 RTT >> > >> > versus >> > >> > tomorrow: HTTP/1.1 request /w Upgrade header + XYZ response /w 200 status >> > prefix == 1 RTT >> >> I use a different comparison: >> >> HTTP/1.1 today: >> TCP handshake: 1 RTT >> HTTP/1.1 request for resource 1: 1 RTT >> Total == 2 RTT >> ...meanwhile, the same thing happens on m-1 other connections that the >> browser is using in parallel >> >> HTTP/1.1 with Upgrade to 2.0: >> TCP handshake: 1 RTT >> HTTP/1.1. request for resource 1: 1 RTT >> HTTP/2.0 requests for resources 2, ..., n-1, n: 1 RTT >> Total == 3 RTT > > No this one above is wrong. You're still at 2 RTT for HTTP/2.0 with > Upgrade : > > HTTP/1.1 with Upgrade to 2.0: > TCP SYN -----------------------> > <----------------------- TCP SYN/ACK => 1 RTT > HTTP/1.1 GET+Upgrade ----------> > <---------------------- HTTP/1.1 101+Upgrade > <---------------------- HTTP/2.0 200 response => 1 RTT > > Total = 2 RTT. Doesn't change anything compared to 1.1. You're omitting something fundamental. In your example, a single request is finished after 2 RTT, but the remaining m-1 requests take an additional round trip. > To be precise, the only difference is that the sender has > to emit "Upgrade: HTTP/2.0" in the first request and that > the server prepends an intermediate response "HTTP/1.1 101" > followed by "Upgrade: HTTP/2.0". It's just a few extra bytes > in the first connection setting up. There's a much bigger difference: if the client starts with HTTP/1.1, it can only issue one request on the connection and must wait at least 1 RTT for the server to respond to that request before the client can begin to issue HTTP/2.0 requests. That puts an Upgrade-based approach at a disadvantage compared to connections that start out talking SPDY. -Brian
Received on Thursday, 1 March 2012 16:23:27 UTC