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

Re: Ascii-based SPDY "compression" idea

From: Adrien W. de Croy <adrien@qbik.com>
Date: Mon, 02 Apr 2012 20:52:39 +0000
To: "Brian Pane" <brianp@brianp.net>, "Poul-Henning Kamp" <phk@phk.freebsd.dk>
Cc: "ifette@google.com" <ifette@google.com>, ChanWilliam(ι™ˆζ™Ίζ˜Œ) <willchan@chromium.org>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>, "Peter Lepeska" <bizzbyster@gmail.com>
Message-Id: <em65c90590-0f90-4bc3-a975-bfde59342888@boist>

------ Original Message ------
From: "Brian Pane" <brianp@brianp.net>
>
>
>In terms of performance, that's a step backwards from SPDY in two ways:
>
>- An additional round trip is needed to negotiate the use of HTTP/2.0.
>You can't rely on TLS NPN if you're not doing TLS negotiation at the
>outer (TCP connection) level.
>
  
no, it's not an additional RT, it's not wasted, it was a GET, and the 
response can actually be sent back with the upgrade.
  
NPN certainly is nice, but requires TLS with NPN extensions.
  
>
>
>- You'll have to do up to N-1 additional TLS handshakes to get N
>secure streams on that connection.  I say "up to" because the client
>can avoid those handshakes by choosing to wait for TLS negotiation to
>finish on one channel and then use session resumption on the other N-1
>channels...but that means adding 3 RTT of latency to those N-1
>channels (2 RTT for the first channel to do its SSL negotiation, and 1
>more round trip for each additional channel to do session resumption).
>
>
Some of these could be piggy-backed.  But I think the idea is just a 
general mux layer over TCP, so the endpoints would sort it out much the 
same way they do now.
  
An alternative could be 2 connections between peers, 1 with TLS, one 
plain, and route messages accordingly.
  
I'd actually be quite keen to allow for the possibility of responses 
coming back a different connection than they were sent on, but it adds 
some challenges, mainly to do with addressing etc.
  
Adrien
>
>Brian
>
>
>
Received on Monday, 2 April 2012 20:53:06 GMT

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