Re: Ascii-based SPDY "compression" idea

------ 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 UTC