[squid-users] got http2?

Amos Jeffries squid3 at treenet.co.nz
Mon Oct 12 10:01:29 UTC 2015


On 12/10/2015 11:31 a.m., Linda A. Walsh wrote:
> 
> I was looking at some traffic differences between one of
> my browsers going through squid and going direct (via masquerade).
> 
> The protocol usage in the 2nd case used 'http2' -- which started me
> wondering what the heck that was...so googled around and
> found it is an optimized http/1.1 mostly meant for packing
> a website and streaming the whole thing as a byte-stream
> to the client.

No it is HTTP version 2.0. As in the next-generation specification
release after 1.1.

> 
> Interestingly, a few things are starting to support it:
> nginx, chrome, MS(w/partial support), later firefox
> versions... and several others.
> 
> In the http2-working (ietf) group, webpage loading
> was about 50% faster (obviously depending on number
> of items).  Supposedly it has to be 'encrypted' w/
> TLS2, BUT I see nothing in spec that requires that.
> 

Correct in that there is no such requirement. It is simply the Chrome
and Firefox developers are refusing to implement plain-text HTTP/2 for
port 80 usage, or support for proxies.

Almost all the other tools you will find supporting HTTP/2 can do so
happily over port 80. Some do not even support the TLS / HTTPS form of
HTTP/2.

And "50% faster" is false. The IETF HTTPbis WG only got a 20% latency
reduction. And take that with a grains of salt too, the measurements
were only taken for single browser->server hops. Since at the time no
tools supported proxies and no proxies existed for HTTP/2.
Still a great result, but not as big as 50%.


> Notably google was talking about http2 support on
> their website, and the availability of businesses
> with web-proxys to request that their clients not
> use the bump to TLS2, but still allow the main
> things that speed things up -- appending multiple
> web items in 1 binary stream and using both
> header and body compression.
> 
> I could see several ways/levels of squid supporting
> this, but looking through my local mail archives,
> I didn't see 'http2' mentioned once --either
> on the users or the dev list and this complete
> lack of its mention is leading me to think of the
> that there is no ongoing work for it or future
> plans at this point?

There is ongoing work to add it to Squid. But it has no sponsor paying
for it to happen anytime soon and been slowed the last few months as I
prepare for Squid-4 release.
<http://wiki.squid-cache.org/Features/HTTP2>

HTTP/2 takes multiplexing to a whole new level above what HTTP/1.1
contains, which has been a design challenge. Squid-4 includes a lot of
the redesign work, but unfortunately I did not get the payload stream
and coders finished yet.

> 
> I think it is partly being supported through the current
> squid by encapsulating a http2 session in a
> http1.1 "tunnel" -- which raises some problems.
> 

Yes.

> All the kinks aren't worked out yet, but
> Proxy-Users scenarios are shown at:
> 
> https://github.com/http2/http2-spec/wiki/Proxy-User-Stories
> 

And yet the only browser that will support sending HTTP/2 to a proxy is
MS IE. The more popular ones are simply refusing to implement half the
specification. It does not bode well for interoperability.



> Are the impacts or implementation details
> being thought about in squid?, since if it comes
> down to it only being supported by encrypted
> TUNNELS, its not only going to be hard to cache,
> but also makes it a pain to implement http/browsing
> controls on content -- since it would all
> be encrypted and and compressed and impossible
> to directly use in companies that need to filter
> web-content as it comes in.

Those problems are not HTTP/2 related. As you noticed there is no TLS
requirement in the specification. They are side effects of the "TLS
everywhere" campaign that those same browser vendors have taken up.

> 
> A bit concerned...
> linda

Squid can MITM the TLS tunnels. When it does so it strips away the
tokens negotiating SPDY, HTTP/2 and QUIC to make the communication be
HTTP/1.1 over the proxy.

Amos



More information about the squid-users mailing list