W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2012

Re: Review: http://www.ietf.org/id/draft-mbelshe-httpbis-spdy-00.txt

From: Brian Pane <brianp@brianp.net>
Date: Thu, 1 Mar 2012 08:22:55 -0800
Message-ID: <CAAbTgTuAk9dcGENpt532SWpi3BE57pwRMCxy_ZuwKA6BzPjW-g@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 06:51:56 GMT