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

On Thu, Mar 01, 2012 at 08:22:55AM -0800, Brian Pane wrote:
> 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.

This is already the case with HTTP. If you enable pipelining, you'll notice
that the first connection only has one object. The first thing that comes to
mind is that you'd like the browser to know that the server supports pipelining
and it should send more requests at once. But in fact in order to know what to
ask for, the browser first needs to retrieve the object to discover what's
referenced there. So performing only one request in the first round trip of
a connection is not a showstopper and what happens most of the time already
for the first connection. Parallel connections generally see several pipelined
requests but we should not need those parallel connections with something like
SPDY.

Regards,
Willy

Received on Thursday, 1 March 2012 16:34:52 UTC