HTTP/2 - the IETF Is Phoning It In

An anonymous reader writes HTTP/2 is back in the spotlight again. After drawing significant ire over a proposal for officially sanctioned snooping, the IETF is drawing criticism for plowing ahead with its plans for HTTP/2 on an unrealistically short schedule and with an insufficiently clear charter. A few days ago the IETF announced Last Call for comments on the HTTP/2 protocol.

Poul-Henning Kamp writes, "Some will expect a major update to the world's most popular protocol to be a technical masterpiece and textbook example for future students of protocol design. Some will expect that a protocol designed during the Snowden revelations will improve their privacy. Others will more cynically suspect the opposite. There may be a general assumption of 'faster.' Many will probably also assume it is 'greener.' And some of us are jaded enough to see the "2.0" and mutter 'Uh-oh, Second Systems Syndrome.' The cheat sheet answers are: no, no, probably not, maybe, no and yes."

"Given this rather mediocre grade-sheet, you may be wondering why HTTP/2.0 is even being considered as a standard in the first place. The Answer is Politics. Google came up with the SPDY protocol, and since they have their own browser, they could play around as they choose to, optimizing the protocol for their particular needs. SPDY was a very good prototype which showed clearly that there was potential for improvement in a new version of the HTTP protocol. Kudos to Google for that. But SPDY also started to smell a lot like a 'walled garden'."

"The IETF, obviously fearing irrelevance, hastily 'discovered' that the HTTP/1.1 protocol needed an update, and tasked a working group with preparing it on an unrealistically short schedule. This ruled out any basis for the new HTTP/2.0 other than the SPDY protocol. With only the most hideous of SPDY's warts removed, and all other attempts at improvement rejected as 'not in scope,' 'too late,' or 'no consensus,' the IETF can now claim relevance and victory by conceding practically every principle ever held dear in return for the privilege of rubber-stamping Google's initiative."

Comments

HTTP isn't why the web is slow

[Anonymous Coward]

A typical "modern" web site loads untold numbers of scripts and other files from dozens of domains, mostly for tracking, A/B testing and other things that the user doesn't want or need. That's what makes the web slow. I don't think HTTP is a particularly nice protocol, but HTTP/2 is taking a bad protocol and making it worse by "optimizing" it, while the real bottleneck is obviously somewhere else.

Re:HTTP isn't why the web is slow

[greg1104]

Whenever I bring a new computer up, I'm shocked all over again at just how slow browsers are before ad blocking is enabled. On most sites, all of the real content is there long before all of the ad and tracking content arrives. Today, nothing speeds up a slow computer and connection like Adblock Plus.

Re:Shrug

[mwvdlee]

IPv6 doesn't suck. We're just not feeling the pain of IPv4 enough to care.

Re:Shrug

[mwvdlee]

The problem with XHTML is that it would never be able to stand on it's own.
Even if all web developers started creating perfect XHTML code, we'd still have a huge legacy that would require all the browser kludges XHTML was supposed to fix.
XHTML is best described as such: http://xkcd.com/927/

versus 20 years for IPv6. 2002 cutover to IPv6

[raymorris]

HTTP/2, like Java, was written with the time frame in mind, ad it was decided that it's better to release a good specification soon than insist on a perfect specification that's never finished and deployed. There is a reason for that - a number of reasons, actually, but the #1 reason is IPv6.

On April Fool's day 2002 I announced that the backbones, root name servers, and other core infrastructure would be doing a cutover to IPv6 and we expected a few hours of downtime for the internet as a whole. The story was believable because IPv6 had been in the works for a couple of years and switchover at that point seemed logical, if the reader wasn't a network engineer.

Thirteen years later, 95% of internet traffic is still IPv4. Ten or twenty years from now, do we want to be using a better version of HTTP, or still be using HTTP/1.1 and talking about HTTP/2?

Re:HTTP/1.1 is just fine

[DarkOx]

Bandwidth is bigger and cheaper than ever. So why?

In places where its being delivered by cable to the edge or damn near to the edge yes. The rest of the world not so much.

Think about. Anywhere dense enough AND stable enough pretty is pretty well covered for highspeed Internet access.

The problem is everywhere else, is being more and more covered by Cellular. There is only so much spectrum, there are laws of physics that place caps on just how much information can be sent there.

So you have trouble on both ends. You have very high population places, us westerners might think of as slums where people want to run lots of cellular radios. You can only get so far with micro cells and wifi. After all the micro-cell or wifi have to connect to something. If the cell is to small you could have just pulled the cable or fiber in.

Ditto for sparsely populated areas. You again get lots of people on one tower there as well (but using more TX power) again because its only economical and practical to put so much density in. Satellites have essentially the limitations.

We are approaching the point were many of high bandwidth have nots are likely to remain have nots pretty no matter what policy well meaning pols come up with it; because at some point basic economic reality slaps you in the face. Yes there is still plenty of USA to cover, we got just about everyone power and phone 60+ years ago, fast Internet will get there too but it will take time.

I don't think we should let trying to keep bandwidth requirements held to a minimum stand in the way of solving real problems and doing new things, but I also don't think its a good or fair idea to just completely say "fuck it" with regard to something like protocol overhead.

Re:Proposals and running code

[dackroyd]

But at first glace it doesn't look that bad.

I can see the appeal of rubberstamping what already exists.

That's the real problem with the proposed protocol; it solves today's problems for todays computers. It doesn't attempt to look ahead and solve problems that should be solved over the next ten years.

Seeing as it's going to take a few years and a huge amount of effort before HTTP 2 is widely adopted, we're going to need to start working on a replacement for it's even finished its rollout.

Poul-Hennings has written his thoughts on the problems that actually should be solved in the next version of HTTP: http://phk.freebsd.dk/words/ht...

The fact that the IETF has decided to ignore those problems so that HTTP 2 can be pushed out the door is what makes the situation be such a joke. Almost the only entities that will benefit from having HTTP 2 in the next 5 years are companies that have a web presence on the same scale as Google, Facebook, Twitter etc. that will save a small amount of money through reduced bandwidth costs.

For everyone else, rolling out HTTP 2 will be a massive initial and ongoing technical burden, with almost no benefit.