Re: The use of binary data in any part of HTTP 2.0 is not good

Well, there are two aspects; one is the encoding for the headers, the other is the framing for the protocol itself.

Additionally, binary can bring benefits in size, leading to performance benefits. However, it can also bring scalability benefits, because it's a lot easier to parse, requiring less memory / copying / look-ahead...

Measuring size benefits is fairly straightforward (as we're already doing <http://http2.github.com/http_samples/>); measuring scalability benefits is more implementation- and deployment-specific, and so more difficult. We can try, however.

FWIW, my "simple" approach *is* textual*, at least for the header encoding part of the problem. Textual framing is also possible, of course, but it's going to come at a fair overhead (in terms of size and in terms of processing overhead), I suspect.

If anyone is interested in pursuing these approaches, an Internet-Draft making a concrete proposal is the best way to get our attention. And of course, if people want to see measurements, they can pitch in (as things seldom measure themselves).

Cheers,


* Or, at least, it was until a few days ago, when I switched to a 7-bit encoding of ASCII; that can be disabled (at a cost of 12.5% efficiency, naturally).




On 21/01/2013, at 10:36 AM, James M Snell <jasnell@gmail.com> wrote:

> This is still being worked out really, qualitative numbers will be coming. So far, however, we're talking about around a 50% reduction in header overhead on the wire without compression. Obviously, however, we're no where near being done yet.
> 
> On Jan 20, 2013 3:26 PM, "Tim Bray" <tbray@textuality.com> wrote:
> Would it be possible to be data-driven?  Textual formats are
> well-known to be easier to debug; but clearly, if there’s a
> substantial performance benefit to going all-binary, so be it. So what
> is the advantage, quantitatively? -T
> 
> On Sun, Jan 20, 2013 at 3:04 PM, Mark Nottingham <mnot@mnot.net> wrote:
> > In one of our recent meetings, one of the grey-bearded IETF old-timers (I forget which, sorry) said that a textual-protocol was a nice-to-have, but that it shouldn't be a determining factor in design.
> >
> > I.e., if you can get everything you need out of a protocol, *and* make it textual, do so, but if it detracts from the value you get from it, don't let that constrain you.
> >
> > FWIW, I think that's a good rule of thumb. However, this means that the community is going to need *excellent* tooling for analysing, debugging, etc. HTTP traffic; and I don't just mean a Wireshark plugin!
> >
> > Cheers,
> >
> >
> > On 21/01/2013, at 9:36 AM, William Chan (陈智昌) <willchan@chromium.org> wrote:
> >
> >> There are many advantages to using binary data. If you would like a
> >> textual representation of a protocol, I advise using a utility to
> >> generate one for you.
> >>
> >> On Sun, Jan 20, 2013 at 2:20 PM, Pablo <paa.listas@gmail.com> wrote:
> >>> Hello,
> >>>
> >>>   I have readed this document
> >>> http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft1 today [1].
> >>>
> >>> I just wanted to say that I think that the use of any binary data (framing,
> >>> header compression, etc.) in any place of the "header" part of HTTP protocol
> >>> is not good; so, please only use plaintext for HTTP 2.0 because, otherwise,
> >>> that will make very difficult to "see" the headers's protocol :)
> >>>
> >>> Thats all,
> >>> Thanks for reading this few lines, sorry for my basic English, and I hope
> >>> that you can re-think all this of using binary data in any part of HTTP X.X
> >>> (ej: session layer).
> >>>
> >>>
> >>> [1] I started knowing about HTTP 2.0 here:
> >>> http://webscannotes.com/2012/10/09/http-2-0-officially-in-the-works/
> >>>
> >>
> >
> > --
> > Mark Nottingham   http://www.mnot.net/
> >
> >
> >
> >
> 

--
Mark Nottingham   http://www.mnot.net/

Received on Sunday, 20 January 2013 23:47:53 UTC