HTTP Intermediary Layer From Google Could Dramatically Speed Up the Web 406
grmoc writes "As part of the 'Let's make the web faster' initiative, we (a few engineers — including me! — at Google, and hopefully people all across the community soon!) are experimenting with alternative protocols to help reduce the latency of Web pages. One of these experiments is SPDY (pronounced 'SPeeDY'), an application-layer protocol (essentially a shim between HTTP and the bits on the wire) for transporting content over the web, designed specifically for minimal latency. In addition to a rough specification for the protocol, we have hacked SPDY into the Google Chrome browser (because it's what we're familiar with) and a simple server testbed. Using these hacked up bits, we compared the performance of many of the top 25 and top 300 websites over both HTTP and SPDY, and have observed those pages load, on average, about twice as fast using SPDY. Thats not bad! We hope to engage the open source community to contribute ideas, feedback, code (we've open sourced the protocol, etc!), and test results."
and faster still.. (Score:4, Insightful)
remove flash, java applets ad's
20X faster!
How about telling Analytics to take a hike? (Score:5, Insightful)
And all other "add this piece of Javascript to your Web page and make it more awesomer!"
Yes, yes, they're useful. And you can't fathom a future without them. But in the meantime I'm watching my status bar say, "completed 4 of 5 items", then change to "completed 11 of 27 items", to "completed 18 of 57 items", to "completed... oh screw this, you're downloading the whole Internet, just sit back, relax and watch the blinkenlights".
Remember when a 768kbps DSL line was whizzo fast? Because all it had to download was some simple HTML, maybe some gifs?
I want my old Internet back. And a pony.
Comment removed (Score:5, Insightful)
Cool.... but it's not http (Score:5, Insightful)
So which ports are you planning to use for it?
Yeah, right... but WHY?!? (Score:2, Insightful)
I mean reinventing the wheel, well why not, this one is old and let say we have done all we could with HTTP...
But why, WHY should you call that with a stupid name like SPDY?!? It's not even an acronym (of is it?).
It sound bad, it's years (decade?) before it is well supported... but why not. Wake me when it's done ready for production.
I guess they start to get bored at Google if they are trying not rewrite HTTP.
Re:Solving the wrong problem (Score:2, Insightful)
What, you think after the first load that CSS file isn't cached in any way? Inline styles slow down every time, CSS just the first. CSS was supposed to make styling elements not completely braindead. You want to change the link colors with inline styles from red to blue? With inline styles - enjoy your grepping. You're bound to forget some of 'm, too.
Bitching about ad loading times and huge JS libraries? Sure, go ahead. CSS? No, that just makes you look silly.
Re:How about telling Analytics to take a hike? (Score:3, Insightful)
It's also why smart users filter them outright with something like AdBlock - anything that I see in the browser history that looks like a tracking/stats domain or URL gets blocked on sight. Come to think of it, I could probably clean it up publish it as an AdBlock filter list if anyone's interested; there's only a few dozen entries on there at the moment, but I'm sure that would grow pretty quickly if it was used by a more general and less paranoid userbase.
Re:Slashdot could use the help (Score:4, Insightful)
They need start with practicing what they preach...
http://code.google.com/speed/articles/caching.html [google.com]
http://code.google.com/speed/articles/prefetching.html [google.com]
http://code.google.com/speed/articles/optimizing-html.html [google.com]
They turn on caching for everything but then spit out junk like
http://v9.lscache4.c.youtube.com/generate_204?ip=0.0.0.0&sparams=id%2Cexpire%2Cip%2Cipbits%2Citag%2Calgorithm%2Cburst%2Cfactor&fexp=903900%2C903206&algorithm=throttle-factor&itag=34&ipbits=0&burst=40&sver=3&expire=1258081200&key=yt1&signature=8214C5787766320D138B1764BF009CF62A596FF9.D86886CFF40DB7F847246D653E9D3AA5B1D18610&factor=1.25&id=ccbfe79256f2b5b6 [youtube.com]
Most cache programs just straight up ignore this. Because of the '?' in there. It ends up being a query to static data.
Then never mind the load balancing bits they put in there with 'v9.lscache4.c.'. So even IF you get your cache to keep the data you may end up with a totally different server and the same piece of data just served from another server. There have been a few hacks to 'rewrite' the headers and the names to make it stick. But those are just hacks and while they work they seem fragile.
The real issue is at the HTTP layer and how servers are pointed at from inside the 'code'. So instead of some sort of indirection that would make it simple for the client to say 'these 20 servers have the same bit of data' they must assume that the data is different from every server.
Compression and javascript speedups are all well and good but there is a different more fundamental problem of extra reload of data that has already been retrieved. As local network usage is almost always faster than going back out to the internet. In a single user environment this is not too big of a deal. But in a 10+ user environment it is a MUCH bigger deal.
Even the page that talks about optimization has issues
http://code.google.com/speed/articles/ [google.com]
12 cr/lf right at the top of the page that are not rendered anywhere. They should look at themselves first.
Re:Solving the wrong problem (Score:4, Insightful)
CSS can make things shorter and faster if they just remember to link to it as a static file.
You can't cache something that changes, and anything, like CSS and Javascript, that's caught in the on-the-fly generation of dynamic and uncacheable text in spite of actually being static, is just going to clog up the tubes.
In fact, thanks to slashdot's no-edits-allowed policy, each comment itself is a static unchangeable snippet of text. Why not cache those?
Sending only the stuff that changes is usually a good optimization no matter what you're doing.
CSS and javascript themselves aren't bad. Failing to offlink and thus cacheable-ize them however, is.
SPDY is technically nonsensical (Score:2, Insightful)
"Single request per connection. Because HTTP can only fetch one resource at a time (HTTP pipelining helps, but still enforces only a FIFO queue)"
WTF you do realize that TCP is a head-of-line blocking protocol right? You can layer whatever the hell you want into a TCP channel and its still bound to TCPs shortcommings. If google really wanted to be productive they would leverge SCTP streams rather than reinventing crap that will never be optimal anyway... haha they even list this under "previous approaches" as if its somehow "legacy"
"Exclusively client-initiated requests. "
Nonsense, this was done in netscape 4.x
"Uncompressed request and response headers."
"Redundant headers"
gzip anyone?
"Optional data compression. Content should always be sent in a compressed format"
Its nice that google thinks it can dictate to operators.
If google really wanted to help speed up the fricking web they would discontinue adscense and google analyitics which adds extra RTTs to god knows what percentage of the entire web.
The real problem is all the commercial **CRAP** and too few selfless operators working to help people without expecting back in return.
I've never had to wait to bring up a wikipedia page.
Re:How about telling Analytics to take a hike? (Score:3, Insightful)
I want my old Internet back. And a pony.
LOL. I'd suggest disabling javascript and calling it a day.
Alternatively, use a text-based browser. If the webpage has any content worth reading, then a simple lynx -dump in 99% of cases will give you what you want, with the added bonus of re-formatting those mile-wide lines into something readable.
On the other hand, I suspect most people don't want the "old internet". What was once communicated on usenet or email in a few simple lines, for example, now increasingly appears in the form of a complex website that displays giant graphic-laden pages, replete with bad formatting and full of extraneous rubbish. And people like it!
Re:Slashdot could use the help (Score:3, Insightful)
How is this different from Web servers that serve up gzipped pages?
Well, for one, gzipping output doesn't have any effect on latency.
Re:and faster still.. (Score:5, Insightful)
Ye are joking, but ye are correct. Take this slashdot page. I used to be able to participate in discussion forum with nothing more than a 1200 baud (1kbit/s) modem. If I tried that today, even with all images turned off, it would take 45 minutes to load this page, mainly due to the enormous CSS files
It would be nice if websites made at least *some* attempt to make their files smaller, and therefore load faster.
Would appreciate it if instead... (Score:3, Insightful)
Re:Oh that's wonderful (Score:5, Insightful)
Re:How about telling Analytics to take a hike? (Score:3, Insightful)
It's not "free for the taking". It's "free in exchange for free content on the web".
(Note, I'm not arguing against ad blockers or the like.. just like I 30 second skip through the vast vast vast majority of commercials on my Tivos, and FFed through them on my VCR before that.)
SPDY (Score:3, Insightful)
Cache control 4tw. A lot of the user perception problems SPDY is trying to solve can be solved by utilizing already-existing protocol features and the farms of cache servers at ISPs for your active content.
The latency differences between a user going all the way to your server and grabbing your content vs. going to ISP's cache server to get it can be huge when you consider a separate connection for each part of the page. When coupled with the decreased response time (checking a cache file and responding with a 304 is a lot easier on your server than pulling your content out of a database, formatting it and sending the entire page) makes a huge end-user perception difference. It also frees resources on your web server faster because you are sending 20-30 bytes instead of x kb. The faster your server can get rid of that connection the better.
Doing this reduces the load on your server(especially connection utilization), your bandwidth utilization, speeds up the download of your page (since it avoids the need to leave the ISP for your content download) and generally makes you a better network citizen.
Of course this requires developers that understand the protocol.
What I want to know is will ISP cache servers will have this implemented?
Re:Oh that's wonderful (Score:2, Insightful)
You have a trigger finger too, commenting over moderation some 15 minutes after the message was posted. Slashdot moderation is like definite integration of a function convergent to 0 over 0,inf), there might be crap on the beginning but it'll fix itself up in the long run and evaluate to a correct value.
I know, I'm sorry, I couldn't come up with a good car analogy.
Re:While we're at it ... (Score:4, Insightful)
e have a semantic language (HTML) and a language that describes how to present that (CSS), right? This is good, let's keep it that way.
But things aren't as good as they could be. On the semantic side, we have many elements in the language that don't really convey any semantic information, and a lot of semantics there isn't an element for. On the presentation side, well, suffice it to say that there are a _lot_ of things that cannot be done, and others that can be done, but only with ugly kludges. Meanwhile, processing and rendering HTML and CSS takes a lot of resources.
The problem is that worrying about semantic vs presentation is something that almost no one gives a s**t about, because it is an artificial division that makes sense for computer science reasons, not human reasons. I don't sit down to make a web page and completely divorce the content vs the layout; the layout gives context and can be just as important as the content itself in terms of a human brain grasping an attempt at communication.
I know I shouldn't use tables for presentation but I just don't care. They are so simple and easy to visualize in my head, and using them has never caused a noticeable slowdown in my app, caused maintenance headaches, cost me any money, etc. The only downside is listening to architecture astronauts whine about how incorrect it is while they all sit around and circle-jerk about how their pages pass this-or-that validation test.
In oh so many ways writing a web app is like stepping back into computer GUI v1.0; so much must be manually re-implemented in a different way for every app. Heck, you can't even reliably get the dimensions of an element or the currently computed styles on an element. Lest you think this is mostly IE-vs-everyone else, no browser can define a content region that automatically scrolls its contents within a defined percentage of the parent element's content region; you've gotta emit javascript to dynamically calculate the size. This is double-stupid because browsers already perform this sort of layout logic for things like a textarea that has content that exceeds its bounds. And guess what? This is one of the #1 reasons people want to use overflow:auto. Don't waste screen real-estate showing scrollbars if they aren't necessary, but don't force me to hard-code height and width because then I can't scale to the user's screen resolution.
This kind of crap is so frustrating and wastes MILLIONS upon MILLIONS of man-hours year after year, yet we can't even get the major browser vendors to agree to HTMLv5 and what little bits (though very useful) it brings to the table. So please spare me the semantic vs presentation argument. If just a few people gave a s**t and stopped stroking their own egos on these bulls**t committees and actually tried to solve the problems that developers and designers deal with every day then they wouldn't have to worry about forcing everyone to adopt their standard (IPv6), the desire to adopt it would come naturally.
Re:Oh that's wonderful (Score:2, Insightful)
That was supposed to be the role of meta-moderation [slashdot.org], although I have to confess, where once I would do it daily, I haven't M2'd for a long time, not since one of the ajax makeovers completely fucked the interface
Re:Not a terribly new concept. (Score:3, Insightful)
It may be noble in goal, but AOL's implementation makes things hell on sysadmins trying to load-balance AOL users' connections. In a given session, even a page load, I can expect connections from n number of (published) AOL proxies, *and* the user's home broadband IP. It's not possible to correlate them at layer 3, so nasty layer-7 checks get used instead, and AOL users wind up getting shoved into non-redundant systems.
Re:and faster still.. (Score:3, Insightful)
Shhh...If people start thinking /. discussions work, half the people here won't have anything to complain about and will have to go back to spending the day working.
Re:Slashdot could use the help (Score:1, Insightful)
They turn on caching for everything but then spit out junk like
http://v9.lscache4.c.youtube.com/generate_204?ip=0.0.0.0&sparams=id%2Cexpire%2Cip%2Cipbits%2Citag%2Calgorithm%2Cburst%2Cfactor&fexp=903900%2C903206&algorithm=throttle-factor&itag=34&ipbits=0&burst=40&sver=3&expire=1258081200&key=yt1&signature=8214C5787766320D138B1764BF009CF62A596FF9.D86886CFF40DB7F847246D653E9D3AA5B1D18610&factor=1.25&id=ccbfe79256f2b5b6 [youtube.com]
As the name implies, generate_204 always receives an HTTP 204 (No Content) response, and is used mainly for logging statistics, so there's nothing to cache there.
Re:SPDY (Score:3, Insightful)
Absolutely the 304 response won't work anymore under that new proposal. And 304 already saves a lot as most external references are static.
There is only one exception, advertisements. One can only asume that Google wants this to effectively push advertisements on the user.
Re:and faster still.. (Score:3, Insightful)
What's the right tool for what's web apps today? (Score:3, Insightful)
"right tool for the right job"
Fair enough.
What's the right tool to deliver to your users rich applications which are
I don't know of any tool other than HTTP/HTML. I can imagine something with ssh and X forwarding, but windows boxes don't come with X preinstalled (nor ssh). Remote desktop, perhaps? Any other good ideas?