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

Re: Ascii-based SPDY "compression" idea

From: Brian Pane <brianp@brianp.net>
Date: Mon, 2 Apr 2012 08:10:38 -0700
Message-ID: <CAAbTgTs55FmKP+HOKhNOz-q_SY1cBec7XLpxqruhFN-+TxtieA@mail.gmail.com>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>
Cc: (wrong string) 陈智昌) <willchan@chromium.org>, ietf-http-wg@w3.org, Peter Lepeska <bizzbyster@gmail.com>
On Mon, Apr 2, 2012 at 7:36 AM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:

> One option, which I personally really like, is that we use a toplevel
> "container" format to do multiplexing (and possibly routing), and
> allow the channels to be individually TLS protected.
> The nice thing about this is that we can do the upgrade to TLS using
> the same TCP connection.
> A mockup would look something like:
> C->S    GET / HTTP/1.1
>        ...
>        Upgrade: http-20-tls
> S->C    HTTP/1.1 101 Switching Protocols
> S->C    [chan=1,msg=HTTP20-REPONSE,len=X] {200|OK|Set-Cookie: blablabla...}
> S->C    [chan=1,msg=HTTP20-BODY,len=X] {<HTML>yaddayadda...}
> S->C    [chan=1,msg=HTTP20-BODY,flag=FINAL,len=X] {..yaddayadda</HTML>}
> C->S    [chan=2,MSG=TLS-SETUP,len=X] {start TLS negotiation}
> S->C    [chan=3,MSG=TLS-SETUP,len=X] {TLS negotiation reply}
> ...TLS negotiation completes for chan=2
> ... more unprotected objects may be pulled over chan=1 in the meantime
> C->S    [chan=2,msg=HTTP20-REQUEST,flag=TLS,len=X] {TLS(request)}
> S->C    [chan=2,msg=HTTP20-REPONSE,flag=TLS,len=X] {TLS(reponse)}
> S->C    [chan=2,msg=HTTP20-BODY,flag=TLS,len=X] {TLS(body part 1)}
> S->C    [chan=2,msg=HTTP20-BODY,flag=TLS,FINAL,len=X] {TLS(body part 2)}

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.

- 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).

Received on Monday, 2 April 2012 15:11:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:13:59 UTC