On Tue, May 08, 2012 at 03:58:21PM -0400, KT Walrus wrote:
>
> On May 8, 2012, at 2:01 PM, Willy Tarreau wrote:
>
> > That's why with the guys from Squid, Varnish and Wingate we presented
> > an concurrent proposal to the IETF one month ago :
> >
> > http://tools.ietf.org/html/draft-tarreau-httpbis-network-friendly-00
> >
>
> I hope that HTTP 2.0 requires encryption/compression for all traffic.
This has been discussed to great extents on the http-bis WG and I must
say I'm one of those against making this mandatory, as it significantly
increases costs for every hop without providing *any* benefit :
- compressing videos and images is useless and is why nobody enables
TLS compression on HTTP ;
- encrypting everything will make it necessary to decrypt at many
hops and will make it totally usual for many users to see broken
sites and crypto errors everywhere, meaning that they won't care
anymore. How many times did you have to click on "I accept the
risks" when your browser told you a site's certificate was wrong ?
And as Poul Henning Kamp of Varnish said, compressing or encrypting pink
bits brings no benefit at all. Let's ensure that the new protocol makes
it much easier and safer to stack components on top of each other, and
to enable safer crypto (which means one which can be deciphered by proxies
as an opt-in if you don't want your children to visit porn sites at school).
Anyway, this discussion is for the http-bis WG, not haproxy's ML.
> Also, I would hope that geographic/distributed load balancing is better
> addressed in the protocol. That is, any request can get forwarded to another
> IP immediately (along with any session data needed by the new server) and a
> short response back to the client (if the new server accepts the request)
> containing a Unique Request ID and the IP for the client to connect to for
> the response. The client would, when seeing this redirect response, connect
> to the IP with the Request ID to get the response. Subsequent requests from
> the client should be made to the new IP for the given host and could be
> changed again.
There is no way this could take off. Current plans for HTTP/2.0 are to reduce
the number of RTTs as much as possible, and adding a preliminary request means
one more RTT. You have to think with smartphones right now, they will dominate
the web in a few years and they have the worst imaginable connectivity.
Regards,
Willy
