New Breed Of Web Accelerators Actually Work

axlrosen writes "Web accelerators first came around years ago, and they didn't live up to the hype. Now TV commercials are advertising accelerators that speed up your dial-up connection by up to 5 times, they say. AOL and EarthLink throw them in for free; some ISPs charge a monthly fee. Tests by PC World, PC Magazine and CNET show that they do speed up your surfing quite a bit. They work by using improved compression and caching. The downside is they don't help streaming video or audio." And they require non-Free software on the client's end, too.

Comments

Faster porn?

[DigitalNinja7]

Unfortunately, these caches store only the most accessed pages, so anything of any value to the Slashdot audience will be as slow as ever. But you can be sure your porn will be delivered at 5x the speed of your normal dial-up! (yawn)

Re:Faster porn?

[Anonymous Coward]

Are you saying Slashdotter's don't value pron?

Re:Faster porn?

[onecrazyfoo]

Actually, how it was described to me, is that the requested page is retrieved by the ISP's server, cached and compressed, then sent along to the client. Which, with the compression they are able to get, is much faster for the dial-up user. At least that is how is supposed to work with Slipstream's product (what NetZero uses).

Re:Faster porn?

[Cramer]

1) If you're using dialup, the speed of the internet will not be a bottleneck (slashdot effect not withstanding.)

2) If you're already using compression (stac, predictor, MPPC, etc.), this will make ZERO difference. The cache has to be on the near side of the slowest link -- which is the dialup user's modem. Now, in the instances where the ISP disables software compression -- like, for instance, the "idiots" at Bellsouth.Net who disable CCP to "speed up connection times" [exact words of the Cisco engineer who helped them set things up] (the time it takes to connect and pass traffic is 100% modem training. For us ISDN users, 3 of the 3 seconds it takes to connect are IPCP; I'll accept that as they do tend to return the same IP most of the time) -- it'll help some.

3) A lot of what's moving around the internet isn't measurablly compressable... GIFs, JPGs, mpegs, zip files, etc. (I shall have to perform an analysis.)

You mean...

[HungWeiLo]

"Web accelerators"...You mean highly-advanced technology like mod-gzip?

Re:You mean...

[pla]

"Web accelerators"...You mean highly-advanced technology like mod-gzip?

Sounds pretty much like that... Which Apache already supports, and the major browsers already support, making something like this redundant.

Moreover, dialup modems already use a fairly high level of compression at the hardware layer. While not exactly "gzip -9" quality, you can only realistically squeeze another 10% out of those streams no matter how much CPU power you devote to the task.


Others have mentioned image recompression, which has traditionally used VERY poor implementations, nothing more than converting everything to a low quality JPEG. I would point out that a more intelligent approach to image compression could yield a 2-3x savings without noticeable loss of quality (smoothing undifferentiated backgrounds, stripping headers, drop the quality a tad (ie, to 75-85%, not the 20-40% AOL tried to pass off as acceptible), downgrading the subsampling on anything better than 2:2, etc). But no, not a 5x savings.

Re:You mean...

[Anonymous Coward]

Uh, no. mod_gzip will compress _much_ better than your modem. Your modem can only compress in small chunks, and so there is less redundancy to remove. Even small(ish) web pages can be compressed, as a whole, to a much, much smaller size than what your modem can.

In fact, using mod_gzip I've experienced a very discernible speed-up in access and display over DSL!

Re:You mean...

[pla]

why is it that downloading a 1meg file full of ZEROS still takes ages on a modem?

Because v.42bis has a maximum compression ratio of 4:1 (MNP5 only does 2:1).

Now, for a file of all zeros, hey, I agree, you can do a lot better. So, how often do you download files containing nothing but zero? For a typical text file, you might get better than 90% with gzip (while still only 75% from v.42bis). But from binary content? very rarely better than 50%.


In any case, web content consists of five basic types of information - Text, graphics, sound, multimedia (flash, MPEGs, AVIs, etc), and already-Zipped packages.

Of those, only the first benefits from any lossless method, and only the second really leaves any room for saving bits via lossy compression without horrible loss of quality at the same time. (Some of the fourth type could also possibly endure lossy compression, but takes far too long to recompress on-the-fly).

Unfortunately, text comprises the least bothersome (in terms of relative size) of all of those major types of web content.


Don't get me wrong, I fully encourage people to turn mod_gzip on in their Apache installs. But When a company hawks its product with claims that simply cannot occur in a normal webbrowsing situation, I have to call foul.

I see only two situations whereby they could claim 5:1 compression - Either VERY text-heavy material, such as reading something from Project Gutenberg, or they strip every possible non-critical image from a page. I already do the latter via my hosts file and a paranoid userContent.css, so what does that leave?

Hope you only like reading text, in which case, have you ever heard of "Gopher"?

Re:You mean...

[flug]

>Now, for a file of all zeros, hey, I agree, you
>can do a lot better. So, how often do you download
>files containing nothing but zero?

Er, every time I visit Slashdot?

Awwww boo hoo

[stratjakt]

They require non-Free software?

Well, why don't you go ahead and write some Free software to accomplish the same thing?

My GameCube requires non-Free software too.

Wahhhh

Re:Awwww boo hoo

[Anonymous Coward]

Apache/mod_gzip + Mozilla = free accelerated web content. Oh, and you can throw in squid if you want caching.

Re:Awwww boo hoo

[stratjakt]

Nah, this is different altogether. Gzip is not the alpha and omega of compression.

Different algorithms lend themselves better to different applications, so it seems to me a good accelerator would use a mix of algorithms based on MIME type.

Ie; is the source data formatted in 24 byte words? 16 bit words? 8 bit words? If you have 8 bit data you don't want to look at 16 bit chunks, because then the string "abacadaeafag" doesnt compress for you. Dictionary sizes and blah blah blah... Even format conversion - turn all those BMPs that dingbats put on their pages into PNGs or lossless jpegs..

