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."

Comments

Oh that's wonderful

[Anonymous Coward]

Now we can see Uncle Goatse twice as fast.

Re:Oh that's wonderful

[Exception Duck]

Do you have a link for you uncles web page ?

Re:Oh that's wonderful

[Anonymous Coward]

http://www.goatse.cx/

Re:Oh that's wonderful

[D'Sphitz]

People take their slashdot comments way too seriously. Mod me whatever, it means nothing and I'll move on.

Re:Oh that's wonderful

[Anonymous Coward]

http://www.goatse.cx/

Surely you mean spdy://www.goatse.cx/

Re:Oh that's wonderful

[operagost]

Wow... how long has it been since someone was modded UP for goatse?

Re:Oh that's wonderful

[Simon (S2)]

I want my old Internet back.

ME TOO!

Re:Oh that's wonderful

[Enleth]

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:Oh that's wonderful

[krelian]

Slasdhot should track where moderators spend their mod points. Those who spend it all on the first five posts should be disqualified from moderating.

Re:Oh that's wonderful

[nschubach]

Just over 2 hours.

Re:Oh that's wonderful

[Vainglorious Coward]

Slasdhot should track where moderators spend their mod points.

That was supposed to be the role of meta-moderation, 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:Oh that's wonderful

[somersault]

Slashdot moderation is like the average fuel consumption on your car's trip computer. If you reset it while rolling down a hill you'll get insane MPG figures, but after that it'll fix itself up in the long run and evaluate to a correct value.

Re:Oh that's wonderful

[Josh04]

Incorrect. If you get modded down with all the force someone can muster, you're restricted to posting twice per day.

Re:Oh that's wonderful

[ZeroExistenZ]

Try "Freenet", its exactly like the internet of the 90s. Porn, warez, crappy "personal webpages" with nonsensial rants about nothing and an attempt to hacker culture. Also naked babies.


For a moment I thought I wanted it back, until I saw it back and realized we've grown so utterly bored with the old internet we have been trying to find a new internet. Now the new new internet has grown boring and lame too, I'm awaiting the next innovation (while I try to innovate user experience myself.)

Re:Oh that's wonderful

[Toonol]

I haven't M2'd for a long time, not since one of the ajax makeovers completely fucked the interface

I metamod occasionally, but I sympathize with your complaints. The interface is terrible, although it's not as bad as the user settings. I have two computers on my desk, side by side, same version of firefox, and I can't get slashdot to behave the same on both of them. The settings seem to have random effects, and the bizarre attempt at javascript pop-up windows make me almost think it would be an improvement if they switched to Flash.

Re:Oh that's wonderful

[Toonol]

Try "Freenet", its exactly like the internet of the 90s. Porn, warez, crappy "personal webpages" with nonsensial rants about nothing and an attempt to hacker culture. Also naked babies.

You make it sound so tempting. Do you still need some sort of trusted invite to access freenet? That was kind of my sticking point; I don't know anybody as paranoid as myself, and I have no desire to go around the net trying to find somebody who's already on it. My other sticking point, of course, was that it was in Java. Is that still the case?

Re:Oh that's wonderful

[skovnymfe]

http://www.goatse.asia/ actually.

Re:Oh that's wonderful

[TheTurtlesMoves]

I would mod you up if i had mod points ;)

Re:Oh that's wonderful

[GooberToo]

Doesn't this mean we'd all be using Google as a proxy for all internet traffic? That means they'd know about all of your traffic rather than just searches. I guess that means they'd know you want to see Goatse twice as fast without you having to search for it.

Re:Oh that's wonderful

[ArsenneLupin]

Wow... how long has it been since someone was modded UP for goatse?

Amazing! Doubly amazing since it's not even the correct address any longer (the legitimate site has been shut down, and is now occupied by a squatter who is into robot fetish...).

An address that still serves the original content is http://goatse.fr

Enjoy, and let the mod points roll in!

Re:Oh that's wonderful

[pfafrich]

Old joke, off topic, not interesting. What are the mods playing at these days. Mod parent down.

Re:Oh that's wonderful

[harmonise]

Or make it so you can only mod one comment per story.

Re:Oh that's wonderful

[grmoc]

No- the protocol has nothing to do with proxying.

Before you click!

[courteaudotbiz]

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...

Re:Before you click!

[oldspewey]

content will be loaded before you click!

Sounds like those "dialup accelerators" from back in the '90s ... the ones that would silently spider every link on the page you're currently viewing in order to build a predictive cache.

Re:Before you click!

[mcgrew]

In the future, the content will be loaded before you click!

Wouldn't you have to have some thiotimoline and water in your mouse for that to work? Thiotimoline ain't cheap, you know.

Re:Before you click!

[wolrahnaes]

Which of course led to quite amusing results when some failure of a web developer made an app that performed actions from GET requests. I've heard anecdotes of entire databases being deleted by a web accelerator in these cases.

From RFC2616:

Implementors should be aware that the software represents the user in their interactions over the Internet, and should be careful to allow the user to be aware of any actions they might take which may have an unexpected significance to themselves or others.

        In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered “safe”. This allows user agents to represent other methods, such as POST, PUT and DELETE, in a special way, so that the user is made aware of the fact that a possibly unsafe action is being requested.

        Naturally, it is not possible to ensure that the server does not generate side-effects as a result of performing a GET request; in fact, some dynamic resources consider that a feature. The important distinction here is that the user did not request the side-effects, so therefore cannot be held accountable for them.

Re:Before you click!

[commodore64_love]

>>>Sounds like those "dialup accelerators" from back in the '90s ...

Hey I still use one of those you insensitive clod! It's called Netscape Web Accelerator, and it does more than just prefetch requests - it also compresses all text and images to about 10% original size. How else would I watch 90210 streaming videos over my phoneline?

Why I can almost see what looks like a bikini. Man Kelly is hot... ;-)

Re:Before you click!

[Hatta]

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...

In the future, the future will happen in the past.

Re:Before you click!

[commodore64_love]

But seriously...

the accelerator (compression) is really useful, and I couldn't imagine using dialup without it. It makes those slow 28k or 50k hotel connections look as fast as my home DSL hookup. (Except for the blurry images of course.)

Re:Before you click!

[grmoc]

Its not the same, really...
SPDY could do prefetching (in which case it'd be server push, instead of a new pull), but mainly what it does is it lets a lot of requests use the same connection, and does compression on the HTTP headers.
Thats essentially almost all of the current performance advantage (for today).

Re:Before you click!

[unix1]

That's called link pre-fetching and it has already been done.

Re:Before you click!

[Steve Franklin]

In the future, the entire web will be downloaded to your brain as you sleep--along with your current belief system and the current standings of Eastasia, Oceania, and Eurasia.

Re:Before you click!

[Nefarious Wheel]

Wouldn't you have to have some thiotimoline and water in your mouse for that to work? Thiotimoline ain't cheap, you know.

It's also an unstable compound before it resublimates. There are people however who have successfully posted warnings of explosions after the fact, but you do have to be quick.

Re:Before you click!

[operagost]

You need to stay away from fleabag hotels. Even Super 8 has wireless internet now.

Re:Before you click!

[auLucifer]

This depends on where you're from. I stayed in a 4-star hotel in our nations capital (Canberra, Australia) where they charge something like $1 first 20mb, $1 every mb after that and you pretty much only had a 256k connection so I could definitely see an accelerator being handy there.

Re:Before you click!

[Enleth]

Well, how do I POST something from a normal link without resorting to JavaScript, then?

I agree that this abuse of GET is quite unfortunate, but the only alternative is to make every action-inducing link into a form, even though it's not really a form in the semantic sense of the word because there are no fields in it (a hidden one or two, maybe), only a "submit" button, and the code is several times longer than it would be for a link. Which becomes, well, a button, not a link, bringing a major PITA for the visual designer, because the browser will render it as a button (which would certainly make sense in an actual form, but not in this case) and make it just impossible to shoe-horn it to look and behave like a link, even with the mightiest amounts of CSS thrown at the problem. Hell, it's impossible to make it look and behave consistently on all browsers and OSes, because some browsers will aply some styles to some form controls, some won't and some will just display the OS controls with the OS' choice of colors. Or even the OS controls with the CSS-provided colors, for the utter horror of any designer.

Are you still going to call web developers names over that?

Re:Before you click!

[REggert]

I wish the Tomcat developers would read RFCs. Or perhaps they consider it a "feature" that I can undeploy my webapp by hitting my browser's Back button while logged into the Manager application....

Re:Before you click!

[Arthur Grumbine]

it also compresses all text and images to about 10% original size.

Who knew that using smaller fonts reduced page-size/load-time? Oh, the wonders you bring us, Netscape!

Re:Before you click!

[Arthur Grumbine]

I think a 'Funny' bomb exploded all over this thread. It's like reading normal headlines after reading The Onion for hours straight - your mind can give the most tragic/serious headline a hilarious meaning, if it's been conditioned to expect it.

Re:Before you click!

[Hurricane78]

Yes. thedailywtf.com has such stories. I specifically remember one, where the delete button of database entries was a GET link from the list page. So Google's little spider went there, and crawled the entire list. Requested every single delete link address on the page. I think it was not even linked from anywhere. The crawler got there by reading out the referrer addresses from when the developers came to Google from a link on that site.

And if I remember correctly, it of course was a non backuped production database. The only one in fact. Must have been fun. :)

Re:Before you click!

[TheRaven64]

but mainly what it does is it lets a lot of requests use the same connection

You mean like HTTP/1.1 does?

and does compression on the HTTP headers

Are the headers really that big? You can compress the content with gzip automatically - I'm surprised that header compression makes a difference. Generally, the header is a small fraction of the size of the response.

Re:Before you click!

[grmoc]

Yup. They're pretty big (cookies can be HUGE!)
Take a look here:
http://sites.google.com/a/chromium.org/dev/spdy/spdy-whitepaper

"Header compression resulted in an ~88% reduction in the size of request headers and an ~85% reduction in the size of response headers. On the lower-bandwidth DSL link, in which the upload link is only 375 Kbps, request header compression in particular, led to significant page load time improvements for certain sites (i.e. those that issued large number of resource requests). We found a reduction of 45 - 1142 ms in page load time simply due to header compression."

Re:Before you click!

[mysidia]

That's because a 'button' is a visual cue to the user by the browser that this element will perform a POST action if pressed. it's a way of ensuring the user knows they aren't just following a passive link.

If you want to use a non-standard element such as a link for that, you should script it.

It happens to be really easy to script POST submission.

So you have the option of using scripting/CSS to style your links, or you can use the standard widgets users are familiar with:

Links for idempotent information requests. Submit or Button elements for requesting actions.

Re:Before you click!

[mcrbids]

There was one more detail: security authentication was being handled by Javascript, which the Googlebot doesn't bother with...

Re:Before you click!

[mccrew]

Are the headers really that big? You can compress the content with gzip automatically - I'm surprised that header compression makes a difference. Generally, the header is a small fraction of the size of the response.

Did you RTFA?

"Header compression resulted in an ~88% reduction in the size of request headers and an ~85% reduction in the size of response headers. On the lower-bandwidth DSL link, in which the upload link is only 375 Kbps, request header compression in particular, led to significant page load time improvements..."

Re:Before you click!

[BikeHelmet]

How else would I watch 90210 streaming videos over my phoneline?

Codecs have gotten so impressive now that 256x160 30fps can be streamed over 56k.

Re:Before you click!

[Inthewire]

This depends on where you're from.

Nah, it depends on where you're at.

Re:Before you click!

[dlgeek]

I'll skip your questions about the headers, since other people have already replied. As for using the same connection, if you read the paper, you'll see it's very different than HTTP/1.1. HTTP/1.1 allows pipelining requests on a single connection, but there's only one serialized stream - any delay (such as having to hit disk instead of cache or whatnot) holds up the entire stream. You save the cost of reopening a TCP connection, but you can't do anything in parallel. Thus, modern browsers usually use about 6 different TCP connections, which throws off all of the optimizations TCP does. SPDY multiplexes multiple streams into one connection so things can be served in parallel. Thus if you're hitting the disk retrieving one object, you can still send the next one out of the cache.

Re:Before you click!

[Progoth]

Google had a web accelerator back in the day. It's one of the earliest apps I remember Google launching. "Wow, they're giving away their software and bandwidth for free? Not related to their search engine? What's the catch?" They pulled it pretty quickly after it started deleting databases.

