- From: Patrick McManus <pmcmanus@mozilla.com>
- Date: Thu, 16 Aug 2012 09:45:47 -0400
- To: Ilya Grigorik <ilya@igvita.com>
- Cc: Henrik Frystyk Nielsen <henrikn@microsoft.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
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 > <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... > > Ilya
Received on Thursday, 16 August 2012 13:46:34 UTC