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

Re: In Defense of Header Compresson

From: Phillip Hallam-Baker <hallam@gmail.com>
Date: Thu, 16 Aug 2012 11:24:53 -0400
Message-ID: <CAMm+Lwii22nj=L8LHJQhbOzrn7Mr_ta2RMyURvwxGLunVK_HMQ@mail.gmail.com>
To: Robert Brewer <fumanchu@aminus.org>
Cc: Ilya Grigorik <ilya@igvita.com>, Henrik Frystyk Nielsen <henrikn@microsoft.com>, Patrick McManus <pmcmanus@mozilla.com>, ietf-http-wg@w3.org
What really matters for performance is the number of packets rather
than packet size. If you are worried about the packet size then you
should not expect a general purpose transport to meet your needs. UDP
is going to be better.

Similarly, if you are using JSON then the JSON bloat is going to be a
lot more overhead than HTTP bloat.


I like tokenization as a strategy as the same approach can be used for
both the JSON and the HTTP space saving. It also means that embedded
devices can even use the tokenized form as a replacement for header
and JSON syntax and only use one parser.

I don't see much advantage to compression for small message sizes
unless you can avoid transporting the compression dictionary which is
exactly what tokenization does, only with a slight reduction in
maximum efficiency and a huge reduction in complexity.

On Thu, Aug 16, 2012 at 10:36 AM, Robert Brewer <fumanchu@aminus.org> wrote:
> Ilya Grigorik wrote:
>> > On Wed, Aug 15, 2012 at 4:36 AM, Henrik Frystyk Nielsen <henrikn@microsoft.com> wrote:
>> > I completely agree that if you have very small entity bodies
>> > then maturally the header size will matter getting more
>> > requests into the pipe faster. However, in the tests that we
>> > have done with actual data the size of the entity bodies was
>> > large enough that the impact was minimal. This is especially
>> > the case if you also do bundling/minification as it naturally
>> > leads you to large entities.
>>
>> It's worth keeping in mind that we're seeing more and more web
>> "applications", as opposed to pages. Frameworks like backbone,
>> angular, etc, all frequently make very small (usually JSON
>> encoded) requests to indicates record updates, or to pull
>> specific objects on demand, from an HTTP endpoint.. All of that
>> to say: many of these requests are just a few hundred bytes.
>> Your typical CRUD operations are all great examples: a lotta
>> headers for a tiny payload and a 204 response. The overhead
>> there is huge, which is why we're seeing people starting to
>> invent their own protocols. e.g. SwaggerRocket:
>> http://blog.wordnik.com/introducing-swaggersocket-a-rest-over-websocket-protocol
>>
>> They shouldn't have to do this...
>
> They shouldn't have to invent their own protocols because there are already plenty of protocols optimized for small-grained messages. That doesn't mean HTTP, which is one of the few protocols which is optimized for large-grained messages (in order to trade efficiency for scalability), has to change to become one of them.
>
>
> Robert Brewer
> fumanchu@aminus.org



-- 
Website: http://hallambaker.com/
Received on Thursday, 16 August 2012 15:25:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 16 August 2012 15:25:27 GMT