[aavegmittal]

hmm… this caught my eye… "Immediately, we see that SPDY is far more adversely affected by packet loss than HTTPS is. This has been anticipated in other work [29] but never before tested. It is also contrary to what has been reported in the SPDY white paper [2], which states that SPDY is better able to deal with loss.”

[chetanahuja]

Well I've never really bought into the real win from multiplexing HTTP transfer over a single TCP connection. Yes the congestion window management against one server works better now. But what about all the other transfers going over the same narrow mobile connection? The HOL blocking in TCP in presence of even a tiny amount of packet-loss is another sign of almost total mobile blindness applied while designing HTTP2/SPDY.

[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.