W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2013

Re: Out-of-order Frames

From: 陈智昌 <willchan@chromium.org>
Date: Sat, 22 Jun 2013 15:12:44 -0700
Message-ID: <CAA4WUYgOQx7aC6KqW0CefpNBD9scFxb_8pf72BDrG22W-sxVTA@mail.gmail.com>
To: Mark Nottingham <mnot@mnot.net>
Cc: Sam Pullara <spullara@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Sat, Jun 22, 2013 at 2:30 PM, Mark Nottingham <mnot@mnot.net> wrote:

> FWIW -
> Sam is pointing out that all bytes in a response aren't equal, in terms of
> what it takes to generate them. Some are very easy (e.g., static parts of
> templates), whereas others take time / cpu / etc. (e.g., database calls,
> service calls, getting something off of disk).

Yes yes, this is all well understood.

> A smart app could send the "easy" bytes immediately, to use the available
> bandwidth, while the "hard" ones churned away in the background.

> Yes, the browser would have to buffer the response, but this would utilise
> the connection more optimally in some cases.

OK, I think this is the important thing. Servers could utilize a new
out-of-order write API to do this, and clients would not necessarily have
to switch to a new out of order read API if their HTTP stack just buffered.
So from that perspective, this could be transparent to a client web app,
but not to the server nor the client (both which need to change their HTTP
stacks to understand this and buffer) nor a servlet (which would have to
leverage the server's out of order write API). If this happened, then you
might be able to utilize the connection more optimally in some cases. You
wouldn't want to just always do this in the web platform case, because
that'd very likely hurt performance in a large number of cases. And the
existing solution is better because the rendering engine gets to process
more of the bytes sooner, but as noted, that requires work on the web devs'

Sorry for misunderstanding earlier, it was not evident to me exactly what
was being addressed. I agree that this is something we can discuss here.

> I think the question is whether this is a useful enough thing to put into
> the core spec (vs. an extension), and whether it's a DDoS vector.
> As a server-side person, I'd be VERY interested in this (especially
> combined with some aggregation frameworks like ESI). Again, FWIW.
> Cheers,
> On 22/06/2013, at 2:11 PM, William Chan (陈智昌) <willchan@chromium.org>
> wrote:
> > Sorry, it wasn't clear you wanted this optimization to happen
> transparently without application knowledge, I thought you were trying just
> to achieve a better optimization of some sort.
> >
> > At this point, most of the conversation is revolving around how the web
> platform uses HTTP in resource loading, and thus the discussion is better
> moved to a web platform list, perhaps whatwg or public-webapps, I dunno. If
> the feeling is that new HTTP semantics would be useful, we can discuss that
> here, but my instinct is that at an HTTP level, it'd be best just to use a
> different resource rather than try to allow out of order response bodies.
> I'm open to what others on this mailing list think though.
> >
> >
> > On Sat, Jun 22, 2013 at 1:47 PM, Sam Pullara <spullara@gmail.com> wrote:
> > This seems roughly the same as the JavaScript version but now I need
> even more coordination with the client application. My intent in adding
> this to the protocol would be that many applications wouldn't even have to
> know that this optimization is occurring.
> >
> > Sam
> >
> > On Jun 22, 2013, at 1:41 PM, William Chan (陈智昌) <willchan@chromium.org>
> wrote:
> >
> >> Correct me if I'm wrong, but I think what you're saying is the problem
> is that chunk 2 is not able to be itself delivered as a set of out of order
> HTML fragments. The current solution as you described allows for chunk 1 to
> be immediately flushed by the server and then parsed & rendered by the
> browser, but then we're stuck with waiting for the server-side template
> expansion to finish completely before flushing chunk 2, rather than letting
> chunks of the server generated HTML get inserted into the document out of
> order.
> >>
> >> I *think* what you actually want to do is something akin to what a dumb
> mail reader web app might do. In the inbox view, you have a whole bunch of
> emails. There's no need to fetch the HTML for all those emails and set them
> in a single innerHTML command. You can fetch all the emails individually,
> and build subtrees of DOM nodes as they come in, and then insert into the
> document as needed.
> >>
> >> In other words, from HTTP land, if you want to be able to fetch
> different fragments of a single HTTP resource out of order, then maybe it's
> best to split that HTTP resource into multiple separate HTTP resources.
> HTTP doesn't care. At the web platform level, use script to re-assemble
> these different resources together into the actual document. This requires
> no changes in HTTP nor the web platform.
> >>
> >>
> >> On Sat, Jun 22, 2013 at 1:15 PM, Sam Pullara <spullara@gmail.com>
> wrote:
> >> I'm all for brainstorming. The current solution works basically like
> this:
> >>
> >> Chunk 1 (sent immediately):
> >> <html>
> >> <body>
> >> <div id="1"></div>
> >> </body>
> >> </html>
> >>
> >> Chunk 2 (calculated completed and sent later):
> >> <script>document.getElementById("1").innerHTML = "<span>Hi William
> Chan!</span>";</script>
> >>
> >> Even if the browser can do no work before receiving all the data it is
> still better because the bytes are sent sooner than they normally would be
> sent. However, I think that the browser would be able to parse complete DOM
> elements in the fragments to do even more work before the page has been
> completely rendered on the server. The contract with the browser might be
> that delayed frames must be complete elements like in the example. Rather
> than out of order frames we might have some way of specifying a named frame
> to be replaced later. There are a number of possible implementations.
> >>
> >> Sam
> >>
> >>
> >>
> >> On Jun 22, 2013, at 1:06 PM, William Chan (陈智昌) <willchan@chromium.org>
> wrote:
> >>
> >>> OK, it sounds like you want to be able to send out of order byte
> sequences for a single resource, by sending out of order frames for the
> same HTTP/2 stream. This is not possible without changing HTTP semantics,
> and HTTP/2 is primarily only working on improving the mapping of HTTP
> message semantics onto a connection.
> >>>
> >>> Btw, why would you want to do this? The browser rendering engine
> cannot do anything with just frame 1 and frame 3 anyway. HTML parsing
> requires in-order parsing of the document.
> >>>
> >>> Stepping back, I still don't fully understand the problem with the
> existing solution that relies on script to dynamically fill in the DOM
> nodes as they become available. Can you clarify what you are hoping HTTP2
> can do that would be better? Maybe there's a better solution here?
> >>>
> >>>
> >>> On Sat, Jun 22, 2013 at 12:52 PM, Sam Pullara <spullara@gmail.com>
> wrote:
> >>> Sorry, let me give a concrete example. You have an HTML page that
> ultimately needs to look like:
> >>>
> >>> <html>
> >>> <body>
> >>> <span>Hi William Chan!</span>
> >>> </body>
> >>> </html>
> >>>
> >>> In order for me to figure out the contents of the span I need to check
> an authentication database and do some kind of hard computation that might
> take several 100 ms. What I am proposing is that you could send 3 "frames"
> or "chunks" or whatever is the final form like this:
> >>>
> >>> Stream:
> >>>  Frame 1:
> >>>  <html>
> >>>  <body>
> >>>  Frame 3:
> >>>  </body>
> >>>  </html>
> >>> … some time later …
> >>>  Frame 2:
> >>>  <span>Hi William Chan!</span>
> >>>
> >>> The client then reconstructs the final document, optionally doing some
> processing on the parts of the document it received before completion. I'm
> pretty sure the protocol doesn't allow out of order frames within a stream
> right now. In section 3.4 it states:
> >>>
> >>>    o  The order in which frames are sent within a stream is
> significant.
> >>>       Recipients are required to process frames in the order they are
> >>>       received.
> >>>
> >>> Sam
> >>>
> >>> On Jun 22, 2013, at 12:47 PM, William Chan (陈智昌) <
> willchan@chromium.org> wrote:
> >>>
> >>>> I'm having difficulty fully understanding the problem and the
> proposal. Can you clarify?
> >>>>
> >>>> * What do you mean by "frame"? Do you mean frames in the HTTP/2
> framing layer? Frames in the framing layer can appear in any order (subject
> to a few rules), so I don't know what out-of-order frames means. Or do you
> mean like video frames?
> >>>> * If you meant video frames, then if you separate the video into
> multiple resources, there's no reason the resources can't be sent "out of
> order", since at the HTTP level there's no concept of order among resources.
> >>>>
> >>>>
> >>>> On Sat, Jun 22, 2013 at 12:34 PM, Sam Pullara <spullara@gmail.com>
> wrote:
> >>>> Commonly in dynamically generated websites there are sections of
> content that are static and parts that are calculated on a per request
> basis. The current best practice for accelerating the delivery of a page
> like this involves leaving identifiable DOM elements where the dynamic
> content would appear, flushing the entire static page, and then flushing
> JavaScript script nodes as calculations complete (e.g. Facebook's BigPipe
> and deferred rendering in mustache.java). This practice only works for HTML
> pages (with JavaScript enabled) and offers no acceleration for other types
> of content delivered over HTTP.
> >>>>
> >>>> One possible solution to this problem would be to allow for
> out-of-order frames where the static frames are sent as quickly as the
> connection allows and dynamically generated frames are then sent later as
> they become available on the server. We would likely not want to enable
> this in general and would likely need to negotiate this behavior between
> client and server. Looking at the spec, frames might not be the right place
> but something on top of frames because of the size limitations.
> >>>>
> >>>> Has something like this been discussed before? Would this be the
> right mechanism or are there better ways to do it?
> >>>>
> >>>> Thanks,
> >>>> Sam
> >>>>
> >>>>
> >>>>
> >>>
> >>>
> >>
> >>
> >>
> >
> >
> --
> Mark Nottingham   http://www.mnot.net/
Received on Saturday, 22 June 2013 22:13:12 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:11 UTC