I'm getting pretty old and my memory's getting foggy, so I could be wrong...it's hard to remember back to the "advances" that were happening in ~1999-2001 while I was drunk on my new GATech dorm internet power. So if it was another company then I apologize in advance.

Re:Before you click!

[GravityStar]

Reference: http://www.quasimondo.com/archives/000225.php

Re:Before you click!

[TheRaven64]

This same benefit can be achieved by running HTTP over SCTP instead of TCP (which can be done without modifying existing servers or clients on some systems, such as FreeBSD, and with tiny changes on others). Compressing headers may still be a benefit, although I'm still a bit surprised it makes a noticeable difference. For most HTTP requests, I'd expect them to fit into a single packet, so the upstream bandwidth shouldn't be a limiting factor, the latency will be. The really big requests will be the ones that contain lots of cookies, and these are much less likely to compress well (they'll contain UUIDs and other random data).

Re:Before you click!

[dlgeek]

And if you read the article, it discusses this already! I think you're underestimating the amount of work required by the client to implement SCTP properly. Also, as a minor point, they're not just running gzip on the headers, they're caching them in some manner so they don't have to be sent with every request.

Re:Before you click!

[commodore64_love]

>>>Even Super 8 has wireless internet now.

Yeah for $10 more per night (last I checked). That adds-up fast when you spend a couple weeks in the same location. Sometimes I get lucky and find a place with a wired cable connection, for free, but if not then I use the phoneline.

Besides dialup is really not as bad as everyone claims. You can't watch hulu.com, but you can watch youtube, listen to streaming radio, or read news sites. You can even bittorrent over dialup (albeit slowly).

     

Re:Before you click!

[commodore64_love]

That's not even funny.

Or perhaps you have you not heard of ZIP? It can compress text to 10 or even 5 percent original size. The Netscape accelerator works on the same principle.

Re:Before you click!

[byron036]

<input type="submit" value="Delete" style="background:transparent;border:none;" />

or

<noscript> <input type="submit" value="Delete" /> </noscript> <script>script_form(); //puts a submission interface into the DOM</script>

Easy-peasy. User-Agents without JS get a crappy but functional interface. Graceful degradation

and faster still..

[Anonymous Coward]

remove flash, java applets ad's
20X faster!

Re:and faster still..

[amicusNYCL]

You could also remove images, CSS, Javascript, and text, imagine the time savings!

Re:and faster still..

[Joe Mucchiello]

Remove the content too. It's all meaningless stuff like this post.

Re:and faster still..

[commodore64_love]

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.

Re:and faster still..

[icebraining]

So save the CSS to your HD and put a filter in an extension/proxy/etc to replace the CSS URL with your local file. Wait, isn't that what the cache is for? Hmm...

Re:and faster still..

[ProfessionalCookie]

Is there any commonly useful Java applets left out there. I disabled Java years ago!

Re:and faster still..

[Mystra_x64]

Maybe /. need to gzip them (once after changing) or something.

Re:and faster still..

[ProfessionalCookie]

Are you kidding? The new slashdot is way easier to participate on from dialup. The CSS file may look huge but it's a 29KB one time download.

Cache headers are set to one week so unless you're clearing your cache every page load it's amounts to nothing.

If anything the scripts are bigger, but again, cached. Besides AJAX comments were a huge improvement for those of us on dialup- no more loading the whole page every time you did anything.

CSS and JS, when used correctly make things faster for users, even (and sometimes especially) for those of us on slow connections.

Re:and faster still..

[Arthur Grumbine]

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

I see ye've done yer part in returnin to the small page size days of yore by reducin the # of characters in yer post, but the '?' remains: Why the hell would ye still be connectin to /. w/ a 1200 baud modem?! Unless ye be a pirate connectin usin plunder obtained from the dumpster behind the thrift store...

Re:and faster still..

[Hurricane78]

I think they do. I don't think anyone doesn't at least use gzip support in Apache.

Re:and faster still..

[daem0n1x]

I think Flash should be made illegal. Yesterday I visited a website 100% made in Flash. I had to wait for it to load and then none of the links worked. Many Flash sites' links don't work in Firefox, I have no idea why. I suspect incompetent developers.

I sent a furious email to the company saying I was going to choose one of their competitors just because of the lousy website. I got a reply from their CEO basically saying "go ahead, we don't give a fuck".

Flash is like cake icing. A little bit tastes and looks great but many people find it cool to put a ton of sugar in the icing until it's nauseating.

Re:and faster still..

[edumacator]

The new slashdot is way easier to participate on from dialup.

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:and faster still..

[cain]

And it's 20.01x faster when you remove unneeded apostrophe's. :)

Re:and faster still..

[Mystra_x64]

Oops, it seems you are right.

Re:and faster still..

[ProfessionalCookie]

Down troll! Don't bite!

Keep in mind that if you're not using CSS they you have to declare the style for every element that exists.

Also compressed encoding means that the full payload for CSS is less than 50K. I don't know what kind of connection you're banished to that makes that an "f- load slower" but maybe you should consider switching from manual morse decoding to something automatic.

rather than camp on slashdot and its ilk

...as you peruse the comments.

Re:and faster still..

[wisty]

Install Adblock and its ... oh wait, not gunna happen.

Re:and faster still..

[StuartHankins]

Try accessing many sites from an iPhone or iPod Touch to see just how bad the problem really is.

Re:and faster still..

[TheTurtlesMoves]

Lynx for the win!

Re:and faster still..

[ConceptJunkie]

I heard of a program called DeCSS. Maybe that's what it does!

Re:and faster still..

[amicusNYCL]

Actually, no. Lynx is never, ever "for the win".

Re:and faster still..

[cffrost]

How about naming names so those inclined can join in the fun?

Enough "lost customers" and perhaps this alleged CEO and his ilk will start fuck-giving.

Slashdot could use the help

[Anonymous Coward]

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.

Re:Slashdot could use the help

[Anonymous Coward]

They need start with practicing what they preach...

http://code.google.com/speed/articles/caching.html
http://code.google.com/speed/articles/prefetching.html
http://code.google.com/speed/articles/optimizing-html.html

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

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/
12 cr/lf right at the top of the page that are not rendered anywhere. They should look at themselves first.

Re:Slashdot could use the help

[amicusNYCL]

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:Slashdot could use the help

[Culture20]

Not +1 Funny. Parent is +1 Informative. On the same wifi network, my iPhone took three minutes to render /. while my dual core lappy rendered it in about 10 seconds (count it; it's actually a long time). BTW, on my laptop, FF grayed out for that time. /.'s JS code sucks hard. I haven't looked, but I'm seriously starting to believe that it's got distributed computing code built in. Both machines loaded other webpages fine before and after.

Re:Slashdot could use the help

[Minwee]

Like maybe they can remove the sleep() statements.

The technical term for that is a Speedup Loop. All good software developers use them... for certain values of 'good'.

Re:Slashdot could use the help

[vikstar]

They've had a solution for a long time.

Re:Slashdot could use the help

[grmoc]

Heh, no it doesn't mean you have to go along with it...
But to answer your question, it is quite different from gzipping the pages!

Re:Slashdot could use the help

[icebraining]

You are confusing latency with round-trip time.

Latency is the time taken for a sent packet of data to be received at the other end. It includes the time to encode the packet for transmission and transmit it, the time for that data to traverse the network equipment between the nodes, and the time to receive and decode the data.

If you gzip the data, it takes less time to be transmitted, so it effectively reduces latency.

Re:Slashdot could use the help

[amicusNYCL]

You are confusing a packet with the entire message. Compressing the data means there are fewer packets, but it doesn't affect the time that it takes for one packet to be transmitted. It means the overall transfer takes less time, but the time to transfer a single packet is not affected.

Re:Slashdot could use the help

[nilbog]

Well now they could transfer gzipped pages over SPDY.

Re:Slashdot could use the help

[ProfessionalCookie]

Actually how about local persistent browser cross site javascript/css caches that validate based on signature? Something like

<script type="text/javascript" src="/scripts/jquery-min-1.3.3.js?v=132" local="com.jquery.min.133.js" sig="eaa41fbd734596533e98e557eae39b8b" />

The browser comes with copies of commonly used libraries or has access to a repository or downloads them from anywhere and validates sigs, using the same code where sigs match.

Re:Slashdot could use the help

[Anonymous Coward]

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

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:Slashdot could use the help

[windwalkr]

He's right though; the user cares about the response time between their action and the final result. They care about the time cost of transferring multiple packets just as much as they care about the time cost for the round trip. To optimize this, you can attack either:

* The round trip time (outside the reach of most users and companies.)
* The number of round trips (may be open to tweaking by predicting which files will be requested as a group, etc.)
* The quantity of data transferred. This tends to have less impact than the others for people on fast connections, but still adds up. For people on slower connections, this may be the largest factor.

Re:Slashdot could use the help

[oranGoo]

GP/TFA is not talking about transport layer latency, but about application layer latency (incurred by the protocol). Hence he is not confusing things too much: 'overall transfer' time you talk about is the 'web latency' that TFA talks about. Er... yes, I might have read it, sorry about that. They are certainly not aiming to improve/fix TCP from applicaiton layer, but what they are trying to fix is the fact that that the http protocol had been designed for single, short request and a single, possibly lengthy response, which typically gets rendered as it is arriving (transfer of the hyper-text, which is basically err.. text, with possibly hypers in it). Today, with all the ajax, streams, uploads, etc... we have quite a different scenario and there is room for improvement. Now, if only someone would fix mail protocols.

Re:Slashdot could use the help

[amicusNYCL]

He's right though; the user cares about the response time between their action and the final result.

I know that, but he asked what the difference was between SPDY and output compression. The difference is that SPDY decreases the latency, and output compression decreases the total message length. They both have an effect on the total time the user sees, but they aren't the same. Obviously combining both low latency and a smaller message would be the ideal situation, if you could transfer several files in one request that would be even better.

Re:Slashdot could use the help

[oranGoo]

He's right though; the user cares about the response time between their action and the final result.

I know that, but he asked what the difference was between SPDY and output compression. The difference is that SPDY decreases the latency, and output compression decreases the total message length.

SPDY (from the TFA):

- does decrease total message length by compressing request headers

- multiplexes streams (so there needn't be a new connection for every single request)

- prioritizes requests (will make easier for servers to prioritize noise=ads)

All of these aim to decrease 'web latency'.

Re:Slashdot could use the help

[dodobh]

If that's a GET request, it can be cached. GET semantics imply that the same URL will always return the same value.

Re:Slashdot could use the help

[badkarmadayaccount]

I just spent 3 hours at that site, trying to get away. And my parents are taking me to a psychiatrist next week, because I have an "overdeveloped sense of humor". Thanks. Thanks for nothing.

Re:Slashdot could use the help

[badkarmadayaccount]

Mod parent up.

Just turn off image loading

[Anonymous Coward]

You can generally surf the web ten times or faster if you just
1) Turn off image loading
2) Turn off Javascript
3) Turn off Java
4) Turn off plugins

yeah, yeah... I know... It's called "lynx"

Re:Just turn off image loading

[spun]

You youngsters and your fancy text based web browsers. In my day, we used gopher, and we LIKED it!

Re:Just turn off image loading

[C0vardeAn0nim0]

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 ?

Re:Just turn off image loading

[shentino]

Speaking seriously, once the main page of HTML is downloaded you pretty much know already where everything goes.

Just stub it out with "loading" boxes in spots where you don't have all the content. Especially if parameters like width= and height= already fix how big the final image is going to be.

When something finishes loading, just update the layout.

Re:Just turn off image loading

[gmuslera]

Gopher is not installed by default, kiddie. But my old trusty telnet to port 80 is still working like the 1st day.

Re:Just turn off image loading

[mattack2]

Or "links" if you care at least a little about the visual presentation of the page.

Re:Just turn off image loading

[ribuck]

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

Re:Just turn off image loading

[commodore64_love]

Wow. That's the first time I've visited a gopher site since.... Fall 1994? I tried gopher, but found the http:/// protocol to be much more useful, especially for looking-up seaQuest, earth2, and other fan sites. It's been a long, long time.

>>>my old trusty telnet to port 80 is still working like the 1st day.

Bah. Humbug. All you need is 1 megahertz 6502 with a 256k RAM expansion. You kiddies today are spoiled. ;-)

Re:Just turn off image loading

[commodore64_love]

Someone already invented this.

It's called Opera browser

Re:Just turn off image loading

[spun]

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.

Re:Just turn off image loading

[commodore64_love]

