Работу над HTTP 2.0 предлагают начать заново

a) Single packet delay induces head-of-line blocking for a stream. Since TCP only provides a single serialized stream interface, a delay of only one packet causes the entire set of SPDY streams to pause. A packet is routinely delayed when a packet is lost, such as due to congestion, and it must be retransmitted. A better multiplexed transport should delay only one stream when a single packet is lost.

b) Unfavorable congestion avoidance handling by TCP, leading to additional bandwidth reduction and serialization latency overhead: A single SPDY connection is routinely used to replace K separate (non-multiplexed) connections. When a single packet of a SPDY (over TCP) connection is lost, the congestion window for the entire connection was historically reduced by 50%, courtesy of TCP [TCP CUBIC default congestion window reduction is roughly 30%, but the factor of 2 simplifies the math in this paragraph’s exposition]. In contrast, a single packet loss among K non-multiplexed TCP connections only reduces the congestion window in one TCP connection. With only one of K streams impacted by a loss, the aggregate congestion window is reduced by roughly 1/2K of the pre-loss aggregate. With K commonly having a value of 6 (for multiple HTTP GET requests), a single packet loss causes bandwidth reduction to 11/12 of the pre-loss bandwidth (pre-loss congestion window size). As a result, TCP congestion avoidance favors sharded (multiple) TCP connections over a multiplexed TCP connection.