And as for caching, it seems to me like more of a prefetch than a squid-type cache.. Ie, you request page, proxy at IP gets page, compresses it on the fly, then sends it. Caching it locally is more of an advantage WRT latency, not throughput.

There's a lot of common sense tricks you could use. And according to these articles, they work.

Re: Awwww boo hoo

[Master Bait]

Well, why don't you go ahead and write some Free software to accomplish the same thing?

Running Squid with a 256mb ram disk cache is all the speedup we need, and it does so without altering the data being fed from upstream.

For a few dollars more . . .

[Brahmastra]

get broadband. This will definitely help places that still don't have broadband. But, if broadband is available, it's a no-brainer. I'd rather spend a few bucks more and get broadband, rather than be stuck with some kind of software that may or may not speed up the access depending on what it is.

I still don't understand

[Anonymous Coward]

Why so many content providers aren't using gzip compression? The cpu time required is MUCH cheaper than the bandwidth, AND it makes users happiers because they get it faster. Oh, and it's free (for Apache anyway) and easy to set up. It even works with 99% of browsers these days.

Re:I still don't understand

[statusbar]

That can't be true. mod_gzip isnt used unless the browser tells the server via the Accept-Encoding header.

--jeff++

Re:I still don't understand

[eduardodude]

One reason is that mod-gzip sometimes conflicts with other modules when used in apache 1.3. Another is that users behind proxies typically don't see any benefit because most proxies are by default set to strip out the accepts-encoding: gzip request header (I think to simplify the job of caching compressed/non-compressed content?).

But you're right: there's no reason not to use it if you can. The bandwidth savings can be massive, saving $$.

Re:I still don't understand

[Fr33z0r]

Why so many content providers aren't using gzip compression? The cpu time required is MUCH cheaper than the bandwidth, AND it makes users happiers because they get it faster. Oh, and it's free (for Apache anyway) and easy to set up. It even works with 99% of browsers these days.

The problem with mod_gzip is it makes the webserver wait until a script is finished executing before it sends *anything* to the browser - no fancy "please wait while we do blah blah blah" pages with mod_gzip installed.

I wrote/am writing a rather nifty chat script that runs realtime through http just by keeping the connection open and flush()ing at the end of the main loop, with mod_gzip installed you would never see anything until you interrupted the transfer (by hitting stop, or back - effectively ending the script and freeing up the server to transmit the data).

mod_gzip is cool for cats, but it's not without its drawbacks.

Yeah, right!

[Anonymous Coward]

And they require non-Free software on the client's end, too.

And I'll just bet that none of that software includes any popups, spyware or intrusive monitoring!

But really, why?

[agent dero]

This seems like a really niche market nowadays. Not _too_ many people that need fast internet, that could use this, don't have broadband availible. The one key thing is price, which is even starting to get iffy.

Something like $10-20 monthly for "speedy" earhtlink dial-up, or an extra $10-20 slapped on my monthly cable bill for broadband? (Charter Communications, they suck anyways)

I guess if you need to read /. or pr0n that much fast, it works, tell me if I am wrong, but I am seeing a small market for this much hype

Next thing...

[koi88]

They actually work?
Next thing they find out is the new generation of penis enlargement devices actually work, too...

Non-Free software?

[divisionbyzero]

OMG, not that! I know this won't get much play here, but I don't care if it's free or not as long as it works. I use the Free software that I do because it is better than Fee software, not because it is free. Shame on me for not being an ideologue.

Re:Non-Free software?

[orasio]

I am an RMS fanboy, and I am not _obsessed_ with avoiding proprietary software. I _prefer_ avoiding it, its an ethical issue. Its a shame that the US people pays no attention to RMS, given how visionary he has been all these years. He has an interesting point of view, even if he is a bit rough when defending it.

tradeoff

[nstrom]

It's just the old tradeoff between CPU power (decompression time) and bandwidth usage (download time). Much easier (and more smartly) implemented on the server side with something like mod_gzip, like HungWeiLo said.

And graphic compression's been done before too, since around AOL 3.0 or so. Most people turn it off because it makes pages look like crap.

Re:tradeoff

[afidel]

This technology is NOT lossless, read the article.
If you choose the highest speed (and hence the greatest compression), the image quality is downright poor. On PCMag .com, for example, the photo accompanying John C. Dvorak's column became a featureless blob.
Doesn't sound lossless at all to me. If admins knew what they were doing the HTML,CSS, etc would already be compressed with mod_gzip or the little compression checkbox in IIS.

What the hell?

[elwoodblues16]

Snake oil that works? What do you even call something like that?

They aren't really that great.

[Jerk City Troll]

My former company was checking out NetAccelerator recently to resell to our clients.

These things are a joke. The primary performance increase comes from recompressing images into really nasty JPEGs. AOL was doing this years ago (and getting blasted for it). If you turn that off, the performance improvement is not even measurable.

Furthermore, you tend to get a lot of stale caches on your machine. Most browsers don't even get this right, so they add yet another layer of potentially buggy cache abstraction.

No, these things are junk. They act as proxy servers and their source is closed. How can you trust them to handle your data? Even with all their compression features turned on, the performance improvement is seriously overrated. Don't bother. You simply cannot get something for nothing in cases like these.

Now, what would improve the download speed of the web is if web designers would start building standards compliant markup. Many web sites have as much as 700kb overhead in markup from tools that create loads of font tags and their ilk. Pure XHTML + CSS layout would do a hell of a lot more to speed up the web than these scams. Of course, don't take my word for it--read Zeldman.

Re:They aren't really that great.

[Reziac]

