Re: Out-of-order Frames

I agree that what Mark describes is interesting, I'm just not sure it's
something we should consider at this point. There are many ways that kind
of mechanism could become a very deep rabbit hole.
On Jun 22, 2013 2:32 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).
>
> 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.
>
> 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 21:42:00 UTC