[KaiserPro]

Yup, Each dropped packet pauses the entire connection until its retransmitted.

Moving forward to a time where the average webpage is 10-100megs in size[1] in around 5 to 10 years time, SPDY will be the bottleneck, not the network or serving infrastructure.

Of course five to ten years is about the time that HTTP 2 will start to see wide spread adoption.....

Multiplexed TCP is just not a good idea for high bandwith, low latency file delivery. (HTTP is basically a very wordy file system interface)

If you look at any of the systems for moving files about, they all either use a custom UDP protocol, or many streams of TCP. (or rely on being in a LAN)

[1]http://www.websiteoptimization.com/speed/tweak/average-web-p...

[xyzzyz]

* Yup, Each dropped packet pauses the entire connection until its retransmitted. *

Yeah, that's why the next step after SPDY/HTTP2 adoption is QUIC, which moves the web to UDP, and solves the head-of-line blocking.

https://en.wikipedia.org/wiki/QUIC

[userbinator]

which moves the web to UDP

That sounds like it'd just cause more congestion and dropped packets if not used carefully - and they'll eventually end up reinventing TCP on top of UDP...

[KaiserPro]

or just create one virtual stream across multiple sockets

[userbinator]

where the average webpage is 10-100megs in size[1] in around 5 to 10 years time

According to that link, the page sizes fortunately seem to be leveling off after a rather sharp jump between 2012 and 2014 (I wonder what happened there... a large increase in SPAs?) so I don't think they'll get that big in the near future - nor would it be a good thing if they did.