How is Links superior to Lynx?

Re:Just turn off image loading

[mattack2]

Mostly in that it handles tables and frames.

http://www.jikos.cz/~mikulas/links/

Re:Just turn off image loading

[commodore64_love]

>>>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.

Re:Just turn off image loading

[commodore64_love]

>>>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.)

Re:Just turn off image loading

[icebraining]

http://kb.mozillazine.org/Nglayout.initialpaint.delay

Re:Just turn off image loading

[operagost]

I think we just slashdotted a Gopher site.

Re:Just turn off image loading

[spun]

Thanks for the correction of my fuzzy old memories. :) I thought I had used Gopher in my last year of uni, but must have been mistaken. Probably used it that next summer at my first internship.

Re:Just turn off image loading

[ProfessionalCookie]

Hey look at that- informative.

Re:Just turn off image loading

[ProfessionalCookie]

One is the world wide web, the other is a cat.

Re:Just turn off image loading

[JSG]

Nope, it's working fine and quite quickly. Sadly my Squid mangled its output rather badly ...

Re:Just turn off image loading

[crt]

Seems like most gopher sites are just lists of... other gopher sites. Kind like the web in 1993 (when there were 100 web sites and all the content was in Gopher). Guess they finally swapped places.

Re:Just turn off image loading

[commodore64_love]

I tried to edit that variable in Firefox 3.0, but I don't see it in the about:config list

Suspicious....

[Anonymous Coward]

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!

Re:Suspicious....

[hesaigo999ca]

I have to agree here, let's take all top 100 websites would have given a much clearer picture for a benchmark, although I guess now google is doing the same as M$ in these regards, they need to keep making profits I guess.....so much for do no evil.

How about telling Analytics to take a hike?

[rho]

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.

Re:How about telling Analytics to take a hike?

[ramaboo]

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.

That's why smart web developers put those scripts at the end of the body.

Re:How about telling Analytics to take a hike?

[thestudio_bob]

I want my old Internet back. And a pony.

You forgot to yell at the kids to get off your internet.

Re:How about telling Analytics to take a hike?

[gbarules2999]

I want my old Internet back. And a pony.

If Slashdot does OMG Ponies again will that satisfy your wants and needs?

Re:How about telling Analytics to take a hike?

[Zocalo]

That's why smart web developers put those scripts at the end of the body.

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:How about telling Analytics to take a hike?

[gstoddart]

Remember when a 768kbps DSL line was whizzo fast?

Jeebus. I remember when my 1200 baud modem felt whizzo fast compared to my old 300 baud modem.

And, yes, I can already see the "get off of my lawn" posts below you, and I'm dating myself. :-P

Cheers

Re:How about telling Analytics to take a hike?

[value_added]

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:How about telling Analytics to take a hike?

[93 Escort Wagon]

Adsense is embedded where the ads are going to be, Google Maps scripts are embedded where the map is going to be, etc.

This doesn't have to be the case, unless you're still coding per 1997 standards. Even with CSS 1, you can put those DIVs last in the code and still place them wherever you want them to be.

It's what I do with the Google ads (text only ads, FWIW) on one of my personal sites - so the content loads first, and then the ads show up.

Re:How about telling Analytics to take a hike?

[causality]

That's why smart web developers put those scripts at the end of the body.

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.

What's paranoid about insisting that a company bring a proposal, make me an offer, and sign a contract if they want to derive monetary value from my personal data? Instead, they feel my data is free for the taking and this entitlement mentality is the main reason why I make an effort to block all forms of tracking. I never gave consent to anyone to track anything I do, so why should I honor an agreement in which I did not participate? The "goodness" or "evil-ness" of their intentions doesn't even have to be a consideration. Sorry but referring to that as "paranoid" is either an attempt to demagogue it, or evidence that someone else's attempt to demagogue it was successful on you.

Are some people quite paranoia? Sure. Does that mean you should throw out all common sense, pretend like there are only paranoid reasons to disallow tracking, and ignore all reasonable concerns? No. Sure, someone who paints with a broad brush might notice that your actions (blocking trackers) superficially resemble some actions taken by paranoid people. Allowing that to affect your decison-making only empowers those who are superficial and quick to assume because you are kowtowing to them. This is what insecure people do. If the paranoid successfully tarnish the appearance of an otherwise reasonable action because we care too much about what others may think, it can only increase the damage caused by paranoia.

Re:How about telling Analytics to take a hike?

[rho]

I'd suggest disabling javascript and calling it a day.

FWIW, this is Slashdot. You can be pretty confident that a Slashdot user is aware of disabling Javascript, and of NoScript, and all the other obvious non-solutions. You can also be confident that if they haven't done so, there's a pretty good reason. In my case, the trouble it fixes is not as bad as the trouble it causes. Not a few Web sites do not work, or work poorly without Javascript. Sometimes it's even useful.

This has been a problem going all the way back to 1995 with a million nested tables and IMG tags with no width or height attributes. It's simply bad design and the bad habit of blindly following trends. People do that because good design is hard and expensive, and following trends is easier and cheaper than developing an individual marketing campaign.

Re:How about telling Analytics to take a hike?

[dotwhynot]

Remember when a 768kbps DSL line was whizzo fast?

Jeebus. I remember when my 1200 baud modem felt whizzo fast compared to my old 300 baud modem.

And, yes, I can already see the "get off of my lawn" posts below you, and I'm dating myself. :-P

Cheers

Cheers mate, I remember working on the 'magic' USR AT command sequence string to optimize the connection, and listen to the sound. Think there was an AT&K1 in there, plus a lot more. Wouldn't want to go back, as with good old PC days I think we are seriously romanticizing the speed we remember, but glad I was there.

Re:How about telling Analytics to take a hike?

[ejtttje]

I'm sorry, are we on your grass?

Re:How about telling Analytics to take a hike?

[Eil]

I want my old Internet back.

No problem. Here you go.

And a pony.

Done.

Re:How about telling Analytics to take a hike?

[commodore64_love]

>>>Remember when a 768kbps DSL line was whizzo fast?

I'm on a 768k connection you insensitive clod! And it IS whizzo fast, compared to my other 50k Dialup ISP

Re:How about telling Analytics to take a hike?

[commodore64_love]

300 baud == reading speed

1200 baud == skimming speed

2400 baud == fast enough to fill a screen in 1-2 seconds

9600 baud == seemingly instantaneous

That was back when all you needed was 1 byte to represent a single ASICC character, and therefore could load a full screen quickly. Nowadays it seems as if there are 1000 bytes per character and a screen takes 10-20 seconds to fully load a screen. Don't they teach optimisation anymore?

Re:How about telling Analytics to take a hike?

[BJ_Covert_Action]

A bit off topic but now I know why NoScript prevents Myspace form loading altogether...because I have analytics blocked and, looking at the HTML source code now, I can see why nothing else is loading afterwards...

And who says slashdot doesn't still have some useful/helpful comments on it?

Re:How about telling Analytics to take a hike?

[mattack2]

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.)

Re:How about telling Analytics to take a hike?

[thetoadwarrior]

That would be ok on a site with shitty ads but not all ads are shitty and to be honest, I rather support sites that are deserving of the support. I'd also like reputable companies to think they can get somewhere with web advertising so web adverts don't just become a breeding group for bottom feeders.

Re:How about telling Analytics to take a hike?

[vikstar]

Welcome to Web 2.0, where it takes a little longer to load a webpage, but you don't need to send HTTP requests every time you click something. Imagine reloading all the comments of a Slashdot article just to post a reply. You're like one of those people that complain about mobile phones to someone whom your talking to on a mobile phone.

Re:How about telling Analytics to take a hike?

[Actually, I do RTFA]

What's paranoid about insisting that a company bring a proposal, make me an offer, and sign a contract if they want to derive monetary value from my personal data?

Because the costs of doing so would outweigh the benefits, leading to no one agreeing to the use of their data, no ad revenue, and ultimately no professional web sites (except those that charge a fee to view). This situtation is termed a "market failure", in this case because of high transaction costs. Therefore, society standardizes the agreement to "they can use the info they get on you when you visit their page", and other people specialize in aggregating that info about you. This is similar to how Target can sell you something for a quarter and turn a profit, while even the most measily negotiated contract costs in the hundreds of dollars.

I personally block their tracking cookies, and have no moral objection to it, but you cannot reasonably assume all human interaction to be governed by explicit contracts.

Re:How about telling Analytics to take a hike?

[pjt33]

I put them in /etc/hosts as 127.0.0.2 and run a lightweight webserver bound to that address which simply returns 404s for everything. That way it's independent of the browser.

Re:How about telling Analytics to take a hike?

[kestasjk]

What's paranoid about insisting that a company bring a proposal, make me an offer, and sign a contract if they want to derive monetary value from my personal data?

It's not paranoid, just unworkable. Your info is stored on /.'s servers, most likely still used to "derive monetary value" by scaling up viewer figures for advertisers. You want /. to send you a contract to sign before you can comment?
If they wanted they could submit data directly to google analytics from their own logs, or track via an image (slashdot could export its static content to external servers to make prevent blocking external servers), because the net is public and they're collecting data you transmit with every request you make.

Every time you pay for something that isn't person to person the data will almost certainly be stored in one or more databases, and used to "derive monetary value", so do you buy all your goods in market places? Of course not, but why? They sure don't make you sign a contract to shop with them, what's the difference between that and browser data? I suspect the difference has a more to do with blocking ads than some real moral objection to mass data collection.
And based on the lack of a donor * I'm guessing you didn't apply your rules and go to OSDN with "a proposal for the exchanging of monetary values for contractual obligations regarding server usage", or however you want to put it.

Basically you don't want to see ads, so you blocked them along with analytics, but you want to see /. stories so you'll surrender your precious data without hesitation (let alone signed contract).
That's fine, but don't go trumpeting it around like you're on some crusade; you're blocking something that annoys you, and if everyone did they'd find a different way to achieve the same results (it's not hard to think up ways to perform tracking via images and serve ads integrated directly into the page HTML)

You can think up some distinction between this information and that information or this purpose vs that purpose, if feeling a twinge of guilt for blocking ads just won't get with your ego, but it's pretty transparent.

Re:How about telling Analytics to take a hike?

[amRadioHed]

Sure but the sites that don't work with javascript didn't exist on the old internet anyway. If you really want the internet circa 1994 experience you won't miss those pages.

Re:How about telling Analytics to take a hike?

[krelian]

Instead, they feel my data is free for the taking and this entitlement mentality is the main reason why I make an effort to block all forms of tracking.

What about your sense of entitlement to get their content under your conditions?

Re:How about telling Analytics to take a hike?

[Enleth]

And what's stopping you from replanting it there using DOM? After all, it's the DOM tree that matters in the end, not the textual representation of the HTML code, and every modern browser will cope with something being inserted into the layout very well.

Put the GoogleSomething in a display:none div at the end of the body, let it use document.write and other atrocities, root it out after it's finished and place it where it really belongs.

Re:How about telling Analytics to take a hike?

[Hurricane78]

You mean spaghetti "developers"? Real developers know the existence and function of the onload hook in the body tag.

But hey, I saw taxi drivers with a HTML 4 book, or ex drug sellers clicking on buttons in Dreamweaver or even Frontpage, who thought they were "web developers" back in the days.
And the worst part: The clueless managers (with the venture capital) believed them, because they were so sure of themselves, and is lack of competence that was their only indicator for who to hire.
*whispers* That was how Lycos Europe was born, by the way. And it was also their cause of death. */whispers*

Re:How about telling Analytics to take a hike?

[causality]

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.)

If they want to hold me to an obligation which entails consideration (the exchange of one thing of value for another thing of value) there is an existing mechanism for that: it's called a contract. Until and unless I consent to an agreement stating otherwise, my data is mine and they may not have it. In fact, I am particularly disinclined to give them what they falsely feel entitled to have. Meanwhile, if they choose to have a publically available, free-to-use service on an open network that anyone with a Web browser can freely reach and utilize at no charge, that service is also theirs to do with as they please. No one forced them to make it freely available; they willingly chose to do that. Thus, in the absence of any contract or other binding agreement, I have no obligation to guarantee the success of anyone's business model.

If this arrangement is not to their liking, they are free to deny me access to any sites they own. They are also free to innovate and come up with a way to require payments, acceptance of advertising, or participation in data-mining as a condition of using their site. In the absence of such requirements, anyone who tries to make me feel obligated is either manipulative or misguided. It could be manipulative because they want to use emotional appeals designed to make me feel bad about using for free what is offered for free. It could also be misguided because such people don't understand that the Internet is a open, public network; the reason you put a Web server on a public network with no access controls (such as passwords or paywalls) is because you want the public to use it.