AOLpress makes the cleanest, most legible HTML you'll ever see (better than most people bother with their hand-crafted HTML, in fact). It's also utterly anal about correct tags. I use it as a validator and code beautifier even when I've built the page in something else. Between that and its ability to work as a browser (a huge timesaver when a site is all unique pages and you need to follow links back and forth between several of 'em as you edit), it's completely ruined me -- now I expect *every* editor to do as well :)

Save As HTML woulda been my first thought too.. except knowing the kark that Word thinks is HTML, I'd probably do this instead: save as WordPerfect 5.1, then (assuming I didn't have WP available to cut the middleman) I'd run it thru one of the WP-to-HTML tools, which usually do pretty well on tables, then load and save in AOLpress to clean up artifacts and mismatched tags. And when it magically appears on the website well before the deadline, the boss thinks you're a genius. :)

Compressing the already compressed?

[insecuritiez]

They compress the packets of data. Where will this help? In compressible places that aren't already compressed. Such as the HTML markup for webpages. This wont help already compressed JPGs, or already compressed MP3s or already compressed ZIP/GZIP files or already compressed videos (MPG/AVI/ASF). So is this really going to help much? Sure, there is always going to be a small percent of space (and therefore time) saved even transferring these formats. Is it going to make a 5X difference? No. Is it going to make a noticeable difference? It's unlikely but possible. The only way this "new technology" is going to help is if you are a dialup user without broadband options.

rproxy -- also actually works, and open source

[mattbee]

rproxy is a really interesting project, and back when I tried it over a 56K dial-up connection, it did actually work to speed things up. You sit an rproxy web cache at each end of the dial-up connection (so you need somewhere to deply your custom proxy to make it work, but bear with me...) and then request web pages as usual. Each end caches the pages that pass through it, but the clever part is that when you re-request a page, the proxy at the far end (on the fast connection) can fetch the page and compare with the last copy in the cache. Then it transmits only the differences using the rsync algorithm. Unforunately it's not being actively developed any more given the increasing availability of high-bandwidth connections, and the decreasing fraction of web traffic that is suitable for delta-compression. Shame, since it did seem to be a real "web accelerator" without any of the illusory techniques used by the garish banner-ad accelerators.

Re:Does anybody really care?

[toomuchPerl]

I'm ...
on ....

dialup....
you....
insensitive ...
clod!

And my connection is wheezing just trying to post this!

because IIS's is garbage

[DrSkwid]

mod_gzip is manna from heaven

I turned mine off by accident once and got a phone call from the co-lo wanting to know why I was suddenly maxing out.

gotta love that 70% saving.

Re:because IIS's is garbage

[Micah]

I agree.

I used to host Slashcode based sites. The default home page was about 50k. With mod_gzip, it literally got down to about 6k. Really sweet!

Re:because IIS's is garbage

[Micah]

Of course, I should also add that both numbers would be a lot lower if the Slashcode theme remotely resembled web standards instead of horrendous amounts of nested tables and "spacer" graphics, but that's getting off-topic.....

Re:because IIS's is garbage

[Jerf]

Of course, I should also add that both numbers would be a lot lower if the Slashcode theme remotely resembled web standards instead of horrendous amounts of nested tables and "spacer" graphics, but that's getting off-topic.....

Actually, try downloading your page, copying it, gzipping the original, cleaning up the copy to your specs, gzipping that, and comparing the two file sizes. While you may kill a lot of text in the uncompressed version, I would strongly suspect you'll find that the gzip'ped version saved much less then you think.

Those "spacer gifs" that take up perhaps 100bytes apiece in the original file (perhaps a bit generous) will compress away down to very little (if there are several near each other, they may literally compress down to a handful of bits after the first one), whereas the story text compresses much less well.

If you're compressing things, XML, CSS, and a lot of other things that look awfully redundent in plain-text are suddenly downright bandwidth-efficient technologies, being dwarfed in their compressed representations by the plain-text payloads. This is one of the reasons that fundamentally XML is so cool; you get human readability, but for the very small effort of invoking gzip or similar compresion technology, you also get something that is very nearly as bandwidth-efficient as possible, because compression technologies dynamically determine the best binary encodings for such messages (including their plain-text payloads), whereas supposed "efficient" binary protocols may actually waste a lot of space. (Compressing the both of them may equalize them, but the binary file, perversely, will still be "harder" to compress, even with nearly the same information in both files.)

How compression behaves is not necessarily intuitive.

Squid & mod_gzip

[chill]

ISPs could simply put some squid caches between the net and their dial-up banks. Turn mod_gzip on and you'll accomplish a lot of the same thing.

Instead of having to traverse the Internet, with all the associated latency, pages are pulled locally - 1 hop away. Pages are also compressed.

A better way would be to figure out how to transfer pages via CVS, so only .diffs came across. :-)

Re:Squid & mod_gzip

[Anonymous Coward]

Does that actually exist, a mod_gzip for Squid?
There is a mod_gzip for Apache...

Re:Squid & mod_gzip

[burns210]

on your cvs comment, it sounds alot like the rsync solution... rsync copies files over the net. but if the file already exists, it will only copied the sections of the file that are change(10% maybe) and keep the other 90%... That sounds like a great feature to have for the cacheable proxies.

Re:Squid & mod_gzip

[chill]

on your cvs comment, it sounds alot like the rsync solution...

Doh!

I meant rsync. I use it to sync websites on multiple servers.

Thanks.

Just remember

[El]

GIFs, JPEGs, MPEGs, and MP3s are already compressed, so compression doesn't make them any smaller. That really leaves only HTTP, HTML and CSS to benefit from compression. And caching only helps if you're in the habit of looking at the same pages multiple times... so where's the benefit for the average porn-downloading, RIAA-infringing geek? Does it speculatively preread links before I click on them?

Re:Just remember

[MerlynEmrys67]

GIFs, JPEGs, MPEGs, and MP3s are already compressed

