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 _______________________________________________ squid-dev mailing list [email protected] http://lists.squid-cache.org/listinfo/squid-dev
