Re: Some thoughts on server push and client pull

On Wed, Jun 6, 2012 at 8:47 PM, Mike Belshe <mike@belshe.com> wrote:

> I agree.
>
> Perhaps another reason for dropping push at this point may be that I don't
> know of any efforts to seriously deploy it.  If no implementors are willing
> to speak up that they plan to use it, deploy it, measure it, and report
> results on their findings, then it is a good time to drop it altogether and
> focus on the other parts of the protocol instead.
>

I recently released a fork of Tornado (http://www.tornadoweb.org/)
implementing SPDY support with server push - we're certainly serious about
it :). As it's only a few days old, I don't know of anyone who's deployed
it yet and has results to report, but I will ask around.

Alek

Mike
>
>
> On Wed, Jun 6, 2012 at 6:30 PM, Gabriel Montenegro <
> Gabriel.Montenegro@microsoft.com> wrote:
>
>>  Hi folks,****
>>
>> ** **
>>
>> Amongst some collegues, we've been thinking about server push in HTTP 2.0
>> and have some ideas we'd like to share as a way to promote discussion on
>> this subject****
>>
>> ** **
>>
>> 1. Overview****
>>
>> Server Push is an interesting idea that could provide some performance
>> gains for HTTP 2.0 clients, however we don’t believe it is core the HTTP
>> 2.0 protocol. Server Push could result in servers sending unnecessary data
>> to the client, introduces potential delays to avoid race conditions and is
>> mostly relevant for browser applications. A less complex alternative that
>> addresses some of these drawbacks while better aligning with legacy HTTP,
>> “Smart Client Pull”, is proposed below. ****
>>
>> ** **
>>
>> ** **
>>
>> 2. Issues with current Server Push in SPDY****
>>
>> ** **
>>
>> We don't envision Server push as part of the base HTTP 2.0 protocol, but
>> see it as a potentially interesting extension, as long as there is some way
>> for the client to exert some control over when and how it is used. One
>> fundamental requirement is for clients to be able to control “Server Push”
>> behavior via a new opt-in <name TBD> header.  Servers MUST NOT push
>> unrequested data to the client, unless the top level page request <name
>> TBD> header is set to allow “Server Push”.****
>>
>> ** **
>>
>> Server Push does not require any validation prior to pushing data to the
>> client, which could result in the server sending unnecessary data to
>> clients that have some of the pushed resources stored in their cache.****
>>
>> ** **
>>
>> Furthermore, "Server Push" introduces a race condition in which a client
>> could start a new request for data that the server is in the process of
>> pushing, effectively causing the same resource to be downloaded twice. SPDY
>> addresses the race condition by not sending any data (headers are OK) for
>> the top level page, until all of the SYN_STREAM for the dependencies it
>> will push are sent:****
>>
>> ** **
>>
>> "To minimize race conditions with the client, the SYN_STREAM for the
>> pushed resources MUST be sent prior to sending any content which could
>> allow the client to discover the pushed resource and request it."****
>>
>> ** **
>>
>> We agree that SPDY's proposal is a good way to mitigate the race
>> condition in Server Push without introducing significant complexity.
>> Unfortunately mitigating the race condition in this manner prevents the
>> server from sending data for the top level page. This could result in
>> user-visible delays.  Whether or not the user will see a delay will depend
>> on what messages (how many and how large) the server is pushing to the
>> client.****
>>
>> ** **
>>
>> 3. Smart Client Pull alternative to Server Push****
>>
>> ** **
>>
>> We would like to propose an alternative to Server Push for discussion.
>> This alternative is closely aligned with existing standards and could even
>> work for HTTP 1.1.****
>>
>> ** **
>>
>> When a server receives an HTTP request for a top level page, the server
>> will generate a list of resources needed to fully load the top level page.
>> The server will send the optimal pre-fetch list to the client, via LINK
>> headers, with a "prefetch" link relation type (defined in HTML5 per
>> http://www.iana.org/assignments/link-relations/link-relations.xml). ****
>>
>> ****
>>
>> The server SHOULD also include the corresponding cache validators for
>> each resource in the pre-fetch list. An extension to the “prefetch” link
>> relation type will be needed to allow cache validator data.****
>>
>> ** **
>>
>> When a client receives data for a top level page, it will begin
>> processing the top level page response, while simultaneously pre-fetching
>> resources in the pre-fetch list that are not in the client cache or that
>> are cached but invalid, as indicated by the cache validators included in
>> the pre-fetch list. Servers SHOULD only include resources that block
>> loading of the top level page in the optimal pre-fetch list.****
>>
>> ** **
>>
>> This eliminates the need to block data for the top level request until
>> all SYN_STREAM for pushed dependencies are sent, in order to avoid the race
>> condition. The client would pre-fetch the resources in the optimal
>> pre-fetch list, which introduces an extra RTT.  We should gather data to
>> determine how much more significant this RTT is, when compared to the
>> complexity of implementing server push and some of the benefits obtained by
>> multiplexing new connections for the dependency resources.****
>>
>> ** **
>>
>> Clients will control “Smart Client Pull” behavior via a new opt-in <name
>> TBD> header. Servers MUST NOT push LINK header and associated cache
>> validator data to clients, unless the top level page request <name TBD>
>> header is set to allow “Smart Client Pull”. ****
>>
>> ** **
>>
>> 4. Other alternatives ****
>>
>> ** **
>>
>> These are other client-driven alternatives to “Server Push”. However we
>> need to capture additional data to determine the impact and cost of each:
>> ****
>>
>> ** **
>>
>> a.            Bundling of HTTP resources: Administrators can package
>> static server side resources needed to download a webpage as a single
>> entity. A client would download all static dependencies by issuing a single
>> HTTP request. However, this could result in the client receiving data which
>> it already had in its cache.****
>>
>> ** **
>>
>> b.            Combination of Smart Client Pull and Bundling of HTTP
>> resources (a).****
>>
>> ** **
>>
>> 5.            Recommendation:****
>>
>> ** **
>>
>> “Server Push” should not be a part of the core HTTP2.0 spec for the
>> following reasons:****
>>
>> ** **
>>
>> - “Server Push” is not core to defining the HTTP 2.0 transport.****
>>
>> ** **
>>
>> - “Server Push” without optimizations can result in unnecessary data
>> being sent to the client.****
>>
>> ** **
>>
>> - “Server Push” even with optimizations, introduces delays to avoid race
>> conditions that are not present in other solutions.****
>>
>> ** **
>>
>> - “Server Push” is relevant primarily for browser applications and not
>> for more general use cases.****
>>
>> ** **
>>
>> 6.            Areas for further discussion: ****
>>
>> ** **
>>
>> - How to send the “prefetch" list and its corresponding cache-validators
>> in an efficient manner. These resources are URLs, which can be really long,
>> causing us to transmit a additional data when using Smart Client Pull.***
>> *
>>
>> ** **
>>
>> - Validation of cached resources included in the prefetch list will
>> require additional CPU cycles.  However, it is no different from cache
>> validation currently performed on cache resources. The tradeoff here is CPU
>> load in order to avoid unnecessary download of resources already in the
>> client’s cache.****
>>
>> ** **
>>
>> - Compare “Smart Server Hints” and “Bundling” to determine the impact of
>> the features in isolation and combined.****
>>
>
>