Flow control can definitely be useful when streaming audio/video files. A browser only needs a few megabytes of buffer to display 1080p content properly. Everyday example: user starts watching a youtube video, gets interrupted and pauses it, then closes the browser because they got carried away. The entire video will be downloaded and put in the cache where only a few megabytes were needed/watched. That's quite a waste of bandwidth at 1080p.

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 :)

The flow control one does make sense. For the multiplexing, I must have missed the fact that multiple tabs need to be loaded simultaneously. It makes more sense to allow ones from the same host to load concurrently over one single connection than to keep one connection per tab.

Thanks for the explanation.

TLS Sessions could go a long way in helping the problems with TLS.

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.

fuck binary.

Thanks!

Multiplexing is necessary because the remote/local port for an open TCP connection acts like a temporary cookie, uniquely identifying a browsing session. The more time you can keep a connection open and the more requests over it the more tracking you can do. 'Ideally' you'd have one connection to google-analytics and keep it open for many minutes for better user tracking.

Stop letting your paranoia get in the way of reality

TCP is great for long lasting connections / large download and HTTP/1.x with it's connection per request, small resources model uses TCP inefficiently.

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.

I wasn't convinced until I saw an example of multiplexed progressive images:

http://www.youtube.com/watch?v=zCDcmit5-fE&feature=player_de...

Flow control is necessary for any multiplexed protocol. Try implementing a multiplexed protocol yourself, and you will notice that without flow control commands, it is very easy for someone to DoS you by overflowing your buffers.