6 ms·
That's a non sequitur - SPDY shows markedly improved performance over wired and 802.11 networks. The underlying problem discussed in the paper is down to TCP's
by matthewmacleod 13y ago
That's a non sequitur - SPDY shows markedly improved performance over wired and 802.11 networks. The underlying problem discussed in the paper is down to TCP's interaction with cellular networks, and just happens to particularly punish SPDY somewhat more than HTTP.
That's something that can be worked on and indeed there's a recommendation for improving it. I'd hope something like this would be included in HTTP/2.0, or at least in a subsequent revision.
- josteink 13y agoSince SPDY was created with DSL MTUs in mind[1] and optimized for them only (unlike plain HTTP which was transport neutral and lasted almost 20 years) I don't find it hard to believe that if you look anywhere outside Google's test-matrix you will see the benefits of SPDY tapering away almost instantly. [1] Basically, the test was: will one web-request (including all of Google's tracking headers) to google.com or any of its adwords/analytics beacons exceed one TCP packet and cause possible TCP reassembly-issues or not when using regular consumer-grade DSL MTUs?
- username223 13y agoIf they want to save a bit of bandwidth, how about removing this HTTP header? > P3P: CP="This is not a P3P policy! See http://www.google.com/support/accounts/bin/answer.py?hl=en&answer=151657 http://www.google.com/support/accounts/bin/answer.py?hl=en&a... for more info." I can't believe they're still adding that...