- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Thu, 19 Jul 2012 13:27:08 +1200
- To: <ietf-http-wg@w3.org>
On 19.07.2012 01:07, Patrick McManus wrote: > On Wed, 2012-07-18 at 08:09 +0200, Willy Tarreau wrote: >> On Tue, Jul 17, 2012 at 09:22:24PM -0400, Phillip Hallam-Baker >> wrote: > >> >> The issue with HTTP/2 will indeed be the same as with IPv6 : HTTP/2 >> will >> be deployed between the browser and the load balancer, and >> everything >> behind will remain HTTP/1 due to the added nuisances of deploying >> 2.0 >> everywhere. > > Except we know that in the very near future SPDY adoption will have > reached far more people than IPv6 ever has. So, unlike IPv6, there is > a > big demand to solve the problems it addresses. > Huh. IPv6 has *reached* just about every end-user in eastern civilisation and a good portion of the western as well. The annoying fact that there are IPv4-only barriers devices all over the Internet is not the users or content providers faults. If HTTP/2 mandates encryption, compression or anything similar that raises the developer implementation workload significantly over HTTP/1 then our efforts will face the same type of barriers with HTTP/1-only IDS, firewall and monitoring systems. Remember we are *already* pretty much confirmed to be adding: * binary encoding - difficult to read on the wire, special new tools required to interpret it (and learn how to use), new library APIs to learn for parsing and generating messages. * multiplexing - flow control on that one will be an educational curve for most still stuck on the HTTP/1.0 paradigm (1.1 folks only get it slightly easier if they understand 1xx status flow control). * pipelining - already a difficult subject under HTTP1, making it mandatory to support is a good thing but does raise the learning curve. Adding all these up and we have a noticable barrier to implementation. Placing *mandatory* encryption on top to raise the barrier even higher, particularly in places where it is clearly not necessary for security OR privacy is too much. As the Hulu folks have said, too much of a good thing is still too much. >> Almost nobody does IPv6 between LB and server nowadays, it's >> added cost for no benefit. You want to tell that to my customers. You (and most other users) not noticing just goes to show how well the middleware gateways and LB have been doing translating IPv4 to IPv6 and back again. The networks over this *quarter* of the world (APNIC and increasingly RIPE NCC) are increasingly 'forced' to run IPv6 internally due to unavailability of IPv4 allocations and routinely do exactly as you suggest 'nobody' does: Run IPv6 between LB and server pool. The available IPv4 being reserved largely for use on the America-facing connections. Then there is the carrier-grade NAT situation for content providers. Bit of a no-chance there, but every attempt simply hides more IPv6 away from those of you in IPv4-only nets. > > of course spdy has lots of benefits. key difference :) AYJ
Received on Thursday, 19 July 2012 01:27:34 UTC