- From: Willy Tarreau <w@1wt.eu>
- Date: Thu, 1 Mar 2012 08:40:34 +0100
- To: Brian Pane <brianp@brianp.net>
- Cc: ietf-http-wg@w3.org
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.
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.
Regards,
Willy
Received on Thursday, 1 March 2012 07:41:02 UTC