Slashdot Mirror
HTTP Intermediary Layer From Google Could Dramatically Speed Up the Web
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."
Now we can see Uncle Goatse twice as fast.
In the future, the content will be loaded before you click! Unfortunately, it's not like it today, so I didn't make the first post...
remove flash, java applets ad's
20X faster!
How is this different from Web servers that serve up gzipped pages?
If only the Google engineers can do something about Slashdot's atrociously slow Javascript. Like maybe they can remove the sleep() statements.
What, just because the original poster pulls a "look at me, I did something cool, therefore I must be cool!" doesn't mean I have to go along with it.
From the link
We downloaded 25 of the "top 100" websites over simulated home network connections, with 1% packet loss. We ran the downloads 10 times for each site, and calculated the average page load time for each site, and across all sites. The results show a speedup over HTTP of 27% - 60% in page load time over plain TCP (without SSL), and 39% - 55% over SSL.
1. Look at top 100 websites.
2. Choose the 25 which give you good numbers and ignore the rest.
3. PROFIT!
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.
Potato chips are a by-yourself food.
The problem isn't pushing the bits across the wire. Major sites that load slowly today (like Slashdot) typically do so because they have advertising code that blocks page display until the ad loads. The ad servers are the bottleneck. Look at the lower left of the Mozilla window and watch the "Waiting for ..." messages.
Even if you're blocking ad images, there's still the delay while successive "document.write" operations take place.
Then there are the sites that load massive amounts of canned CSS and Javascript. (Remember how CSS was supposed to make web pages shorter and faster to load? NOT.)
Then there are the sites that load a skeletal page which then makes multiple requests for XML for the actual content.
Loading the base page just isn't the problem.
Doesn't that mean that both the client and the server have to be running this new application to see the benefits of this? Essentially either one or the other is still going to be using HTTP if you don't set it up on both, and its only as fast as the slowest piece.
While a great initiative, it could be a while before it actually takes off. To get the rest of the world running on a new protocol will take some time, and there will no doubt be some kinks to work out.
But if anyone could do it, it'd be Google.
No. Akamai gives boxes to ISPs that cache Akamai's customer's content closer to the ISP's customers. Akamai then uses logic they've put together into DNS to redirect requests to the appliance closest to the request.
So which ports are you planning to use for it?
Deleted
You youngsters and your fancy text based web browsers. In my day, we used gopher, and we LIKED it!
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
AOL actually does something similar to this with their TopSpeed technology, and it does work very, very well. It has introduced features like multiplexed persistent connections to the intermediary layer, sending down just object deltas since last visit (for if-modified-since requests), and applying gzip compression to uncompressed objects on the wire. It's one of the best technologies they've introduced. And, in full disclosure, I was proud to be a part of the team that made it all possible. It's too bad all of this is specific to the AOL software, so I'm glad a name like Google is trying to open up these kind of features to the general internet.
here's an onion to hang on your belt, granpa.
now, on a more serious note, isn't gopher a faster protocol than HTTP ? could we just use it to transport html, pictures, etc ?
What ? Me, worry ?
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.
--- Bouh !!! ---
If only the Google engineers can do something about Slashdot's atrociously slow Javascript.
I've noticed a discernible difference in /. loadtime, in favor of Google Chrome vs FF 3.x on Mac OSX at home. And that's just the Chrome dev channel release. I was pleasantly surprised.
Reply to That ||
While we're at it, let's also make processing web pages faster.
We 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.
Here is my proposal:
- For the semantics, let's introduce an extensible language. Imagine it as a sort of programming language, where the standard library has elements for common things like paragraphs, hyperlinks, headings, etc. and there are additional libraries which add more specialized elements, e.g. there could be a library for web fora (or blogs, if you prefer), a library for screenshot galleries, etc.
- For the presentation, let's introduce something that actually supports the features of the presentation medium. For example, for presentation on desktop operating systems, you would have support for things like buttons and checkboxes, fonts, drawing primitives, and events like keypresses and mouse clicks. Again, this should be a modular system, where you can, for example, have a library to implement the look of your website, which you can then re-use in all your pages.
- Introduce a standard for the distribution of the various modules, to facilitate re-use (no having to download a huge library on every page load).
- It could be beneficial to define both a textual, human readable form and a binary form that can be efficiently parsed by computers. Combined with a mapping between the two, you can have the best of both worlds: efficient processing by machine, and readable by humans.
- There needn't actually be separate languages for semantics, presentation and scripting; it can all be done in a single language, thus simplifying things
I'd be working on this if my job didn't take so much time and energy, but, as it is, I'm just throwing these ideas out here.
Please correct me if I got my facts wrong.
No. Akamai offers many services and features beyond 'giving' boxes to ISPs. For instance, they have their own global CDN unrelated to any ISP which you can pay to have your content served across. They'll host it or reverse proxy/cache it. They also can multicast live streaming media, on demand streaming media, etc. You get the picture. In once sentence, Akamai is a high availability, high capacity provider of bandwidth. And they accomplish that in a variety of ways other than just putting boxes in ISPs.
"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.
How about we don't use HTTP/HTML for things they were not designed or ever intended to do? You know, that "right tool for the right job" thing.
There is no "-1 offended" or "-1 you don't agree with me" mod options for a reason.
It's not all rosy as the short documentation page explains. While they are trying to maximize throughput and minimize latency, they are hurting other areas. 2 obvious downsides I see are:
1. Server would now have to keep holding the connection open to the client throughout the client's session, and also keep the associated resources in memory. While this may not be a problem for Google and their seemingly limitless processing powers, a Joe Webmaster will see their web server load average increase significantly. HTTP servers usually give you control over this with the HTTP keep-alive time and max connections/children settings. If the server is now required to keep the connections open it would spell more hardware for many/most websites;
2. Requiring compression seems silly to me. This would increase the processing power required on the web server (see above), and also on the client - think underpowered portable devices. It needs to stay optional - if the client and server both play and prefer compression, then they should do it; if not, then let them be; also keeping in mind that all images, video and other multimedia are already compressed - so adding compression to these items would increase the server/client load _and_ increase payload.
oldermanwholikestofondleyou.cx
To follow the goatse.cx standard, I believe it should be http://oldermanwholikestofondleyour.co.ck
It's only $250 to register a .co.ck address!
The good news is that SPDY seems to build on the SMUX ( http://www.w3.org/TR/WD-mux ) and MUX protocols that were designed as part of the HTTP-NG effort, so at least we're not reinventing the wheel. Now we have to decide what color to paint it.
Next up: immediate support in FireFox, WebKit, and Apache -- and deafening silence from IE and IIS.
Gopher is not installed by default, kiddie...
Gopher is installed by default on most builds of Firefox. Try this in your address bar: gopher://gopher.floodgap.com/1/world
Paid Q&A/Research
you got my new Droid to be able to dial hands-free and sync with Outlook. Would help me out a bunch more than faster http. No, really...
Someone already invented this.
It's called Opera browser
"I disapprove of what you say, but I will defend to the death your right to say it." - historian Evelyn Beatrice Hall
Port 80? That newfangled HTTP thing? Gopher predates HTTP by a fair number of years. You can try that fancy pants modern trick now but back in the day, that would have got you nothing.
Of course, Gopher is newer than Telnet. And Telnet is newer than BBSs. And BBSs are newer than dialing in to the university mainframe over a 300 baud acoustic-coupled modem connected to a teletype, which is where I cut my teeth, sonny boy.
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
Mostly in that it handles tables and frames.
http://www.jikos.cz/~mikulas/links/
>>>acoustic-coupled modem
Which was the result of the Bell Telephone monopoly. They refused to let other non-Bell devices connect to their lines, which forced users to buy *only* Bell products. Man I hate monopolies. I despise them like Teddy Roosevelt despised them.
Fortunately somebody came-up with the idea of the acoustic modem, which connected *indirectly* via the usage of sound. Very primitive but they worked, and they didn't break Bell's rules, and more importantly, they opened-up the market to other companies.
THEN bell announced, if you were using a modem, you had to pay an extra surcharge for overusage of the line you paid for. Or else risk disconnection. Sound familiar? (cough Comcast). Most users ignored Bell's surcharge idea.
"I disapprove of what you say, but I will defend to the death your right to say it." - historian Evelyn Beatrice Hall
>>>Gopher predates HTTP by a fair number of years.
Not correct. Gopher and HTTP were both released in summer 1991, so virtually the same birthdate. However gopher was available on the IBM PC that same year while HTTP was still confined to Unix systems, so that's why people misremember gopher as being first. (HTTP came to IBM PC, Macs, and Amigas in 1993.)
"I disapprove of what you say, but I will defend to the death your right to say it." - historian Evelyn Beatrice Hall
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?
Don't kid yourself. It's the size of the regexp AND how you use it that counts.
If they really wanted a faster web, they would have minimized the protocol name. Taking out vowels isn't enough.
The protocol should be renamed to just 's'.
That's 3 less bytes per request.
I can haz goolge internship?
# To make SSL the underlying transport protocol, for better security and compatibility with existing network infrastructure. Although SSL does introduce a latency penalty, we believe that the long-term future of the web depends on a secure network connection. In addition, the use of SSL is necessary to ensure that communication across existing proxies is not broken.
The problem for that is now everything is encypted. If it has multiple channels, let one be plaintext of insecure items,a nd one cyphered for encrypted ones
We've had ideas along these lines-- specifically, we need to work on caching! One proposal that we had was that we'd send cryptographic hashes on the secure channel, then send the static data in the clear on a non-encrypted channel.
Alternatively, the data could be signed, and no communication would be necessary on the secure channel.
In any case, there is a lot of work to do on this, and we by no means have the answers right now. We just want to make the experiment public, and get as many people involved as we can so that we all end up with something better.
# To enable the server to initiate communications with the client and push data to the client whenever possible.
Horrible idea because now popup and ad blockers don't work. Sure they might not show it, but the server has already sent it to you and eaten up your bandwidth. What are your options? Send a block-list during negotiation? Not likely, and still might not be honored. We need to keep the client in control. What should be done is the server send the component list, and then the client can return the accepted list back to the server to have it put into the download stream. While this is the correct operation, the problem with this is it increases latency.
Well, the fact the server sends the data doesn't mean that the browser has to interpret it or render it. In the protocol, if/when the browser notices the server sending something it doesn't want, the browser can send a FIN (letting the other side know it should stop), and then can simply ignore the rest. It uses up some bandwidth, but it is really not that much worse than today... especially if we find that the real world tests also show it to be 2X faster on average!!
Oh, also.. the measured in-lab 2X speedup was without any server push. Who knows, maybe the HELLO message will eventually include a flag that says that the server shouldn't push anything to the client. We're already talking about how to rate-limit anything speculative like this (so that client-requested content is almost never held up with content that is speculatively pushed).
Most of the features of fasterfox are found in about:config. There is no sense in installing an addon that will slow the browser down when the browser already has pipelining and prefetching (albeit disabled)
One is the world wide web, the other is a cat.
"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?