For a given representation these are all compressed. However in all cases these have lossy compression, where you can degrade the quality of the final output and send a smaller bitrate over the wire. Want me to prove my point... Take your favorite CD quality MP3 - lets say the track is 100 K. Now take it and convert the quality to minimum quality - the file will be like 20 K now (if even that much)... you can still hear what is going on... but the quality will suck. Can do the same thing with the rest of the compressed formats as well.

Re:Just remember

[MerlynEmrys67]

Yup... this is exactly what they are doing... Remember I have a local proxy cache - and multiple T-3 links to the internet - you have a 33kbit connection to this. If I can get a 100K file - spend time compressing it by 5x and get it to you in less time than it would take you to get the 100K file (24 seconds right) I have won. And guess what - the next sucker that asks for it, I get to give the recompressed data too for free.

In many cases CPU power on the internet is free, bandwidth is expensive and worth spending free CPU cycles dealing with... Oh - how do YOU know that you are getting a degraded image anyway ? the average idiot going through an ISP that would do this only sees the internet this way.

Hooray...

[-Grover]

You can get the same thing you looked at yesterday 5x faster!!

Caching and compression will only get you so far before lossiness (sp?) kicks in and you start getting garbage, or caching works so well you get the same page every time you load it.

Get on the bandwagon and chip the money for Broadband if you're looking to boost your speeds. If you can't get a/v any faster, really, what's the point?

Low bandwidth main pages becoming less and less prevalent so it's not going to do you much anyway, plus, you're still paying for it...

Semi-real, maybe

[Empiric]

Okay, so GIFs, JPGs, streaming video, ZIPs, and compressed .EXE installers are all already compressed near to their thoretical limits.

[Puts cynics hat on]

The vendors mentioned in the PCWorld article seem to be treading dangerously close to copyright infringement by compressing other people's content on their servers to be pulled through their browser proxy.

NetZero and Earthlink apparently force you to use their proprietary internet-access layer, so how are we sure their extra-cost "Super" speed isn't just normal internet speed, and their "Base" speed isn't just slowed down by the interface layer?

[Takes cynics hat off]

The only thing here that seems like it would be genuinely useful is HTML compression... surely there is/will-be an Open Source solution for this. Maybe a new MIME type, e.g. text/html.compressed? Then it could be implemented on both the browser and server side, and this would have far greater impact. This could be implemented either in the browser itself or in a lightweight proxy like Proxomitron. Anyone? Anyone?

Nasty JPEGs?

[Hayzeus]

OK -- now you'vegot my attention. Like, um... just how nasty?

Methods

[wfberg]

Caching webpages in a proxy is something all ISPs do. The downside is that whenever I've used an ISPs squid proxy, it slowed things down! Turning proxies off almost invariably helps speeds, in stead of hurting them. Plus, if the proxy goes down, you can still use the web. I have no idea why ISP's proxies are so craptastic (YMMV), but in my experience, they are. (BTW, it would help if windowsupdate was cacheable..)

Compression.. Now there's something! I have in the past used an ssh tunnel (with compression switched on) to my university's web proxy, and that sped up things quite a bit! Why isn't this switched on by default on my PPPoA connection? Doesn't apache handle gzip'ing these days? Doesn't seem to be used much, though.. This speed up might be less pronounced on dial-up links though, because POTS modems usually switch on compression anyway (again YMMV).

Some download accelerators simply download different chunks of the same file in multiple sessions from either one server (shouldn't matter - unless with roundrobin DNS) or even from mirrors (better!). That's quite effective as well, but we know this, and that's why we use bittorrent for big files, don't we? ;-) Not such a good approach for webbrowsing btw.

But it has to be said.. Most download accelerators are just bloaty spyware and don't do *zilch* to help your download speed.. Feh!

Didn't AOL use to convert GIF graphics to their own, lossy, .ART format when you used their client? Do they still?

Re:Methods

[Phroggy]

Caching webpages in a proxy is something all ISPs do.

Wrong. Most of the larger residential ISPs probably do, but mine certainly doesn't, and of the last four ISPs I worked for, only two did any caching at all, and one of those only did caching in certain limited situations.

The downside is that whenever I've used an ISPs squid proxy, it slowed things down! Turning proxies off almost invariably helps speeds, in stead of hurting them.

Hogwash. I've been using a caching proxy server on my LAN for the past several years, precisely because it increases download speed. Now that I'm using broadband the speed increase isn't noticeable, but on dialup it was - somehow Squid is actually more efficient than Netscape or IE at downloading pages. Of course, with multiple computers you get the caching benefits on top of that.

If your downloads go slower through the proxy, it's because the proxy server is overloaded and your ISP needs to upgrade it - not because proxy servers inherently slow things down.

Plus, if the proxy goes down, you can still use the web.

Of course routing web traffic through a proxy server adds an additional single point of failure, in addition to the other points of failure already in place.

Compression.. Now there's something! I have in the past used an ssh tunnel (with compression switched on) to my university's web proxy, and that sped up things quite a bit! Why isn't this switched on by default on my PPPoA connection? Doesn't apache handle gzip'ing these days? Doesn't seem to be used much, though..

Compression is the main thing these "web accelerators" do. Your ISP runs the server and you run the client, and data exchanged between the two is compressed.

To compress your PPPoA connection would require the router where your connection terminates to compress and decompress ATM cells as they're tunneled inside a PPP link. That's not necessarily very efficient. It would require extra processing at both ends, and may not result in that significant a speed improvement. You probably want higher level compression - fitting more data into a packet, instead of making the packets smaller.

And yes, mod_gzip is available for Apache. Slashdot is using it, didn't you notice? No? Then quit complaining about how little it's used.

Another class of people who can't get broadband

[yerricde]

You admit that a $200,000 setup fee isn't "a few bucks more." Thank you; most people miss this.