There was an Internet before there was any advertising-funded content. If that business model fails, there will be an Internet after it, too. Besides, companies like Google are more than shrewd enough to realize that for every person like me who will take whatever steps are necessary to safeguard his privacy, there are thousands of users who don't even know what trackers are. This can be regarded as one definition of their business model, though certainly not an exhaustive one.

Re:How about telling Analytics to take a hike?

[PReDiToR]

I thought that was called consumer choice?

Too many corporations/monopolies buying laws take it away from us these days.

Re:How about telling Analytics to take a hike?

[causality]

It's not paranoid, just unworkable. Your info is stored on /.'s servers, most likely still used to "derive monetary value" by scaling up viewer figures for advertisers. You want /. to send you a contract to sign before you can comment?

What info is that? The disposable e-mail address with which I created the account? My username of "causality"? My password that is unique to this site and is not used anyplace else? My IP address which is really public information anyway, and does not uniquely identify me because I am on a shared connection with a NAT router? My HTTP referrer that always returns the site's own homepage no matter what the actual referrer would have been? I could try to exhaustively list everything but I think you get the picture.

And, you misunderstood me. A contract would be Slashdot's way to obligate me to provide them with accurate information. Additionally, Slashdot itself doesn't try to track my browsing habits. Sure, they log what I do on their own sites, but you won't find a 1x1 pixel Web bug (or anything like it) from Slashdot on somerandompage.com because Slashdot is not in that business. Comparing Slashdot to the advertising companies employing proactive tracking measures (that were obviously the subject of my post) is less than intellectually honest.

I suspect the difference has a more to do with blocking ads than some real moral objection to mass data collection.

I for one would block ads whether or not an attempt is made to collect my data. They are two separate issues. As I have already stated, my objection to mass data collection is that it occurs without my consent. I am a big believer in the virtues of informed consent. After all, if it is such a legitimate business practice, then informed consent should not be a problem. If it is a shady business practice, then maybe they wouldn't want to call attention to it.

Basically you don't want to see ads, so you blocked them along with analytics, but you want to see /. stories so you'll surrender your precious data without hesitation (let alone signed contract).

Your suggestion (an assumption really) that I am a hypocrite rests on your belief that I am making a special exception for Slashdot because I enjoy Slashdot's content. I do enjoy Slashdot's content. However, I have made no exceptions and the first paragraph of this post explains that for you. Slashdot has none of my private data. If accurate private data became a requirement for using this site, I would find another site.

That's fine, but don't go trumpeting it around like you're on some crusade

What crusade? I do what I do not as a product of random chance, but because I have my reasons. I have stated some of those reasons because it came up in the conversation. Your line there can be reworded thusly: "censor any beliefs you have that I dislike, or I will overreact to them by calling it a crusade and pretending like mentioning something germane to the conversation is the same as 'trumpeting' it". I don't think you are deliberately intending that (though some will knowingly do this because it works so well on most people). I point it out because I don't think you realize it or actually understand the message you are sending.

I'll be blunt here. I am not some pushover who will either censor himself or alter his beliefs in order to please you and you can either respect the integrity of that or you can hate me for it -- your choice. Because of that, you'll just have to get over the fact that I might do things you don't like or don't agree with. If you can't handle that without making a mountain of a molehill or making assumptions about my beliefs, this is your problem. It is yours to either overcome or further succumb to. I won't legitimize it by acquiescing to it and my involvement in it ends there.

Re:How about telling Analytics to take a hike?

[kestasjk]

You consider the data analytics and adverts track to be "personal data", but when /. (and RL stores, banks, CCTV, etc, etc) log equally or more personal data (or identical datasets) you have no problem with it.
This implies your reason for blocking certain content isn't about protecting your user data.

It's a plain double-standard, whether I'm insecure or magicians have me under their spell doesn't really come into it.

Re:How about telling Analytics to take a hike?

[causality]

You consider the data analytics and adverts track to be "personal data", but when /. (and RL stores, banks, CCTV, etc, etc) log equally or more personal data (or identical datasets) you have no problem with it. This implies your reason for blocking certain content isn't about protecting your user data. It's a plain double-standard, whether I'm insecure or magicians have me under their spell doesn't really come into it.

Slashdot logs data on its own slashdot.org site. Google and others log not only on their own sites, but also on many others. Either you are being deliberately dense or you really cannot seem to grasp the concept that Slashdot's methods cannot be used to build useful profiles on me while Google's methods can do that. Slashdot is not actively trying to track my behaviors while Google is. So Slashdot gets a very minimal set of data (otherwise I could not use the site) while Google is routinely blocked. See the difference?

To give an analogy, Slashdot is like me walking into a store. The store's owner can see that I am there and can see what I am doing, but I can see him too. When I walk out of his store, he leaves me alone. You see, this isn't tracking.

Google is like me walking into a store. The store's owner can see that I am there and can see what I am doing, but I can see him too. When I walk out of his store, he tries to follow me and this time he tries not to be noticable. He writes down the names of every other store I go to so he can sell me similar items later. You see, that is tracking. I will take measures to block this guy that would not be necessary to use on Slashdot. Why? Oh yeah, because they're two different situations so I handle them in two different ways. Yes, I know, it's the ultimate in hypocrisy and double-standards isn't it? It may even club baby seals to death.

Bottom line, my data is mine to do with as I please. The more intrusively someone tries to obtain it, the more willing I am to take steps to prevent them from doing so.

And yeah, you're insecure. Your car is yours to do with as you please, and for that reason, I wouldn't put your driving habits under a microscope and look for inconsistencies and double-standards. That's because I have no need to portray you any particular way. My data is mine to do with as I please also. Yet for some reason you want to tell me there is anything wrong with feeling that way about it. The "double-standard" you point out doesn't exist: Slashdot is not an intrusive Web site so there's little reason for me to treat it like one.

Again, if you don't like what I do with my private data, feel free to set a better example by using yours in a way that you think is appropriate. If you do, that's your business. It's not my place to tell you what you should do with what is rightfully yours, and in fact, everything I have said on this subject is my personal opinion. I'm not shocked or challenged when your personal opinion is different. I don't view that as a problem I need to correct. That's why I don't understand your need to win a convert. It's just not going to happen, so get over it. Incidentally, the imaginary double-standards do not make you any more convincing.

Re:How about telling Analytics to take a hike?

[kbielefe]

There is a contract. It's called the terms of service. By using the site you agree to that contract. The content is protected by copyright and nothing else gives you the right to download a copy for viewing on your computer. This is well-established law. You may not like the law. You may not like the contract. You may not agree with the means of entering into it. The contract may be very loosely enforced. That doesn't change your legal obligation. If you don't like it, you are perfectly within your rights to dispatch a lawyer to negotiate an individual terms of service contract that is more to your liking. You have a good chance of succeeding too, but not at the same price you're getting now. If you really believed your argument, and weren't just trying to justify your behavior, you would do just that.

Re:How about telling Analytics to take a hike?

[umdenken]

I realized a little while ago that only techies like us pay attention to the "completed X of Y items...", and get aggravated over the unfinished state of the web page. As long as the page appears to be finished loading, then it *is* finished loading as far 95% of people are concerned. And this isn't so bad - it means the extra time to load analytics doesn't really matter.

Re:How about telling Analytics to take a hike?

[martin-boundary]

There is a contract. It's called the terms of service. By using the site you agree to that contract.

I don't think it's that simple. A contract has to be enforceable in a court of law, or it's just a worthless piece of paper. Now, if some web surfer in Tibet reads slashdot, there is no court anywhere that can enforce the terms of service of slashdot. The web surfer is probably anonymous anyway, but certainly the courts in Tibet won't enforce these terms, and a court in the US physically can't.

The only actual terms of service that the surfer in Tibet has entered into are with his local ISP, who have no connection with slashdot. Instead, the local ISP has a contract with another ISP, etc moving up the chain and back down again until you reach the owners of slashdot.org. The fact that the web surfer in Tibet can read the site is merely a side-effect which is not covered by any jurisdiction.

Re:How about telling Analytics to take a hike?

[kestasjk]

See the difference?

OSDN makes money via advertising and have every reason to track what software you download from sourceforge.net and check out on freshmeat.net, what stories you read on slashdot.org to try and profile you to provide better targeted ads.

Your purchases in any major store are stored in a database in your bank and (depending on the store) in the store's databases to build data determining trends and what products people who fit certain profiles are likely to buy.

All this data could be used to profile you, just like the Google Analytics data, yet you seem to be concerned only with Google Analytics and ad tracking. That is a double-standard.


Re: "yes you are insecure because cars, and I'm not convinced, and I won't agree no matter what you say so I'm right so there." I'm not getting drawn into personal attacks, stick to the subject.

Solving the wrong problem

[Animats]

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.

Re:Solving the wrong problem

[HBI]

IAWTP. With NoScript on and off, the web is a totally different place.

Re:Solving the wrong problem

[Anonymous Coward]

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.)

