I Googled but didn't find anything about SPDY with slow or unreliable connections. I wonder if it also speeds that up, or if it might actually make things worse?
Which part of SPDY do you think might make it perform worse than HTTP over slow or unreliable connections? I can think only of TLS, and such SPDY documentation as I have seen claims that the latency drawbacks of using TLS are outweighed by other features of SPDY.
Well the first thing that triggered my wondering was that it's different. The second was that I read SPDY holds connections open. And the third was that I couldn't find anyone benchmarking different types of internet connections with it, just a generic '64% faster!' which hardly ever holds true regardless of connection type.
So my general skepticism kicked in and now I want to know.
Edit: To their credit, they said '64% reduction in page load time', which is a lot more quantifiable than '64% faster'.
If you email me (my username at chromium.org) with the bug link, I can make sure that it gets cc'ed to the correct people.
We would also probably want a net-internals dump: restart Chrome, open chrome://net-internals in a tab and leave it open while reproducing the error. Then switch back to the net-internals tab and dump the log to a file and attach to the bug.
That source (a blog post by Ilya Grigorik) is not only more informative, but a significant portion of this article seems to have been plagarized from it. While this AlertFox article does link to Grigorik's post, it copies significant parts without proper attribution. The second paragraph even replicates one of Grigorik's article headings, "SPDY in the wild".
Hi... me here: At no point it was my intention to claim ownership of this discovery. I simply wanted to share it with our users. I thought (and still think) quoting the author in the first line of the article makes the original source very clear: "I was googling for some Google Chrome documentation today, and discovered a fascinating post by Ilya Grigorik: ". Will now set the Ilya's text in cursive to make it 100% clear.
If claiming ownership is not your intention, you should make it clear by using blockquotes or otherwise setting the quoted text apart from your own observations.
I find it difficult to give you the benefit of the doubt when it looks like you have used text from other sources in the past without giving any attribution at all.
http://blog.alertfox.com/2011/05/myth-by-reporting-infrastru... seems to use text from a HP whitepaper on infrastructure monitoring from 2008, "Five Myths of Infrastructure Monitoring: How End User Monitoring Can Help You Improve Customer Satisfaction".
I think SPDY is a big step forward, but Chrome only supports it when TLS NPN is used (which requires the server to use a patched version of OpenSSL, and is impossible with SChannel).
If SPDY is to be adopted on a large scale, things like the Connection: Upgrade header should at least be supported as an alternative to NPN.
This has been in place for many months and will have been subject to gradual phase-in and constant incremental tuning, so nobody will have been able to notice a distinct jump in speed. It's about shaving off the milliseconds and the microseconds.
Also, they are just as much interested in the overall throughput at their end as the perceived speed at your end.
There was a separate article a couple weeks back that talked about how mobile apps shouldn't use TCP/IP since its linear and mobile has a tendency to do crazy things like switch towers. Sounds like SPDY would be much more useful as a defacto mobile protocol.
21 comments
[ 3.1 ms ] story [ 48.3 ms ] threadSo my general skepticism kicked in and now I want to know.
Edit: To their credit, they said '64% reduction in page load time', which is a lot more quantifiable than '64% faster'.
Is there any way a user can tell a SPDY and a HTTP error apart?
http://i.imgur.com/9ZMiK.png
I reported the bug. I like that Google is trying to innovate here and will keep using Chrome.
We would also probably want a net-internals dump: restart Chrome, open chrome://net-internals in a tab and leave it open while reproducing the error. Then switch back to the net-internals tab and dump the log to a file and attach to the bug.
I'm mentioning it because I think that source is actually much more informative.
I find it difficult to give you the benefit of the doubt when it looks like you have used text from other sources in the past without giving any attribution at all.
http://blog.alertfox.com/2011/05/myth-by-reporting-infrastru... seems to use text from a HP whitepaper on infrastructure monitoring from 2008, "Five Myths of Infrastructure Monitoring: How End User Monitoring Can Help You Improve Customer Satisfaction".
http://blog.alertfox.com/2011/05/www-or-no-www-is-not-same.h... seems to have some of the same text at http://www.awebguy.com/2011/02/seo-tip-www-or-no-www/
There's no original content here at all - flagged...
If SPDY is to be adopted on a large scale, things like the Connection: Upgrade header should at least be supported as an alternative to NPN.
chrome://net-internals/#events&q=type:SPDY_SESSION%20is:active
Also, they are just as much interested in the overall throughput at their end as the perceived speed at your end.