Making HTTP realtime with HTTP 2.0
docs.google.com
docs.google.com
The nice thing about this approach is that it is entirely contained such that the web application in the browser doesn't know (or even need to know) the difference, in the same way that current web applications don't need to worry about whether the request data was compressed or not.
However, some things, such as avoiding making multiple connections due to congestion and due to slow-start being slow, flow control, and arguably encryption, seem like they would be better addressed in TCP. And in fact, Google is trying to do that with QUIC.
The problem is that if (when) those things get standardized in HTTP/2.0, they need to be supported forever, even if an improved transport layer protocol makes them obsolete in relatively short order.
It reeks of overengineering--might as well spend that energy improving TCP or putting together a better secure sockets layer.
Most of the problems they cite are the result of people shoving too much shit (ads, trackers, social media, etc.) into their sites anyways.
Flow control is necessary because it's a multiplexed protocol. Without your own flow control commands, flow control is applied over the entire TCP stream, not on your substreams. That doesn't do what you want. Try it: implement any kind of multiplexed protocol yourself, and you will quickly see why it is necessary.
Encryption: some of it might be for security, but a lot of it is also for backward compatibility. SPDY/HTTP2 is a different protocol than HTTP1, and there are a lot of broken routers out there that will break things unless you encrypt the entire connection as an SSL session.
Those who do not understand SPDY are doomed to complain about it on HN, and then one day maybe reinvent it, poorly.
Why should HTTP be a multiplex protocol though; that's the issue.
> Encryption: some of it might be for security, but a lot of it is also for backward compatibility. SPDY/HTTP2 is a different protocol than HTTP1, and there are a lot of broken routers out there that will break things unless you encrypt the entire connection as an SSL session.
So why not just use SSL/TLS? Why wrap it into the HTTP protocol?
> Those who do not understand SPDY are doomed to complain about it on HN, and then one day maybe reinvent it, poorly.
Those who can't see the benefits and reason for HTTP1 are doomed to make a mess of it by "improving" (or "working around") it.
Because HTTP is inefficient due to the TCP three-way handshake, and because pipelining has many problems. These are fixed by multiplexing.
> So why not just use SSL/TLS? Why wrap it into the HTTP protocol?
They are using TLS.
So why should HTTP care about this?
> They are using TLS.
But it's specified as part of the HTTP protocol
Also flow control seems weird to me too. Maybe it's just I failed to see a scenario where flow control in HTTP layer is really useful.
Binary header and streaming (long-live TCP connection) are definitely interesting. In fact I would be really happy if I've got a connection, and can keep sending binary-format HTTP request, and the server will just respond with resource I requested in the same order.
EDIT: typos
Multiplexing allows you to have the same level of concurrency as you currently have with domain sharding without requiring multiple TCP connections (and TLS contexts). Starting and getting a TCP connection up to speed takes a while, especially on congested links (packet loss, spurious retransmits, slow starts, etc.), and TLS just makes the problem worse by requiring multiple back and forth to setup encryption. It also takes quite a bit of memory on servers to maintain hundreds of thousands of TCP socket and TLS states, and a lot of CPU to set up TLS contexts (Diffie Hellman can be quite expensive CPU wise). Then, there are flow-based routers, load balancers, stateful firewalls and other stateful network equipments. We'll get greater performance out of them by using less concurrent connections.
I think moving to a binary protocol and reducing the number of TCP/TLS connections is a very good thing, long overdue IMHO.
EDIT: typos :)
Thanks for the explanation.
I'm still not sold on why a Layer 7 protocol should be doing things that a Layer 3/4 protocol should be worried about.
Keep-alive reduces some of this inefficiency by re-using connections, but each connection still has to go through the 3 way handshake and growing the congestion window - multiplexing requests over a single connection reduces these inefficiencies further.
Multiplexing also allows the browser to communicate the priority of downloads - with HTTP/1.x once all the connections are in use the only way to alter the priority is to cancel a connection and start a new one (expensive), with HTTP/2.0 the browser communicates the priority with the request so the server could pause the download of lower priority resources.
http://www.youtube.com/watch?v=zCDcmit5-fE&feature=player_de...
There is a free online version available at http://chimera.labs.oreilly.com/books/1230000000545/index.ht...
As for why flow control is being pushed into the app layer, the answer again comes down to multiplexing of multiple streams over one TCP connection (since without stream-level flow control, one slow end-point for a stream can potentially block the progress of every other stream in that session... see discussion here: https://groups.google.com/forum/#!topic/spdy-dev/g4PiZBTW-34)
I guess in the end, only real measurements with a mature implementation will answer the question. As it turned out with SPDY (1), the results of all this work might still not be enough to overcome the basic problems with TCP.
(1) http://www.guypo.com/technical/not-as-spdy-as-you-thought/
HTTP was around before I was, hence the question.
If we just want to transfer generic files, maybe we should create a file transfer protocol.
In all seriousness, HTTP is a good example of scope creep. The type and volume of content sent in a typical session is far different than what was common a decade ago.
In 2003, the type of content was exactly the same: HTML, Images, CSS, JavaScript, Audio and Video. The formats weren't all that different. Nowadays the main difference is you see a lot more JSON and/or XML (mostly RSS).
In 1995-1996, the formats and codecs were a bit more primitive, and the net was smaller, but it was the same sort of content: AVIs, MOVs, GIFs, JPGs, HTML, and early 1.0 JavaScript.
HTTP+URI is also generally a much better protocol for transferring state than FTP. It's both simpler AND more general.
> In 1995-1996, the formats and codecs were a bit more primitive, and the net was smaller, but it was the same sort of content: AVIs, MOVs, GIFs, JPGs, HTML, and early 1.0 JavaScript.
There is a difference in magnitude between the present day web session and the typical 1995 one. The number of resources needed to properly render many pages is much, much larger. HTTP 1.0 and 1.1 simply weren't designed with this requirement in mind. They still do a pretty good job handling it, but it's not hard to argue that a protocol designed around improving parallelism will have better performance characteristics.
Sorry then :)
> There is a difference in magnitude between the present day web session and the typical 1995 one.
I agree with that, just misinterpreted your post as a pile on against HTTP. Certainly HTTP/2.0 and SPDY are necessary to keep up with the complexity of today's pages.
It just took until 2000 for Roy to call this "REST".
People write some good stuff and some bad stuff. Not because they're not smart, in general. More because of pressure due to various reasons, or because they lost interest, or what not.
Personally, every time i see a "not so much of a win" followed by memes to make it "look we rock!" it makes me feel pity for our whole industry
Here's an alternative deck by Mark Nottingham