I definitely agree on this one (who wouldn't). I'd say they clearly improve the look and feel of websites, but the simple addition of making them separate files requires a separation GET, which is far slower than consolidating. Also, a lot of sites do not compress these files (both in-transit, and simply removing whitespace from their web server versions--it's fine to keep it for your personal modification, but a compression tool should always be used on those scripts/files before putting them out for the rest of the internet to download. It has a dramatic affect on speed.

Re:Solving the wrong problem

[BlueBoxSW.com]

So if Google sped up the non-ad web, they would have more room for their ads?

SNEAKY!!

Re:Solving the wrong problem

[Monkeedude1212]

I think you mean SNKY

Re:Solving the wrong problem

[rho]

With NoScript on and off, the web is a totally different place

Yes. Quite often completely non-functional, because the site requires Javascript to do anything.

Usually this is followed by an assertion that the site's developer is a clueless knob--which may be true, but doesn't help at all. This is the Web we deserve, I suppose: 6 megabit cable connections and dual-core 2.5 gigahertz processors that can't render a forum page for Pokemon addicts in under 8 seconds.

Re:Solving the wrong problem

[Yoozer]

Remember how CSS was supposed to make web pages shorter and faster to load? NOT.)

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:Solving the wrong problem

[mea37]

So... when you try to load slashdot, the requests that fetch the content don't get rolling until the request that fetches the ad finishes... and SPDY allows all of the requests to be processed concurrently so the content doesn't have to wait for the ad...

How is that solving the wrong problem again?

Re:Solving the wrong problem

[Cyner]

Don't forget the servers that are overloaded, or have poorly written code. An easy can, check out HP's bloated website. Each page has relatively little content compared to the load times. It's all in the backend processing, which must be massive seeing as how it takes 1/2 to several seconds for the server to process requests for even simple pages.

As the OP said, they're solving the wrong problem. It's not a transport issue, it's design issues. And many websites are rife with horrible design.

Re:Solving the wrong problem

[shentino]

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.

Re:Solving the wrong problem

[shentino]

How is the separate GET slower?

If it's being properly cached then it shouldn't ask the server about it AT ALL, assuming of course that proper cacheability directives have been placed on the response.

Re:Solving the wrong problem

[Idbar]

I agree with you, most of the times they address the wrong problems because they want to avoid being blamed. Doing research on TCP congestion control mechanisms, realized that ISPs pushed all the problems towards the borders over dimensioning networks. Now core network traffic remains low, while home routers can't handle traffic and drop the packets due to ridiculous access speeds.

Besides, I want to be able to take advantage of the Internet without requiring 2+ cores and battery draining GHz of speed.

Re:Solving the wrong problem

[amicusNYCL]

How is the separate GET slower?

For the same reason that it's a lot faster to transfer one 100MB file over FTP than it is to transfer 10,000 10KB files: the overhead in setting up the connection and transfer.

Re:Solving the wrong problem

[DaveV1.0]

Actually, what he said was

advertising code that blocks page display until the ad loads.

Which is means that even though the desired page may have already been retrieved, the page content will not display until the ads have been downloaded. If the ad server is slow, then the page will load slow, even using SPDY.

Re:Solving the wrong problem

[mujadaddy]

With NoScript on and off, the web is a totally different place

Yes. Quite often completely non-functional, because the site requires Javascript to do anything.

For varying definitions of "anything", including "some bullshit hypersaturated ad-analytics hell video link that you don't need to watch anyway."

If I can't see something within 2-3 temporary permissions grants, I didn't need to see it anyway. <3 NoScript. Well, more properly, I love having a Javascript whitelist.

Re:Solving the wrong problem

[MaliciousSmurf]

... His point was that the CSS file is downloaded once, and then works for all pages on that site. It's faster to download one 100KB file than 100 files of 100KB. That's why CSS is a good thing. Duh.

Re:Solving the wrong problem

[h4rm0ny]

In fact, thanks to slashdot's no-edits-allowed policy, each comment itself is a static unchangeable snippet of text. Why not cache those?

Ooh! Nice idea! Mod up +5 Editors Read This.

Re:Solving the wrong problem

[jimicus]

How is the separate GET slower?

If it's being properly cached then it shouldn't ask the server about it AT ALL, assuming of course that proper cacheability directives have been placed on the response.

Go set up a caching proxy sometime, turn the logging up to max and take a look at what you get.

You would be AMAZED how many things these days cross the Internet with Pragma: No-Cache and HTTP/1.1 cache control headers.

Obviously if you're writing the app yourself you can make it cache-friendly and stick a reverse caching proxy in front of it, which helps everyone. But this doesn't help the lone admin trying to stretch available bandwidth as far as is humanly possible within his organisation.

Re:Solving the wrong problem

[h4rm0ny]

Actually, maybe it isn't a nice idea. How could you accomplish this without creating something that was forced to make hundreds or even a thousand little separate requests the first time you loaded a popular story, instead of one, admittedly large, HTML page?

Re:Solving the wrong problem

[Temporal]

Loading the base page just isn't the problem.

Did you actually read the article? SPDY seems to be *all about* loading multiple resources. It looks like SPDY reduces the number of round trips required by allowing the server to push files to the client which it knows the client will need, and allows transfers to be multiplexed rather than forcing everything into a FIFO pipeline as HTTP does. And the prioritization features presumably allow the client to get the resources required to start rendering the page (like the CSS) before things that can be filled in later (images).

Re:Solving the wrong problem

[AP31R0N]

Is my flash and javascript blocker making pages faster for me then? If i go to a busy site and have all those ad sites blocked... is my browser still pulling all that crap? Or is it ignoring it, making the page proper load faster?

Re:Solving the wrong problem

[thetoadwarrior]

That's because anyone can put up a web page. Anyone with any serious intention of doing things write won't let their page be hindered by CSS and it's dead easy to shove a good portion of your Javascript to the bottom of the page to be executed last. This is good for numerous reasons but most importantly because any slow third party JS won't stop the user from using the page.

Re:Solving the wrong problem

[OzRoy]

It seems that people have been making very similar arguments to this about all aspects of computing for decades. Until recently it was always with the amount of memory or CPU speed.

Basically it's summarised as "Why should we make X run Y faster when we can just optimise Y?"

It's just a ridiculous argument. Obviously you should always try and optimise the software, but why shouldn't everything else run faster as well?

Re:Solving the wrong problem

[Pulzar]

So how do you explain, then, that the top 300 sites loaded in half the time on average? It certainly seems like it's solving one of the major problems. There are others, no doubt, but this is by no means a "wrong" one to solve.

Re:Solving the wrong problem

[nilbog]

So how do you explain the 200% improvement in download speeds on all the sites they tested? I agree that there are lots of different bottlenecks you can focus on, but you can't argue with results.

Re:Solving the wrong problem

[ProfessionalCookie]

I always wished you could define aliases directly in CSS:

@define
(
themecolor1,'#f6a889';
themecolor2,'#00ff40';
themecolor3,'rgb(165,42,42)';
boxshadow1,'1px 2px 4px #c6c6c6';
)

.sidebox
{
box-shadow:box-shadow1;
color:themecolor1;
}

Otherwise you end up greping through css when you want to change/reuse something. CSS was a step in the right direction but there's plenty to do :)

Re:Solving the wrong problem

[ProfessionalCookie]

Or even being able to assign classes to other classes:

.main-font{font-family:Times, serif}
.headline {class:'main-font';color:green}

#news {class:'main-font';}
#side-header {class:'headline'}

That would be super hand most days

Re:Solving the wrong problem

[shentino]

you could always pipeline the requests.

Re:Solving the wrong problem

[Allicorn]

Remember how CSS was supposed to make web pages shorter and faster to load? NOT

Build a page that looks the same as a heavily CSS'd page but uses only presentational HTML tags and attributes to achieve the effect.

Now make a second page for the same site with different text on it. And a third. And a fourth...

There's your "CSS makes web-pages shorter and faster" right there.

Re:Solving the wrong problem

[Razalhague]

.headline,
#news,
#side-header {font-family:Times, serif}

.headline,
#side-header {color:green}

Re:Solving the wrong problem

[ProfessionalCookie]

Yeah I know that. The issue is that you can either associate a long list of selectors with a property or a selector with long list of properties.

If you're designing a page it fastest and easiest to write CSS using the latter strategy.

Unfortunately it also means you have to play grepcakes when you decide to change change a single color.

A capability like {class:'main-font';} means you can reuse long property lists and stick with a design strategy that makes the most sense.

Re:Solving the wrong problem

[Razalhague]

I don't think you realize how similar what I showed you and what you want are. The difference is that the way you want it you need to name the parent at the definition of the child, whereas the way I showed it you need to name the child at the definition of the parent (and their parents). It's just inverted. Your way is better only if you want to build huge inheritance trees.

Re:Solving the wrong problem

[badkarmadayaccount]

Oh, where art thou, Javascript Style Sheets?

Re:Solving the wrong problem

[ProfessionalCookie]

haha- yes I'd also like to be able to do simple math in plain old CSS but for some reason width:calc(body.width-40px) just doesn't work :/

Re:Solving the wrong problem

[badkarmadayaccount]

I was thinking of the prototype based object model, but now that you mention it, that seems an issue as well.

Cloud gaming

[should_be_linear]

Everything plays together nicely for "cloud-gaming" statrups. This will solve, at least to some extent, one of their hardest problems, for free. Except if Google itself is not after exect same market. They never mentioned how Chrome OS is supposed to provide gaiming to users ...

Re:Cloud gaming

[fuzzyfuzzyfungus]

Google has never explicitly mentioned it(at least to my knowledge); but I don't think that it is rocket surgery to infer the likely possibilities.

For basic casual flash stuff, there will almost certainly be flash support(since Adobe seems to at least be promising to get off their ass about reasonably supporting non wintel platforms). In the longer term, Google's work on making javascript really fast will, when combined with SVG or WebGL, allow flash level games to be produced with stock web technologies.

For native binary stuff, Google's quiet-but-interesting NaCL project seems like a likely candidate, most probably using ordinary web technologies and the Chrome browser as the desktop UI; but with cached NaCL lumps for applications that can't be done any other way. One might also expect to see Courgette used to efficiently update those cached NaCL components.

For games beyond the capability of the hardware that ChromeOS will typically be running one(since it seems to be aimed at the weak-'n-cheap end of the market) I'd assume that one of two things will happen: If the various "game streaming" offerings that are sprouting up turn out to actually work reasonably well, one or more will probably end up being available for ChromeOS(either purchased and integrated, or because ChromeOS supports third party NaCL objects). If they end up being laggy crap, Google will probably just ignore the problem, reasoning that everybody's slow and cheap hardware suffers from the same fundamental limitations in that area, and so the lack of more sophisticated games isn't a huge issue

Re:Cloud gaming

[ickleberry]

anyone who uses HTTP as the protocol for a game server should be shot. UDP is where its at man

Application Layer...

[Monkeedude1212]

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.

Re:Application Layer...

[coolsnowmen]

A plugin gets it into something like firefox. Then, as long as there is a way for a webserver like apache to allow both requests (http or spdy), it shouldn't be that hard because you arn't storing your web pages in (static or dynamic) in a different format so it shouldn't be that much work to add the [apache] module once it is written.

Re:Application Layer...

[grmoc]

Yes, it means that both sides have to speak the protocol.
That is why we want to engage the community to start to look at this work!

Re:Akamai?

[epiphani]

Eh, not at all. Akamai is a distribution/anycast provider. They're about the infrastructure to support large-scale websites and/or content providers with very high SLA targets, not speed up individual requests.

All the parentheses in the summary...

[Ironchew]

Am I the only one imagining a ventriloquist controlling a snarky dummy that counters all the points in the summary with dubious half-truths?

Re:All the parentheses in the summary...

[grmoc]

Yea, sorry about that-- I tend to represent my thoughts with lots of parenthesis. :)

Re:All the parentheses in the summary...

[dzfoo]

Then, may I suggest you first think about what you want to say, organize your thoughts a bit, and then write them down. It makes for more efficient and effective communication. In time and with practice, thoughts will start flowing in a more organized way.

Like any other grammatical tool, parentheses have their place, of course, but they are very easily abused in ways that confuse the ultimate meaning the writer intended to convey.

        -dZ.

Re:Akamai?

[TooMuchToDo]

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.

Is he your biological uncle?

[spun]

Or simply an older man who likes to fondle you?

Re:Is he your biological uncle?

[brainboyz]

What's scary is that you got a 404 and not a NXDOMAIN.

Re:Is he your biological uncle?

[commodore64_love]

Here you go. The Dirty Old Man's Association - http://www.domai.com/ (warning nudity)

Re:Is he your biological uncle?

[Sparky McGruff]

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!

Re:Is he your biological uncle?

[hrimhari]

(warning nudity)

Thanks for the warning : ) I'm always happy to see people open to suggestions.

Cool.... but it's not http

[Colin Smith]

So which ports are you planning to use for it?

 

Re:Cool.... but it's not http

[TorKlingberg]

Everything uses port 80 these days. Thank NAT for that.

Re:Cool.... but it's not http

[Craig Davison]

Probably 443. In the article, it says they're building this on top of SSL to maintain compatibility with existing proxy servers.

I don't think it mentioned how a client will indicate they're going to speak SPDY instead of HTTP. Probably have to read the code or spec for that.

Re:Cool.... but it's not http

[grmoc]

Right now the plan is to use port 443. We may as well make the web a safer place while we make it faster.
The plans for indicating how a client/server speaks SPDY is still somewhat up in the air.. .. what we have planned right now, is:
UPGRADE (ye olde HTTP UPGRADE).
and, putting some string into the SSL handshake that allows both sides to advertise which protocols they speak. If both speak SPDY, then it can be used.
This is nice because you don't have the additional latency of an additional roundtrip (and that latency can be large!)

Re:Cool.... but it's not http

[GuyFawkes]

Please DO NOT usurp port 443 for you own ends.

Your "method" involves breaking https handshaking, and I don't care what definition you use, any method that involves extra protocol handshaking that my port 443 application does not recognise is both delaying it and breaking it.

What you are doing is not HTTP, it is not HTTPS either.

Please bugger off to some other Port, maybe 61482

Re:Cool.... but it's not http

[michaelhood]

Are you concerned about the additional overhead related to setting up https connections partially or entirely negating the performance benefits of SPDY in many environments?

Re:Cool.... but it's not http

[grmoc]

I work with some of the OpenSSL maintainers, and we've figured out a way of advertising protocol support (whether it be SPDY, YGNDMA, WHTSTHISNEWPROTO, whatever :) ).

During the SSL handshake, a string is sent which includes the protocols that the server/client would like to advertise. This is *during* the handshake, not after it. It isn't a large amount of data, and thus you don't incur an extra RTT or any other latency penalty. SSL implementations which don't expose this field would just ignore it.

If after the handshake, a side that supports SPDY (or whatever), sees that the other side also supports it, then it can use that protocol instead of HTTP over SSL.

So, what we're proposing is 100% compatible with the way things work today-- it shouldn't break anything at all. If it isn't true, then we simply wouldn't do it that way.
Using another port isn't a good idea, incidentally. In addition to the fact that many personal NAT/firewall/routers will filter out strange new ports, and given that asking everyone to upgrade either the settings or the hardware is essentially impossible... we're stuck.
Even if we're successful at using a new port (imagine that the rest of the problems go away), there is still the problem that we have to continue to support HTTP/HTTPS indefinitely. Many sites will continue to exist only with HTTP/HTTPS. For those sites, attempting a new connection on a different port may not be great. You can use some interesting heuristic, but you'll always get into a race, even if the site supports all the protocols..

Re:Cool.... but it's not http

[grmoc]

