[squid-dev] HTTP2 push related question.

Amos Jeffries squid3 at treenet.co.nz
Wed Jun 22 12:56:11 UTC 2016


On 22/06/2016 8:28 p.m., Eliezer Croitoru wrote:
> I am having troubles in understanding the benefits of HTTP 2 push messages
> and I am looking a starter point on how to look at the subject.

> I am sure that there are applicable usage for it and I remember that xmpp
> and many other protocols are using this feature already.
> But I still do not understand in what way it will extend the protocol?

If you connect to a HTTP/1 server and tell it only that you want
http://example.com/index.html. That is all that will come back.

With HTTP/2 PUSH the server will inform about /some-scrip.js, logo.png,
etc. that were referenced by the index.html, and start to send them back
as well.

As you mentioned protocols like XMPP, they can be done more efficiently
over this type of one-request equals N-things-happen communication than
over HTTP/1 messaging. The parallel + multiplex nature of the streams
also helps them out a lot more than HTTP/1 synchronous messages.



> The situation of a PUSH as I understand it would be when you kind of "trust"
> the origin server and for specific applications.

Trust is not a direct part of the equation. It is only there in the fact
that 1) the server emitting the PUSH should be the origin for the domain
of the request that originally triggered the PUSH, and 2) the resources
PUSH'ed need to be related (same authority IIRC) to the initial request.


PUSH is aimed at removing the needs behind some existing services
behaviour which is causing problems in the name of latency gains.

Specifically the ones bundling up multiple response objects into a
tarball or similar. So the client asks for only thing (after the HTML
page that uses it) and decompresses all the display pieces dynamically
in the browser memory to generate the page. Often only a small part of
the bundle is actually needed, and the parts individually could be much
better cached separately if they were allowed to.

Or worse, the page has a script running up a WebSockets channel that
transfer the objects in a custom way incompatible with HTTP caching.



> Today normal web pages are already pushing data to the web browsers but with
> PUSH as I understand it means that for example a 1GB file can be pushed to
> the client.

Any size of content up to infinity can be PUSH'ed back.

If you look into exactly _how_ those services are doing the 'push' its
usually something very inefficient, complex and/or difficult. Such as
the ways I mention above.

Theres a need there that HTTP/1 does not provide a solution to. HTTP/2
tries to improve the situation.

Amos



More information about the squid-dev mailing list