HTTP 2 will support server push, what does this mean?

Question

I've read a lot of things about HTTP 2 (which is still in development), so I also heard about the server push feature, but I my head, this is not clear.

Does this server push feature mean that the server will be able to send a response to the client without the latter making a request? Just like a vanilla TCP connection? Or I'm missing the point?

Ashore

The accepted answer is wrong. a) HTTP/1.1 keeps the connection open for a configured interval. b) HTTP/2.0 do allow the server to push to connected clients (without the client doing requests). It's possible thanks to "streams" in HTTP 2.0 – Lied

@Lied Can you please add some references? Why comment the question instead of the answer you think is wrong? You are free to give minus points either. – Crenelation

@Ashore You can use SSE if you want to push with HTTP. You don't need HTTP2, SSE works with HTTP1.1 too. What HTTP2 push does as far as I can tell, is very similar to multipart messages. You can send multiple files in a package as response. – Crenelation

Answer 1

The HTTP2 push mechanism is not a generic server push mechanism like websocket or server sent events.

It is designed for a specific optimisation of HTTP conversations. Specifically when a client asks for a resource (eg index.html) the server can guess that it is going to next ask for a bunch of associated resources (eg theme.css, jquery.js, logo.png, etc. etc.) Typically a webpage can have 10s of such associated requests.

With HTTP/1.1, the server had to wait until the client actually sends request for these associated resources, and then the client is limited by connections to only ask for approx 6 at a time. Thus it can take many round trips before all the associated resources that are needed by a webpage are actually sent.

With HTTP/2, the server can send in the response to the index.html GET push promises to tell the client that it is going to also send theme.css, jquery.js, logo.png, etc. as if the client had requested them. The client can then cancel those pushes or just wait for them to be sent without incurring the extra latency of multiple round trips.

Here is a demo of push with SPDY (the basis for HTTP2) with Jetty https://www.youtube.com/watch?v=4Ai_rrhM8gA . Here is a blog about the push API for HTTP2 and SPDY in jetty: https://webtide.com/http2-push-with-experimental-servlet-api/

Monophthong

AFAIK HTTP2 does not predict what to send to the client, being a transfer protocol. What it does it to send multiple files against multiple file requests. – Jarrell

It is up to the application to decide what files to push. In Jetty we provide a filter that uses referrer headers to learn relationships between resources, but frameworks like JSF might already know relationships and thus might be able to push associated resources. – Monophthong

Here is a comprehensible article about what's new in HTTP/2: mnot.net/blog/2014/01/30/http2_expectations – Ashore

AFAIK the push promises are being sent in the HTTP headers of the original response. These are special headers which are then removed by the client, meaning they are not visible from a JavaScript point of view. This mechanism plays well with the multiplexing introduced with HTTP/2, which enables the resources to be sent simultaneously to fully use the available bandwidth. – Valetudinary

Answer 2

Essentially your understanding is correct, however, there is a lot more to it.

The server will only be able to send a resource to the client after a request for an HTTP page has been made and the resources required by that page for it to render properly, i.e. images, JavaScript files, CSS etc, have been identified. The mechanism responsible for this is the server side framework. In Java, this will be Servlet 4 and possibly JSF.

A server can not just send any resource to the client when it feels like it. Only under the above circumstance will it occur and a client will always be able to reject the server request to push a resource.

The mechanism of HTTP/2 server push has been really well designed and to get to grips with it I recommend this overview of HTTP/2 and this in depth article diving into the internals of the HTTP/2 protocol.

Adenine