But what about people who are so mobile that they need to be able to jack in and access the Internet from any of several locations, and they can't afford the price of a broadband subscription for each location? I was in just that situation for four years. Dial-up has the advantage of a last mile in almost every home in the States, brought to you by the Universal Service Tax, meaning that no matter whose house I was visiting, I could always plug my laptop into the wall and dial my Verizon Online account.

Wow, what an amazing concept!

[default luser]

WOW, a webcache and real-time compression!

My browser and my modem with .v42Bis compression have only been able to do that for, what, nearly a decade?

Cache the Suckage

[Bonker]

I worked at a local ISP who managed to get a demo for a cache server a while back. (I don't anymore.) The machine arrived. We plugged it in, and started to take tech calls.

Basically, it proxied all requests through that ISP on port 80. If it found a request to an IP or sitename it had visited before, it tried to serve it out of cache. If it didn't, it proxied the result through and returned the results from the requested IP or sitename.

The problems:

The server had a difficult time with virtual hosting of any kind. About 4 out of 5 requests to a virtual host would go through. About 20% of the time, there was some critical piece of information that the cache server would mangle so that the vhost mechanism would be unable to serve the right data. This was a couple years ago, so bugfixes might have happened. Maybe.

The server definitely had a hard time with dynamic content that wasn't built with a GET url (thus triggering the pass-thru proxy). If the request was posted, encrypted, hashed, or referenced a server side directive of some kind (server-side redirects were a nasty) the cache would fail. A server side link equating something like "http://www.server.net/redirect/" to a generated URL or dynamic content of some kind was the most frequent case we rean into with this. The server simply couldn't parse each and every http request or every variety and try to decide if it should pass-thru or not. I can't think of a logical way around this that wouldn't break any given implimentation. Can you?

We used dynamically assigned IPs at the time, so proxy requests made from one PC were often returned erroneously to another assuming the IP changed between usage. Say a modem hangup, etc. This was a rare event, but I listened to at least one person complaining that he was getting someone else's Hotmail. The fix to this is either to blacklist sites from being cached-- infeasible for every site that could possibly be requested-- or assign static IPs. DHCP broadband users may have similar problems, especially for those who have new IPs every so often.

Finally, if something got corrpted on the cache server due to disk error, stalled transfer, or some other reason, the sever had little or no way to throw out the bad data. It would throw out data that it *knew* was corrupt due to unfinished downloads, etc... , but often times this check failed or data was assumed to be correct even when it wasn't. Everyone who requested the same piece of corrupt data got it. I had to answer this statement a few times. "I downloaded it on one computer connected to your ISP and got a bad download. I downloaded it on my other computer from the same ISP and got the same bad download. Then I connected to another ISP from the first computer and got a complete download. What's up wit' dat, yo?"

Cache servers are a bad idea. The very idea is to try to be an end-all be-all to everyone who uses them. There are bug-fixes to some of the problem, but no way to solve the essential problem of the fact that MOST data on the web is dynamic now. Using cache servers with dynamic data is inviting difficulty and problem.

Re:Cache the Suckage

[slamb]

Sounds like you had a horrible experience with one. But the problems you saw were bugs in the software, not fundamental problems with the concept. One by one...

I worked at a local ISP who managed to get a demo for a cache server a while back. (I don't anymore.) The machine arrived. We plugged it in, and started to take tech calls.

Sounds like this was your mistake. You "managed to get a demo" speaks volumes. Sounds like an expensive proprietary product from a small company. If you had just downloaded Squid, I don't think you would have encountered all these problems.

The server had a difficult time with virtual hosting of any kind. About 4 out of 5 requests to a virtual host would go through. About 20% of the time, there was some critical piece of information that the cache server would mangle so that the vhost mechanism would be unable to serve the right data. This was a couple years ago, so bugfixes might have happened. Maybe.

Sounds like it only supported IP-based virtual hosting. Back in the day, most sites would have had separate IPs for everything they hosted, so that percentage sounds right. The 20% that failed needed a "Host: www.virtual.com" header.

The server definitely had a hard time with dynamic content that wasn't built with a GET url (thus triggering the pass-thru proxy). If the request was posted, encrypted, hashed, or referenced a server side directive of some kind (server-side redirects were a nasty) the cache would fail. A server side link equating something like "http://www.server.net/redirect/" to a generated URL or dynamic content of some kind was the most frequent case we rean into with this. The server simply couldn't parse each and every http request or every variety and try to decide if it should pass-thru or not. I can't think of a logical way around this that wouldn't break any given implimentation. Can you?

First, I think you mean a POST query would trigger the pass-through. GET is the normal method.

Second, there are pretty simple ways for triggering a cache or not. The full rules are here, but very roughly a page should be cached if and only if:

• There is an "Expires", "Last-modified", or "E-tag" header set
• There is no "Cache-control: no-cache" header set
• There was no authorization domain required (HTTP authorization; this doesn't catch forms of course)

If one is in the cache other than the Expires (which doesn't even need to be checked), it will query the server and check if the content is the same as before (with a special header that instructs the server not to send anything if it's unchanged).

This is a nice rule because webservers tend to automatically set the Last-modified: date on plain files and never do on dynamic stuff, so you have to explicitly add it in your dynamic code after considering it. So it gets most of the static stuff automatically (and that's generally the big stuff - images) but is cautious with anything dynamic. That's the correct approach.

This scheme really only breaks down when clock used by the requester (cache server in this case, browser also) or by the content generator (possibly the webserver, but also maybe the desktop used to generate stuff and then upload to the webserver) is skewed. And even then, it just gives stale data; not one person logged in as someone else. And this problem occurs even without a caching server, since browsers implement caching by themselves. Really, having a correct time is important to lots of things on computers. For example, don't ever try to do development without your clock being correct; build tools will be completely unable to tell what's up-to-date and what's not. Ticket-based network authentication systems (like Kerberos implementations, including Microsoft's shiny new ActiveDirectory) will refuse to log you on. etc, etc.

We used dynamically assigned IPs at the time, so proxy requests made

Free Web Accelerators

[wang232]

There are two free software projects building web accelerator proxies. One is RabbIT . The other is ziproxy. They are both web proxies which do not require any special software on the client side. They both compress HTML by gzip, and compress images into lower quality JPEG's. RabbIT is written in JAVA whereas ziproxy is written in C. RabbIT has more features than ziproxy, such as caching and removing ads. Give them a try if you're using a slow line! Disclaimer: I'm a ziproxy user and developer.

Oh yeah?

[identity0]

If they're so good, why isn't this first post?!

A little bit of insight..

[ewhenn]

Netzero offered this a while ago (maybe they still do). Basically it does speed up loading of pages greatly, however there is a drawback, and a big one at that, the pictures look like crap. The GIFs/JPEGs/etc are compressed. Compressed so much to the extent that they look like, for lack of better terms, crap. A rule of thumb applies here, if it sounds too good to be true, it probably is. You really cant expect broadband speed for the cost of a dial up, and if you do I have some lovely penis pills to sell you for the low low price of 69.95.

Use faster web servers

[peel me a grape]

The web could be faster if web server admins used faster web servers. Zeus Web Server instead of Apache, for example. The Holy Grail of web serving seems to be "good enough is good enough, and performance is someone else's problem".

Tests by PC World, PC Magazine and CNET show ...

[noahbagels]

That's about all the article had to say:

Tests by PC World, PC Magazine and CNET show

These are the same magazines with full color, multi-page reviews of the new 0.025% faster hardware. They are the same magazines that review each micro$oft product and say that the TCO is lower than ever before. Take one look at any of their websites, and you will see:

These magazines are Advertisements

Taking anything from them seriously is like taking a presidential speech to be a serious economic discussion, or taking a realtor's web-site as gospel in the market.

Funny - just went to CNET.com to research my post, and guess what? Over 50% of the page is advertising. The rest is 'reviews' of which 100% have links to affiliate programs to purchase said hard/software and give a kickback to CNET.

They will try hard to sell anything, and get their commission. It's like they are the used car salesman of the internet - only everything is new and they don't look you in the eyes when lying to you.

Squid

[Helmholtz]

Personally I've found putting my modem on a box with a large amount of disk space and running squid to be extremely useful. In between the agressive caching and blocking banner ads, most of my web browsing doesn't seem very slow at all.

Of course when it's a new site chock full of graphics, or I'm doing binary downloads, I'm painfully aware of my modem's limitations. But for general surfing, sometimes it seems almost as good as the friends' broadband.

RabbIT Proxy

[DA-MAN]

Ah, you mean like the RabbIT proxy. Personally I run this on my box on a t1 and use it whenever I am stuck with all but dialup.

Speeds things up so much, it's not even funny. Although it does require that you have a machine on a decent, faster than dialup connection to make it work well.

Can't compress twice

[fm6]

I would prefer more browsers to use gzip for retrieving web pages.

I might be wrong, but I'm pretty sure this would have not help dialup users at all. They're already using hardware data compression in the modem. When you're using lossless compression, there's an absolute limit as to how much compression you can get -- and you can't get around that limit by running your data through multiple compressors.

(I should check this out by timing various downloads, but I'm too lazy. Somebody else can prove me wrong!)

So why do JPEG files with "more" compression download faster? Because JPEG is a lossy format: when you increase the "compession" you're not encoding data more efficiently, you're throwing data away. Depending on the image, you can do this and still end up with something that looks the same. But push it far enough and you end up with crap.

Re:Can't compress twice

[HeghmoH]

You're making the incorrect assumption that all lossy compression is equal.

Modem compressors work very, very poorly. This isn't just because the people who come up with them suck, there are fundamental problems with doing compression in the modem. In order to avoid introducing really horrible latency, you have to compress the data in fairly small chunks. You can't wait for 50k of data to arrive from the computer and compress it all at once. Yet any decent compression scheme will achieve better compression ratios on longer chunks of data than shorter ones in non-pathological cases. So you have a modem which is stuck trying to compress a hundred bytes at a time, and a web server which can compress all 100k of page at once, and you have a significant difference in size. Also, gzip runs on a computer with a truly mind-boggling amount of number-crunching power available compared to a modem, which has a CPU just powerful enough to handle complicated commands like "ATH". With more CPU power, you can achieve better compression ratios.

In the end, modem hardware compression is basically a hack, and mostly a worthless one. There's a reason why everybody who distributes a file for download compresses it first, and it's not because it makes the file look prettier.

Get Broadband

[batkins]

Seriously, it's a lot easier to just get broadband. I mean, look at it this way - these people are paying in the neighborhood of $19.95 a month (or $22.95 if they're letting AOL rape them) and also around $15 for an extra phone line. So in most cases, you're paying around $35 a month for crap service.

Where I live, DSL is $30 a month and cable is $40 a month. How can you argue with that?

Re:Get Broadband

[Muggins the Mad]

> Where I live, DSL is $30 a month and cable is $40 a month. How can you argue with that?

Um, because I don't live where you live?

- MugginsM

Because

[ZorbaTHut]

The CPU time isn't always cheaper than the bandwidth. Some sites get cheap bandwidth and serve a ludicrous number of database-driven pages that are slightly different from each other - they're designed so that the database servers can handle the load, but gzipping every single page absolutely slaughters the webservers, which are barely doing anything more than relaying requests back to the database servers and are *still* running at high load.

Re:You mean... -- You miss the point

[eduardodude]

Yes apache and all 4.0+ browser support the gzip/mod-gzip combination. But the fact is very few websites implement this. Lots of reasons for that (mod-gzip conflicts with many other modules for one) although many more should than do.

A service like this that acts as a compression proxy can dramatically knock down the size of content. We implemented this at my last client and saw 78-93% compression of everything other than images. That includes css, javascript, dynamic web content, etc. I don't know about images, but this alone is very significant for today's clumsily table-laden pages.

Useful for portable connections unlike DSL

[goombah99]

DSL is only useful if you dont move around. When you travel or if like my parents you are retired and semi nomadic, you cant afford to get DSL connection at every place you might live.

Likewise I often find myslef in some crappy hotel where the connection is so noiesy I can barely squeeze a 14.4K connection out of it. I just want to check my web based e-mail not download the encyclopedia britannica

so anything that can make a dialup work painlessly on common web pages is a good thing.

Hey weren't you in my class?

[narftrek]

You......
went.....
to the.....
William.....
Shatner....
school of.....
acting.....
didn't you?

Well, actually . . .

[erikharrison]

I hate to conflict with the general Slashdot opinion that this technology is somehow bad, but the truth is this stuff rocks

I've seen Internet Connection's acheive compression rates and acceleration rates breaking 130Kbs (equivalant).

We've talked some about compression rates, but there is more to it than that. This stuff does:

• Serverside image regression. Images have their quality reduced (at variable levels) on the server, thus reducing download times. And with good IE integration you can pick individual images or pages to restore to full quality.
• Persistant connections. And by that, I am refering to TCP/IP sockets. A surprising amount of traffic on a dial up connection is renegotiating TCP sockets, because the reduced bandwidth results in lots of TCP/IP time outs. The ISP's server is on a broadband connection, so it can maintain those TCP sockets, and the only thing the client has to maintain is a single socket to the ISP's accellerated proxy. This cuts out that additional TCP overhead.
• Smart caching. These systems usually maintain a seperate cache from the browser. This cache is smart. It rates documents based on the frequency of download, and removes those that aren't often viewd, while preloading highly viewed images and documents into memory on load to increase performance.
• And finally, ridiculous compression rates, the natural evolution of the good ol' v.42 related standards.

The first two require a proxy server setup, the second two are just plain good ideas that haven't made it into the wild. For example, the smart cacheing could be implemented by Moz, or even by a Firebird extension. The last could be handled by a certain standards body implementing much more aggresive changes in terms of compression instead of features like the ones introduced in the v.92 standard.

Re:Well, actually . . .

[erikharrison]

Damnit! Replying to myself. I forgot about the coolest feature. The proxy checks for inline ads by a similar algorithm that Moz uses, and removes them. Not only are the ads gone, but since it is server side, it cuts down on download size.

I have first hand experience with this....

[eyeareque]

I work for a wholesaler in the western united states..

In test trials 2-3x is the average seen. 5x does happen, and so does 9x from time to time. ...and to the claim that it requires a client? that is not true. (blatent plug http://www.pacwest.com/dialbroadband/) this wholesale solution for ISPs is clientless.

compression with PHP

[mboedick]

If you have a recent version of PHP, you don't even need mod_gzip. Just put the following lines in your .htaccess file:

php_flag zlib.output_compression on

Does everything on the fly. I once had a shell script that would wget a url with the accept encoding gzip header, and then wget it again without and show the percent savings. Was fairly interesting to see what sites were using compression, and what sites that weren't could have saved in bandwidth by using compression.

Congratulations: you're clueless.

[Jerk City Troll]

In my experience, standards-compliant HTML is *less* space-efficient than ad-hoc HTML. Compare

font size="+1"
vs.
font size=+1
or the extra trailing slash on atomic tags, or /p tags (which you can pretty much omit entirely without confusing any browsers).

Wow. I've never encountered anyone who has spoken so confidently on a topic without knowing a damn thing about it it. You are so absolutely wrong that the example you gave is the exact oposite of what you think it is. You've demonstrated precisely what not to do when writing good markup.

I don't even know where to begin to correct your cluelessness. Here it goes...

When I talk about writing good markup, I'm speaking a purely structural sense. In otherwords, markup text based on what it is, not what it looks like. Separation of content from presentation is the principle to follow.

For example, this is bad HTML:

...
<p><font size="12pt">Header</font>
<p><font color="navy">We're going to list some <i>items</i>.</font>
<p>Here 's a list:<br>- Item 0<br>- Item 1<br>
...

That's bad for many reasons.

1. The font tag eliminates the user's ability to define their own visual style for the page. One of the central reasons for writing structural markup as opposed to presentational markup is so that the user, not the author, has final say on what the page will look like. From time to time, users will supply their own stylesheet to help with readability. If there is no structural nature to the markup, or it defines appearance, the user is defeated. A web developer also has to keep in mind that the browser makes NO guarantees about how something will be rendered.
2. No computer system could interpret that markup and understand *what* it was. What's paragraph text? What's a list? What's a header? What text has emphasis on it? There would be no prioritizing of the text. This defeats search engines and screenreaders (for the blind). Basically, there is nothing about that markup which is machine readable.
3. Changing the visual style of this context requires someone to go and edit the markup. Now what if the visual style was defined in the markup across 1000 pages. That's 1000 complex changes that must be made.

Now, here's good HTML:

...
<h1>Header</h1>

<p class="P0">We're going to list some <em>items</em>.</p>

<p class="P1">Here's a list.</p>

<ul>
<li>Item 0</li>
<li>Item 1</li>
</ul>
...

And then a stylesheet:

h1 {
font-size: 12pt;
}

p.P0 {
color: navy;
}

p.P1 {
color: black;
}

Now, the user can easily define what stuff should look like based on what it is. A user could supply a stylesheet that increases the size of paragraph text by a percentage. A user could specify their own margins for list items. A user could eliminate colors or adjust contrast to their liking.

On top of that, a machine can read that markup and know precisely what it is. This is a header, that's a paragraph, this is a list, etc. A search engines and screenreaders would know precisely what to do with the text.

Furthermore, the styling data is in one location, so if you have 1 or a 1000 pages, the work is the same to make them look different.

Of course, this is only the tip of the iceberg. If you use XHTML and CSS properly, you get more visual flexibility than otherwise. (This also implies discarding tables for use in layout in favor of layers. Tables are for organizing tabular data, not positioning things visually.) XHTML also gives you forwards c

Re:For a few dollars more . . .

[wishlish]

I have numerous relatives, older people, that had broadband but went back to dialup over the cost. In my apartment complex, DSL is not feasible due to the age of the phone lines, so we must use the Comcast monopoly- $50/month. Juno is around $10/month- even AOL is $23/month, half the cost of broadband.

Obviously, using broadband makes sense at a certain point of usage. But if you're not using the Internet more than, say, 2 hours a week, the economics just doesn't make sense. So there is value in dialup web accelerators, especially software that's easy for those who are technically challenged.

Mod this down overrated.

[pr0ntab]

For the most part, gzip IS, in fact, the alpha and omega. gzip is king on byte-oriented data (it doesn't matter what size the words are, it's a nth-order entropy encoder, so they all turn into pseudo-symbols).

The types of data that can be specialized are much fewer than you propose.
For example, bzip: better suited for text as text has a lot of localized second order trends. However it is computationally intensive and may not do well on a server appliance over multiple connections.
PNG is better on (many) raster images since it exploits 2-dimensional relationships recursively. But it requires the source image to be uncompressed first. JPEGs might already be compressed, and that would make them larger. But recompressing JPEGs (which is the big step these proxies take) is someone of a hack since we didn't really ask for it, and it may look like shit in the end.

And forget video or audio. There's nothing you can do about it (in realtime anyway...).

If and when SVG and other XML-based content formats become prevelant components of websites, then gzip/bzip on the fly will become very useful in making sites small, fast but content-rich.

PDF and flash are already compressed heavily, so they don't need it. Java programs come in .jar files (pkzip)

And mozilla has browse-ahead built in.

So I don't really buy any of this. If I still had dialup, I'd rather them just be upfront, let me control MY upstream cache settings/content, and forget all the fancy software, because most of it is redundant. That part about the cache is the key thing, because that's what you're really paying for, and they should let you control how it's used.

Speed up your site and cut bandwidth use right now

[ChaosDiscord]

One step most of these proxies is doing is compressing HTML files. HTML is highly redundant, so compression can save alot of space. However, it's silly for the proxy to do the compressing. Instead web site owners can do the compressing! Transferring pages gzip compressed is part of the standard. No special software is needed by end users. A 3:1 reduction in bytes transferred for your web pages (the HTML itself) is a reasonable minimum. The result is that you use less bandwidth and end users get a faster web site! Every mainstream browser supports this, and those browsers that don't support it will automatically get the uncompressed version. If you're using Apache, you'll want mod_gzip to automatically compress transfers. (You can fake the effect with MultiViews, but it's a hassle to maintain two copies of every HTML file.)

(Yes, I know I don't practice what I preach. I'm working on it.)

Why is this limited to dial-up?

[kinema]

People keeps saying that this technology is pretty much moot as more and more people are getting broadband connections. Why should compression and caching technology only be applied to slower connections? Why waste any amount of bandwidth even when you have "tons" of it?

Free software for faster browsing

[Ed Avis]

I use a modem for web browsing. I've found that wwwoffle is a good proxy server, because it can operate in both online and offline modes - when offline, it serves the most recent version of each page, and if you try to view a non-cached page, it's marked to be downloaded next time you connect. If you want to speed up your browsing some more at the expense of having to hit 'reload' occasionally, you can configure wwwoffle to always use an available cached version even when online.

If you have a shell account on another machine, and that machine has access to a proxy server, then you can tunnel port 3128 or 8080 (common http proxy ports) through ssh. This makes browsing a lot quicker because there is only a single TCP/IP connection going over the modem link - you don't have to connect separately for each page downloaded. Unfortunately I found that while this gave very fast browsing for half an hour or so, eventually it would freeze up and the ssh connection would have to be killed and restarted. Perhaps this has been fixed with newer OpenSSH releases.

RabbIT is a proxy server you can run on the upstream host which compresses text and images (lossily).

The author of rsync mentioned something about an rsync-based web proxy where only differences in pages would be sent, but I don't know if this program was ever released.

MS does this already on any connection

[milosoftware]

If you and your ISP both use a Windows system, turning on "software compression" (and don't forget to turn off the modem's hardware compression) basically gives you mod_gzip on ALL your incoming AND outgoing data.

A drawback used to be that the server at the provider side was often overloaded, so I set up several "accounts" to switch between hard- and software compression with and without proxy. Now that my ISP is no longer "free", I haven't seen the server become overloaded any longer, so I use software compression and their proxy all the time. HTML and text download at 20kB/s over a 48kbps connection. Off course, there's no gain in already-compressed content like images and audio.

Evil...

[SharpFang]

Harvest all the links on a webpage, cache them on disk while you view the page content, if you still don't go anywhere, harvest links on the cached pages, and so on. If you type some URL and go elsewhere, discard everything.
Results for you: You click on a link and you have it immediately - from harddisk cache.
Result for others: A major part of the bandwidth is wasted, everyone's connection gets slower.
Effects: Everyone installs accelerators to have the net working faster. Bandwidth usage jumps 10 or so times, prices rise, connection speed drops far below what was before the accelerators. Nobody gives up the evil accelerators because without them it goes even slower.

It's called "social trap".

rproxy (rsync)

[Lennie]

From one of the articles:
The idea is to store Web pages on your hard drive upon your first visit to the pages, and then to limit the information you download on subsequent visits to those pages to only the data that changes, making for a faster download.

Makes me think about: http://rproxy.sourceforge.net/.

R T F M

[DrSkwid]

Here's a fucking hint

http://sourceforge.net/projects/mod-gzip/