Re: In Defense of Header Compresson

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 <> wrote:
> Ilya Grigorik wrote:
>> > On Wed, Aug 15, 2012 at 4:36 AM, Henrik Frystyk Nielsen <> 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:
>> 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


Received on Thursday, 16 August 2012 15:25:21 UTC