Nope-- we've seen 65% latency reduction without SSL, and 55% with. In other words, SSL doesn't hurt us that much. For HTTPS, it is much worse, since you have to make more connections and deal with setting up the connection that many more times.

Not a terribly new concept.

[ranson]

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.

Re:Not a terribly new concept.

[grmoc]

That definitely sounds interesting... I'd love to speak to people about that!

Re:Not a terribly new concept.

[Hurricane78]

Uuum, not to brag, but I did this in 2003/2004. With pure javascript/DOM. I had a "network card" that i could use to do the same things that I would have been able to do in a tunneled virtual network card. of course it did not have the useless low-level stuff, but only what was needed on an application level. But it had complete object serialization, compression and update "packet" objects sent trough the pipe (resulting in pretty good deltas), encryption (oh hell yeah!) and server session management.

I used it to pipe a networked file system trough it, so I could safely manage files on the server just like with a windows share. It worked pretty well.
The file system was of course modularized, so that I could "mount" a cookie as a drive, and store data in there. :)

Man I miss those days... With switching to games, I fell way too far behind.

Re:Not a terribly new concept.

[bill_mcgonigle]

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:Not a terribly new concept.

[Arthur Grumbine]

With all due respect for the technical accomplishment, by admitting your pride in working for AOL you've revealed your true identity... could it be... hmmm...SATAN?

Comment removed

[account_deleted]

Comment removed based on user account deletion

Yeah, right... but WHY?!?

[51M02]

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:Yeah, right... but WHY?!?

[shentino]

Reinventing the wheel is just fine if the first wheel isn't actually round enough...or has proprietary axle interfaces such that only one kind of wagon can be put on them.

Re:Yeah, right... but WHY?!?

[layer3switch]

I think, Google's motivation is in self interest, not end user's interest. Reducing load and time to serve will benefit content providers, not end users. However it's bit odd and immature for Google to fix something that is NOT broken. Or maybe I'm too old to think like people at Google...

Re:Yeah, right... but WHY?!?

[fuzzyfuzzyfungus]

I strongly suspect that whether or not HTTP is "broken" is largely a matter of perspective. For classic website serving, HTTP works pretty well. Not perfectly; but easily well enough that it isn't worth replacing.

If, though, your business model largely depends on creating webapp UIs that are good enough to compete with native local UIs, HTTP's latency and other issues are going to strike you as a fairly serious problem(particularly if the future is very likely going to involve a lot more clients connecting wirelessly via cell networks, where latency is already utter shit). Since that is pretty much exactly Google's situation, their motive seems pretty clear.

As for the "odd and immature" bit, if they had tried to roll this out as some sort of Web2.0 version of the old walled garden protocol setups(like the old "Microsoft network", before MSN became a normal ISP), then that would have been very odd and very immature. As it is, though, they've rolled out a potentially interesting project that fixes some problems that bug them under a liberal OSS licence. That seems like a fairly reasonable and inoffensive activity.

Re:Yeah, right... but WHY?!?

[grmoc]

Hopefully this shouldn't be proprietary at all.. We're open sourcing it, after all!

Re:Yeah, right... but WHY?!?

[grmoc]

We had a different name before. Alas, many of the better names are already taken...

Re:Yeah, right... but WHY?!?

[Bill, Shooter of Bul]

Learned from Go's mistake, did we?

Me, I woulda suggested FLAPJACK. (FJ://). Cause, after all, who doesn't like flap jacks? If the internet could deliver them to me, this would be a better world.

Re:Yeah, right... but WHY?!?

[zevans]

Coeliacs don't like flapjacks, you insensitive clod!

Re:Yeah, right... but WHY?!?

[Bill, Shooter of Bul]

They can use the BFJ:// protocol : Buckwheat Flap Jack, It isn't as good, but you tell everyone you prefer it anyways. Relatives will send you BFJ packets while they send FJ's to themselves to make you feel included.

But can't you see how SPeeDY will solve ALL these?

[Colin Smith]

?

No. Neither can I. It will let them *push* adverts at you in parallel though... *before you asked for them*

Google wanting more efficient advert distribution... No, never...

 

slashdot

[jDeepbeep]

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.

Re:slashdot

[commodore64_love]

Try the K-Meleon browser. Your moth will drop.

Your mouth will probably drop too.

Re:slashdot

[jackchance]

Try the K-Meleon browser.

i use mac and linux you insensitive clod!

Re:slashdot

[commodore64_love]

Try the Galeon, Epiphany, or Camino browsers - your mouth will drop at their speed

While we're at it ...

[RAMMS EIN]

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.

Re:While we're at it ...

[MichaelSmith]

Well probably the ultimate way forward was the hotjava browser, which was just the JDK applet viewer running an applet which could display a web page, with the capability to load new classes to display other content. Unfortunately this idea is more microsofts wet dream than suns wet dream and nobody wants to trust microsoft to that extent.

Simple, kludgy ascii based protocols help to keep the web open.

Re:While we're at it ...

[31415926535897]

There are many of these components in Flex, but the downside is you have to compile to flash...

Re:While we're at it ...

[element-o.p.]

Because push technologies have an inherent problem with abuse (can you say "spam"?).

Re:While we're at it ...

[rabtech]

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:While we're at it ...

[RAMMS EIN]

Your post illustrates pretty much exactly the frustrations that have led me to my ideas.

``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.''

Right. But humans who can see your shiny, flashy presentation are not the only ones who will be analyzing the information. There are also those who must do without visual cues, such as search engines, visually impaired people, people on text-only systems. You may not care about those, but it's sure nice to have your page well represented in search engines, at least. Hence my suggestion for a good language for expressing semantics.

``I know I shouldn't use tables for presentation but I just don't care.''

And, in fact, you shouldn't. The only reason some people want you to care about that is that they think table is semantic, whereas you would be using it just for presentation. The truth is that tables _are_ presentation, and it should be perfectly fine to use them for that. Hence my suggestion for a good language for expressing presentation.

``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.''

Hence my suggestion for re-usable libraries.

``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.''

The way I see it, the problem is mostly:

1. The people on the standards committees don't come up with the tools we need to make what we really want to make

2. The people who do come up with such tools make them proprietary and/or poorly integrated with the Web

3. Meanwhile, we have kludges that are Good Enough for a lot of people, reducing the incentive to come up with a real solution

Re:While we're at it ...

[twostix]

You just re-invented flash...

Re:While we're at it ...

[Hurricane78]

Uuum, what do you think the WhatWG, and the W3C work on, with (X)HTML 5 and CSS3? :)

But what are you going to do, when the killer argument "that's too hard for our most totally retarded end of the target group" is thrown at you?

We could have this already, if not for those people who think XHTML is "too hard". I mean WTF? Maybe for those wannabe ex-cab-driver "developers". I wish I could force them to learn Haskell until their head explodes. ^^

Re:While we're at it ...

[Larry_The_Canary]

I stopped reading as soon as you said that you used table layouts, here's why:

Solution 1:
<table>
      <tr><td colspan="2"><table id="header">...</table></td></tr>
      <tr><td><table id="menu">...</table></td><td><table id="content">...</table></td><td>..... OK I'm so f*cking annoyed already just making this example that I can guarantee that you're annoyed reading it!

Solution 2:
<div id="header"> ... </div>
<div id="menu"> ... </div>
<div id="content"> ... </div>
<div id="footer"> ... </div>

Not only is it painfully obvious that the non-table solution is easier to create, read and understand but it is also reusable since a different look can be applied to it by just changing a style sheet.

So please, take another shot at justifying table layouts. (HINT: Being too lazy to learn and understand the box model is not a good reason)

Re:Akamai?

[ranson]

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.

Don't be evil. Be swift and speedy.

[PDX]

Then the customers will empty their wallets twice as fast!

SPDY is technically nonsensical

[Anonymous Coward]

"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.

Cell phones

[nexxuz]

This sound like it would be perfect for cell phone browsers.

OT Re:Not a terribly new concept.

[netsharc]

Congrats on being the only interesting post so far. Everybody else is just complaining about the bloat in sites nowadays, which is valid, but I guess unavoidable. I just realize some sites might have 200+ inline elements, and the combined HTTP headers (plus TCP, etc overhead) on that isn't trivial, so this technology will surely help. Oh well, that's IT isn't it, Intel builds faster CPUs, and Microsoft builds bloatier software. I installed "Windows Live Mail" and "Windows Live Messenger" for a friend yesterday, and these 2 pieces of software (mail, and chat) takes up 100 MB. 100 MB!

A novel idea

[DaveV1.0]

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.

Re:A novel idea

[jimicus]

The words "door", "horse", "stable" and "bolted" spring to mind there.

Re:A novel idea

[deek]

You, sir, would never make a good hacker.

Re:A novel idea

[jeffstar]

I think the reason that HTTP/HTML has become so popular for anything not graphics intensive (like image, video editing, cad, etc) is that nobody wants to support users on microsoft windows. there is too much other shit that can go wrong that you end up picking up the phone for. Whereas if your app is web based, they try another computer and realize their one is borked.

Re:A novel idea

[DaveV1.0]

No, the reason that HTTP/HTML has become so popular is that companies and developers are cheap, lazy, and stupid.

Oh, and nice anti-MS troll, however MS has nothing to do with it.

Re:A novel idea

[DaveV1.0]

I am a decent hacker. But, a kludge is never good programming and hacking is rarely good programming and usually shitty design and implementation.

Being a hacker is one thing. Being a good programmer is another. That is the reason why software "engineering" isn't actually engineering.

Re:A novel idea

[snadrus]

Go on, what's the right tool for millions of people around the world on at-least 5 incompatible platforms to interact with near-realtime performance in ways I select using whatever interface & paradigm my next site will offer?

If your answer is: 5 separate programs, each installed differently across different platforms, each inevitably having their own learning curve that doesn't benefit those migrating to a different platform, then pass.

Companies don't want to spend that much hassle on IT when they know that standards save time. There's no more prevalent standard for visual interaction.

Re:A novel idea

[DaveV1.0]

How about a protocol stack designed for near real-time application performance instead of a protocol designed for transferring text, specifically marked up text with links? How about a protocol that uses packed binary data instead of ASCII text or UniCode, after all the data being sent and received by the application will never have to be written or read by a human as an HTML document might?

One does not need "5 separate programs, each installed differently across different platforms, each inevitably having their own learning curve". How about one program written to use an appropriate protocol that is compiled to run on each of those different platforms? You know, kind of like TCP.

By the way, please list all of those "5 incompatible platforms"?

Re:A novel idea

[snadrus]

Win, Lin (Gnome/KDE), Mac, Android, & Symbian. Ignoring iPhone, Pre, BSD & the future (Chrome OS?).

Better standards are the future, but binary has endian-ness and a spec & tags for everything. That only avoids the overhead of compressing html text which compresses very well and decompresses very easily (and in parallel). ODF is GZip(XML) (not inherently binary), yet already sees some of the problems with a format no-one writes directly, so it looks different in the 3-4 editors (Symphony, OOo, KOffice, MS).

I think standards should stay text(-able) & optimized for the slowest piece: the programmer. Meaning:
- Fast turing languages with included libraries.
- Higher-level primitives (like what UI has had for years) that have predictable looks
- An improved automatic layout (one of the things that made HTML great, then stagnated when people treat the web as print)
- Not too wordy (like b, i, and u tags)
- Optionally Distributable/reusable/overwritable (like CSS) to a greater degree that includes content.
-Departure from location to "app" per site with assumptions designed for interactivity.

Re:A novel idea

[deek]

I can appreciate what you say, but there's a certain beauty about a _good_ hack. It can be an amazing thing, a beautiful thing, to make something work the way it wasn't intended.

Re:A novel idea

[DaveV1.0]

ODF is GZip(XML) (not inherently binary), yet already sees some of the problems with a format no-one writes directly, so it looks different in the 3-4 editors (Symphony, OOo, KOffice, MS).

This is not a problem with the ODF having a binary component. It is a problem with the standard not being implemented properly and possibly the standard not being specific enough as to how to handle parts.

standards should stay text(-able) & optimized for the slowest piece: the programmer.

Use the right tool for the right job. If there is no reason for a standard to be "text(-able)" then it should not be "text(-able)".

An improved automatic layout (one of the things that made HTML great, then stagnated when people treat the web as print)

You make my point for me. People are not using the right tool for the right job.

Departure from location to "app" per site with assumptions designed for interactivity

As HTTP is connectionless, it is not designed for true interactivity.

