Google Chrome replaces HTTP with SPDY for some Google websites(blog.alertfox.com)
blog.alertfox.com
Google Chrome replaces HTTP with SPDY for some Google websites
http://blog.alertfox.com/2011/05/your-chrome-browser-might-not-be-using.html
8 comments
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".
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/
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/
He's made it clear that all the text is a quote now, which means this is pretty much a duplicate of the (months old) original.
There's no original content here at all - flagged...
There's no original content here at all - flagged...
[deleted]
Yeah when I saw this, it didn't really strike me as "news" considering news is really well just that, and this is months old...
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.
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.
You can view the active connections here:
chrome://net-internals/#events&q=type:SPDY_SESSION%20is:active
chrome://net-internals/#events&q=type:SPDY_SESSION%20is:active
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.
Has anyone actually noticed a speed difference? I haven't - just curious.
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.
Also, they are just as much interested in the overall throughput at their end as the perceived speed at your end.
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'.
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'.
Am I the only one who is constantly getting SPDY protocol errors with Chrome?
What does a SPDY protocol error look like? I don't think I have encountered one yet.
Is there any way a user can tell a SPDY and a HTTP error apart?
Is there any way a user can tell a SPDY and a HTTP error apart?
Here's one I got a minute ago when trying to switch my google docs account.
http://i.imgur.com/9ZMiK.png
I reported the bug. I like that Google is trying to innovate here and will keep using Chrome.
http://i.imgur.com/9ZMiK.png
I reported the bug. I like that Google is trying to innovate here and will keep using Chrome.
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.
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.
Run Wireshark to try and find out what's going on on the wire.
...since 4 months!
I'm mentioning it because I think that source is actually much more informative.