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.
Re:Making HTTP realtime with HTTP 2.0
by jimktrains2 on Monday October 21, 2013 @08:11AM
(#6584929)
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.
I planned for this to get downvoted. Damn! Turns out I'm not the only one thinking so then ;-)
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 :)