Re: In Defense of Header Compresson

This thread has primarily talked about downstream compression and the
fact that its utility is driven by the header:body ratio.

Upstream compression for http/2 is pretty interesting too.

http/2 is presumably muxxed with priority semantics. The server can only
do priority scheduling across the transactions it is aware of - so we've
moved past the simpler http/1+pipeline need of being able to send enough
requests to keep the downstream bandwidth utilized. Having extra
transactions to choose from lets the priority of a late ordered
transaction take precedence if appropriate.

upstream compression lets the client send more requests in its typically
small cwnd.

On Wed, 2012-08-15 at 22:40 -0700, 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...
> Ilya

Received on Thursday, 16 August 2012 13:46:34 UTC