Everyone see HTTP/HTML/XML as this wonder tool that can be used for anything and everything. But, it is not appropriate for many of the tasks it is being used for. One would not use a Swiss army knife to cut a 2x4 in half even if the knife has a saw. The appropriate tool is a cross-cut saw. One should not use a volt meter to try to measure current, even if one can rig it to do so. The fact that one can use a tool for some job doesn't mean one should use that tool for that job.

Re:A novel idea

[DaveV1.0]

Yeah, I know. But, I am living the results of not replacing a hack with a well-designed implementation.

I created a script to do a job for a single client. It was a hack to fill a hole. The script was supposed to be replaced by an engineered solution. But, the hack worked so well, that the engineered solution was put on hold. Then, the PHBs started adding more clients to use this solution. It became a support nightmare as the hack was good for one customer, but not for four customers whose input is not reliable.

Now, the engineered solution needs to developed ASAP, but the resources are not available. I have had to create a second hack to replace the first to make the whole thing manageable and moderately reliable until the other solution is finished sometime in the middle of next year. In the meantime, they will expand the customer from four to fourteen.

Re:The question is - why?

[amicusNYCL]

Do we need a faster http? Really?

Of course not. HTTP as it exists now is perfect and sublime, and people will still be using this exact implementation over the next thousand years.

Twice as fast doesn't justify it

[edelbrp]

The nice thing about standards is that there are so many to choose from!

Why in the world implement a new standard whose purpose is to speed up the web yet only do it 2x under certain conditions? To be taken seriously, it would have to be orders of magnitude faster, but that's a huge hurdle because the root of the problem isn't the HTTP protocol, but what's happening on the web server (no pipelined connections? slow DB? uncompressed content? sloppy, inefficient coding?) and the end users' bandwidth. The one thing SPDY has going for it is compressing headers and eliminating redundant headers, but that's a small gain really.

In any case, you could simply wait and things will get naturally faster w/o new protocols because servers generally get faster and users' bandwidth increases. And by the same token the benefits of a new in-between protocol would diminish.

Cool stuff

[__aailob1448]

SPDY sounds like a really cool open source project if you ask me. Sure, it's not as cool as replacing TCP and HTTP completely but I bet I'm not the only one who's checking out the white paper and the implementation of the algorithms.

SSL for everything?

[colfer]

It says the goal is

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.

But the testing is on both TCP and SSL/TCP, since:

SSL poses other latency and deployment challenges. Among these are: the additional RTTs for the SSL handshake; encryption; difficulty of caching for some proxies. We need to do more SSL tuning.

How about downsides...

[unix1]

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.

Re:How about downsides...

[grmoc]

As a server implementor I can tell you that I'd rather have 1 heavily used connection than 20 (that is a LOW estimate for the number of connections many sites make(!!!!!!!)). Server efficiency was one of my goals for the protocol, in fact!

When we're talking about requiring compression, we're talking about compression over the headers only.

In any case, as someone who operates servers... I can't tell you how many times I've been angry at having to turn of compression for *EVERYONE* because some browser advertises supporting compression, but doesn't (which interacts badly with caches, etc. etc).

Re:How about downsides...

[unix1]

As a server implementor I can tell you that I'd rather have 1 heavily used connection than 20 (that is a LOW estimate for the number of connections many sites make(!!!!!!!)). Server efficiency was one of my goals for the protocol, in fact!

Average of 20 seems a lot considering most browsers cache all static content (images/HTML/Javascript/CSS/XSLT/etc.). Also, keep-alive can bring that number down to even less.

That is also a very general statement to make. Again, maybe that's true in Google's case (I don't know), but HTTP keep-alive handles this already for most cases by giving you control of how long you want keep the resources hanging around for a connection, or free them up for another client, and it's all depending on your environment.

For example, I am visiting a shopping site, blog entry, SPDY documentation page, etc., on average visitors spend X seconds/minutes on a single page on that site. With HTTP keep alive you are in charge of how soon you want to free up the server resource, and make it available for the next visitor; with a single permanent connection, you are still holding on to the resource as long as the client is still there.

Now, with say 100 visitors per 1 [time interval] starting at point N, you'll need to keep those 100 connections open until at least N+X. Now add 100 more visitors arriving at N+1, then N+2, etc. until you reach X. That's how many connections you'll need to keep open on average.

What I am saying is that number of connections is not going to be optimal in most cases. Because you'll almost always want to free up the resources way prior to the average of X. In fact, let's take some numbers:

100 clients / 1 second
X = 1 min
20 connections / client (took from your post)
Avg connection = 0.5 sec (doesn't matter as it rolls into the value of X anyway)
keep-alive = 0.5 sec (took from SPDY doc link)

With HTTP:
20 conns x 100 clients / sec = 2000 connections / sec (0.5 + 0.5)
Avg num of connections = 2000 (no keep-alive on client)
Avg num of connections = about 700 (w/keep-alive pipelining set to 4, default when enabled in Firefox)

Using SPDY:
Avg num of connections = 100 clients x 60 secs = 6000 connections

This would only make sense for low enough values of X where client needs to be getting constant dynamic updates from the server - an extremely media-heavy website maybe? It would almost have to be badly designed. I'm not sure, but it's certainly interesting. I am just wondering what testing conditions were used to achieve the results mentioned on the linked SPDY page.

When we're talking about requiring compression, we're talking about compression over the headers only.

In any case, as someone who operates servers... I can't tell you how many times I've been angry at having to turn of compression for *EVERYONE* because some browser advertises supporting compression, but doesn't (which interacts badly with caches, etc. etc).

OK my bad on that one then.

Re:How about downsides...

[cheekyboy]

Compression has been optional and available for 10 years.

The client tells server it can decompress, and the server decides to send 'pre cached compressed' content, or compress dynamic content if it likes.

eg. A 150kb FAQ would be quicker to show if it compresses to 30kb.

Re:How about downsides...

[unix1]

Compression has been optional and available for 10 years.

The client tells server it can decompress, and the server decides to send 'pre cached compressed' content, or compress dynamic content if it likes.

That's why I was saying it needs to _stay_ optional. But a later reply by the author says they would only be requiring compression on the header, so the point is moot.

eg. A 150kb FAQ would be quicker to show if it compresses to 30kb.

Are you just guessing, or do you have any supporting evidence? E.g. would it also be "quicker" if this was on an underpowered mobile device on a fast 3G network or wifi?

Now imagine if that same mobile device had to make not 1 but 5-10 connections, get compressed data and first have to decompress all of them before it's able to render and display a page. Would it be faster? Are there any tests to substantiate this claim?

Re:How about downsides...

[unix1]

Compression absolutely makes sense. Processing power is growing at a much, much greater rate than bandwidth.

Really? Do you have any facts to back up that statement, or is it just a wandering thought of the hour? Besides, just the growth rate of processing power vs. bandwidth does not give you the whole picture.

How about mix in other variables too:
- battery life/efficiency
- device size
- underclocked CPUs

Overall "growth" of CPU processing power is not as great when you consider batteries are not making equivalent progress. And devices are getting smaller and thinner, meaning batteries and everything else will need to be smaller too.

The point is - without any concrete evidence your statement is at best a complete guess in the dark, and at worst AC trolling.

Re:How about downsides...

[headbulb]

I am curious what browser's don't actually support gzip compression?

Re:How about downsides...

[grmoc]

IE didn't for javascript some time ago, certain mobile browsers and built-in browsers in various appliances don't (though the may advertise it) as well.

Indeed.

[XanC]

I'm not sure what everybody else is complaining about. Did they read the fine article?

HTTP-NG Revisited (ten years later!)

[kriegsman]

HTTP-NG ( http://www.w3.org/Protocols/HTTP-NG/ ) was researched, designed, and even, yes, implemented to solve the same problems that Google's "new" SPDY is attacking -- in 1999, ten years ago.

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.

Re:HTTP-NG Revisited (ten years later!)

[CannonballHead]

Next up: immediate support in FireFox, WebKit, and Apache -- and deafening silence from IE and IIS.

Hum. Not Chrome? ;)

Re:HTTP-NG Revisited (ten years later!)

[OzRoy]

Chrome uses WebKit

Re:HTTP-NG Revisited (ten years later!)

[grmoc]

BEEP, if I remember properly, was about an extensible protocol, but didn't focus on the issues relevant to speeding up browsing. It could be used, but it would introduce some inefficiencies that we currently don't believe are a good tradeoff..
However, we really want the community's input on this (so long as they're willing to do experimentation and measurement to back up opinions!)...

Re:HTTP-NG Revisited (ten years later!)

[Tumbleweed]

Now we have to decide what color to paint it.

Black.

Re:HTTP-NG Revisited (ten years later!)

[icepick72]

Oh IE will try to catch up when they realize their browser seems suddenly and even much much slower than the others.

Re:Akamai?

[paulzeye]

small nitpick- Akamai redirects requests to the appliance closest to the requester's reslover.

Would appreciate it if instead...

[jddj]

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...

Re:Would appreciate it if instead...

[Hurricane78]

Well, why did you buy it then? ^^

And about Outlook... You know it already, don't you? ... ;) ...: That's your own fault! :D

Re:Would appreciate it if instead...

[illumin8]

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...

Not to rub it in or anything... but iPhone does this.

Re:Would appreciate it if instead...

[jackchance]

reminds me of this

Re:Would appreciate it if instead...

[jddj]

Actually, no I didn't.

Since it's a top-of-the-line smart phone, and VZW's new flagship smart-phone and "iPhone killer", I didn't think to ask "hey, this can do the same must-have Outlook sync through a cable thing that your freebie and $30 phones do, right?"

It's not quite a smart phone if it won't sync with Outlook. Stupid phone, more like it. (and before you snark at me, I'm a Mac owner, user, lover (though not a Macolyte). I just have to use Outlook at work, and that makes Outlook sync (not through GMail, sorry) a _necessary_ feature).

When a phone will voice-dial, and when it will take a Bluetooth headset, I don't automatically think to ask: "Wait...will this phone voice-dial through the Bluetooth headset? No? Why the fuck not?!??"

What the hell good is voice dialing if you have to swipe to unlock the phone, pick an app, talk to it, then confirm your choice by tapping the screen?

Maybe the general question I should've thought to ask was: "Hey, are there things about this phone that suck? What are they?" But knowing VZW salespeople as I do, I'd have no confidence in the answer.

These are a couple of the WTF items for Droid. Another is: if I need to use a static IP on one of my WiFi connections, the phone tries to use the same static IP for ALL my WiFi connections. The static IP is bound to the phone, not to the connection. #fail

Yet another: If I have the phone locked, and I take an incoming call from my BT headset, the touch screen comes on on my pocket and mutes, disconnects, puts me on speakerphone. Wait a minute, I thought I had the phone LOCKED!

It's a wonderful hardware platform, but there are a fair amount of problems yet. I hope the real-world feedback (particularly anger over Outlook and the lack of BT voice dialing) will snap their heads around.

I bought the phone expecting a certain amount of early-adopter pain. I wanted to go on the journey with this product. But the Outlook and voice-dialing things just make my head want to explode.

"we've open sourced the code"

[Anonymous Coward]

we need some stupid idealistic programmer to do the work we dont want [to do, to spend on, etc]

Problems...

[scorp1us]

# 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

# 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.

Re:Problems...

[grmoc]

# 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!!

Re:Problems...

[grmoc]

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).

Re:Problems...

[scorp1us]

Don't waste my bandwidth, especially on a mobile device.

Idea fail.

Re:Problems...

[grmoc]

Huh? The protocol uses significantly less bandwidth for the same content (thanks to compressing the headers).
Surprisingly, compressing the headers makes a big difference.

Re:Problems...

[dlgeek]

He was referring to push. The concern is that a SPDY server might preemptively push data the client doesn't want (like an ad). Sure, the client can refuse to render it (as you stated before), but it's already gone over the pipe, which costs or penalizes the consumer on a metered or capped connection (like a cell phone or in Australia).

Re:Problems...

[cpghost]

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

How would you implement this rate-limit across a distributed server farm? Won't you need to propagate client's choke message to all involved servers? Or is this per connection only? And if so, what about anycast connections?

Re:Problems...

[grmoc]

I can understand that
One of the proposals was that the HELLO message indicates how much bandwidth the user wants the server to use for 'speculative' purposes.
Hopefully we'd figure out how to auto-tune based on connection parameters (e.g. if the browser tells us it is a phone), and so the user wouldn't have to set any defaults that would hurt in other cases.

Re:Problems...

[dlgeek]

How application-aware is the protocol going to be? (See this sub-thread for more discussion of the issue). If the protocol stack is going to be significantly application aware, maybe you can define various categories for pushing (ex: inline images, embedded frames, flash objects, etc, etc.) and the client's HELLO message can define which of the categories it wants the server to speculatively push.

Re:Problems...

[grmoc]

Well, I don't really know how to answer that. As with any protocol design, we want to provide mechanisms that are as generic as possible while attaining our goal.

In this case, we've talked about having 'priority' groups, which have flow control settings on their own. If the application chooses to assign a priority (which potentially could be exposed via javascript or tags eventually?) then the application in the webbrowser has control over it. This is probably as it should be-- your extensions would do whatever they want to these things anyway...

Re:Problems...

[dlgeek]

I want to make sure I understand what you're saying - the application behind the web server would have various priorities of content, so maybe the base HTML would be "CRITICAL", the images would be "HIGH" and the ads (really the javascript that displays them) would be "LOW". The browser would then say "send me >= HIGH" and the ads wouldn't get pushed, the browser would parse the page and pull it, unless an extension blocks it. My issue with that is that anyone who wants ad revenue is probably going to configure it to send the ads at a very high priority in order to attempt to maximize their revenue, thus still costing bandwidth without the adblocker being able to prevent it

However, I guess the saving grace is that the ad stuff is probably on a 3rd party server and can't be pushed by SPDY.

Re:Problems...

[grmoc]

In SPDY, the client always is the thing that defines the priority of the fetch, with PUSH data being low-priority unless the client has defined it otherwise.

When we implement flow control, we also want to have the client indicate how best to ratelimit data sent to it. This is so that if the client is making more than one connection (still likely to happen if resources are fetched from a different IP), then it needs to be able to tell one host to slow down so that it is always getting the highest priority data from either connection.

A very nice side effect of this is that you can get high priority data and tell the low priority data to fsck off before it uses too much of your bandwidth (or any, depending on your set limits).

This allows the clients to choose what cost/speed tradeoff they want.. and really, that is where the tradeoff MUST be decided because only the client has that data.

As for servers pushing ads.. Servers are going to do what they're going to do. If the server is going to not pay attention to the protocol spec, or what the user wants.. don't browse that site! As protocol writers, we don't have control over what people do (unless they use our reference implementation!).. We only have control over saying what they should be doing.
In today's world a server implementor can stick the ads/images/flash, whatever inline, in which case you have no ability to say no. With SPDY depending on how well they adhere to the spec, either it only gets better, or it is the same.

Reverse proxies

[gmuslera]

This is not supposed to affect applications, just servers or clients, but not sure how the server will "suggest" more files without at the very least parsing the html files served (probably caching a bit, then parsing, then sending the headers with the suggestions and then the actual content).

More than in the application web serves, could be interesting to implement this in the perimetral (caching) reverse proxy servers (like in varnish and others). That won't force changing probably legacy web servers, and implementing it could add some improvement even if this new protocol isnt used by most/all clients.

Re:Reverse proxies

[dlgeek]

Theoretically, it could do it by analyzing patterns of requests. If everyone who requests resource A then asks for resource B in the same connection, it can assume a relationship without ever parsing the data it's sending. In any event, it's a feature in the protocol that's up to the person implementing the server to decide how to use.

Or just use Opera Turbo

[TeXMaster]

(which is basically proxying from dedicated Opera servers)

Re:Akamai?

[TooMuchToDo]

Thanks for the correction. I thought I had seen that spoken about on NANOG's recent What DNS Is Not thread.

It already is, with no ads.

[John Hasler]

> What would be possible if browsing the web was as fast as turning the pages
> of a magazine?

With all ads blocked (including Googles) it already is.

SPDY

[rgviza]

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:SPDY

[Casandro]

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.

fst wb prtcl

[Anonymous Coward]

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?

Why is Google misunderstanding HTTP?

[koinu]

I don't get it. Maybe someone should actually use Google there and lookup "REST" oder "RESTful" and see how the web was designed and SHOULD actually work.

Re:Why is Google misunderstanding HTTP?

[grmoc]

Heya, what about the protocol doesn't support REST?
I'm not aware of anything, but if you can point it out, I'm happy to try to fix it.

I don't want new protocols from Google

[petrus4]

I've already seen the XML based, opaque mess that is Google Wave.

In an ideal world, corporations would not be able to have any say whatsoever in the development of collectively used protocols or languages. The suits are already destroying HTML.

Destroying things for the sake of money, is the only thing that suits know how to do. If you want to actually create something, and create something which is genuinely beneficial and positive in nature, the profit motive has to be removed from the equation.

People also need to stop believing the lies that they are told, that the profit motive is a necessary part of the process. It isn't. We see software development occurring on a daily basis, that the profit motive has absolutely nothing to do with. We also saw communication systems (in terms of the bulletin boards) being developed in the past, which were entirely non-commercial in motive and intent, as well.

Before you develop stars in your eyes about worthless things like Google Wave, try realising that none of the functionality it offers, is genuinely new at all. It is simply an obfuscated hybrid of a number of pre-existing protocols, which work far more effectively on an individual basis.

Instead of the idea advocated here, try using a text-based browser (such as links) for specific tasks, which bypasses all of the advertising, and massively reduces the amount of necessary bandwidth used.

Instead of Google Wave, use IRC.

Re:I don't want new protocols from Google

[ptudor]

please don't make me go back to using PHONE on VMS. Research and experimental new technology is alright.

Re:I don't want new protocols from Google

[cpghost]

In an ideal world, corporations would not be able to have any say whatsoever in the development of collectively used protocols or languages.

In the real world, many fundamental RFCs are being co-authored by (engineers working at) corporations. Just pay attention to the authors' section.

addin not needed

[eleuthero]

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)

Naysayers be naysaying

[wayward_bruce]

I love it how the know-it-alls jump and say "no, CSS/ads/JavaScript/AJAX/ is guilty". Timothy's post claims an observed twofold increase in speed in practice. Unless you want to flat-out say that he is lying, your arguments are invalid.

Um, humor me here...

[rickb928]

But doesn't this sound like another protocol?

So why not just make HTTP into SPDY?

Actually, why not give me a way to prevent the offensive ad loads, especially the hidden/cloaked ads? All these do is slow down my page load and cheat the advertisers. Wait, this is a 50/50 win for me... Well, maybe, but it still makes me wait for nothing I even suspect I want.

A pox on all of them, I say.

Application layer?

[Hurricane78]

So there is still (e.g.) Ethernet, IP and TCP below it? Sounds like yet another layer of inner-platform anti-pattern...

Or is TFS misleading? Application layer is clearly above TCP. But it looks like they created a replacement for TCP/IP from the rest of TFS. (Wich is a bit hard to get the world to use, to make it actually useful.)

Which is it?

Re:Application layer?

[grmoc]

It is an application-layer protocol. It is on top of TCP/IP, not a replacement for TCP/IP.
The reason it is 'between' HTTP and TCP is that the web/javascript authors see the same interface that they had before (requests, responses, headers, cookies,etc) with HTTP... but the representation on the wire has changed.

I'm NOT going to use Chrome!

[Snaller]

So you can take your proxy and go home.

I hope they learn from the past

[blake182]

This article points to a bunch of other efforts from the past. This list is most notably missing BEEP which also included the ability to multiplex multiple streams on top of TCP at the application layer.

I hope they're able to synthesize all of the thinking from these protocols into their work, and they bring this into the IETF and W3C for discussion when it's appropriate...

Re:Just turn off image loading (but not with SPDY?

[grmoc]

The server can push the content to you using SPDY, but the client can close that stream (not the connection, so you still get the data you really want).
In other words, the server will not push a terribly large amount of data before your browser can kill it with a FIN message. (It is 1-RTTs worth if the server is doing things according to spec).

Plus, since the priority of server pushed data is low (lowest) any request will immediately pre-empty any pushing that the server is doing.

Also note that just because the server pushes info, doesn't mean that the browser has to use it. It may simply put it into the cache to be used "in the future".. this is essentially how it works in the hacked-up chrome that we have today.

All of your adblockers, etc. should continue to function. :)

Re:Safari and Chrome-alikes = best /. browsers

[jeffstar]

my chrome dev build on ubunutu 8.04 is messed up right now. select boxes don't show the options and tabs are freezing, which has never happened before.

In the daily ubuntu chromium-browser build they have the select boxes fixed but still has random freezing.

Re:friend/foe indicator

[totally bogus dude]

It's still the same coloured dot/pill for me as it always was. Maybe it's implemented in some funky web 2.0 way that your browser doesn't like or you've configured it to reject?

It's actually written as text inside a <span> with class "zooicon fof" (for Friend of a Friend) so perhaps your browser isn't parsing the CSS properly, or isn't handling the space in the classname?

+1, Insightful

[martin-boundary]

Well said.

Worry?

[anarche]

is no one else worried about servers with extended open connections pushing data to the client without the client asking for it?. Sure its encrypted, but a decent MitM attack leaves the server wide open and the client expecting unwanted data...

What's the right tool for what's web apps today?

[jonaskoelker]

"right tool for the right job"

Fair enough.

What's the right tool to deliver to your users rich applications which are

• accessible from (almost) any computer, anywhere
• doesn't require the user to install software that isn't already pre-installed on most computers
• works on all architectures and operating systems
• can be updated for everybody by the application provider without invading peoples' machines

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?

diffserv and IPv6 label?

[GNUPublicLicense]

Hey... first thing first: normalized at IETF a proper IPv6 label for web document. Then, let IAPs deal with that label. BTW diffserv support is important too because it does work also with IPv4... but in which diffserv class with which priority shall we put the "web document traffic"?

+1 Fsck yeah!

[dzfoo]

Hear! hear!

            -dZ.

Re:What's the right tool for what's web apps today

[DaveV1.0]

What's the right tool to deliver to your users rich applications

Not the World Wide Web.
Not Hypertext Transport Protocol.
Not Hypertext Markup Language.

You have a hammer (HTTP/HTML) so everything looks like a nail to you.

Re:Not a terribly new concept: RFC 3229

[wdebruij]

RFC 3229 discusses a design for delta encoding in HTTP. I once stumbled upon this when I thought of doing something like this, as well. This idea makes a lot of sense, but it's well known. The main problem I see is that you need both parties to support it. Since gzip compression in HTTP is fairly common, this is not at all impossible. I have not RTFA, so they may well be proposing something different.

Guaranteed Ad revenue

[snadrus]

They did it, here's a feature we won't want to live without, yet it guarantees them that Ads are delivered: Server Push. Without it, you have round-trips for each page component. With it, forget adblock, even if you don't want to see the Ad, you downloaded it.
Don't care about the download, you still want adblock? Not in Chrome.

Why are you compressing my jpegs, again?

HiJacked

[imscarr]

Click on Chrome in this article http://www.itproportal.com/portal/news/article/2009/11/4/google-rolls-out-chrome-40-beta-and-updates-its-wave-platform/
and you get an ad for IE8. LOL

Re:Bug 487638 - status bar blames wrong resource..

[nanoflower]

I think you may be wrong on that. It seems that the bug they are fixing is a bug in the 3.6 code as I went to the three test scripts that were mentioned in the comments and with Firefox 3.5.5 everything worked as it should. When I went to the bencamm site it was slow as expected and the slow server mentioned in the status area was the bencamm site and not Google analytics. So it looks like Firefox 3.5.5 does the right thing and Firefox 3.6 didn't do the right thing.

Re:What's the right tool for what's web apps today

[jonaskoelker]

[Not WWW/HTTP/HTML]

I agree partially: I think, as I think you do, that these tools are really poorly suited for the things people want to do, and the things people do could work much better if they were made with better tools.

(display postscript over ssh, perhaps? Wasn't that Sun's NeWS? I've heard good things about it... see also my other suggestions.)

You have a hammer (HTTP/HTML) so everything looks like a nail to you.

I disagree with this bit. I think people want the universal accessibility and zero-administration properties of web applications. I've come up with two non-web ways of delivering that, which probably won't be popular, but... none the less, I'm not fixated on applications having to be web applications. Also, I think not every application should be web-based (in fact, I tend to prefer client-side apps over web apps, all else being equal)

Maybe I'm missing something. Which non-nails am I overlooking?

Re:friend/foe indicator

[pAnkRat]

Ehhh, that's not a space in the class name, it means: "please apply both class rules to this span"