Hacker News Reader

Hacker News

Comment by treeman79 | Hacker News Reader

Full thread

treeman79

Back in BBS days I downloaded a utility that doubled connection speed. Skeptical but highly board, I tried it.

And to my astonishment it worked!

A few minutes later, “the clock seems to be running really slow”

Clever program. Half speed clock makes all download speeds show double speed.

View on HN

I recall a utility that proxied all requests through another server, and compressed assets (eg large images) down on the fly on the server- so the end client used much less bandwidth to load a heavy web page.

It worked quite well and I think some ISPs offered it out of the box in the end

I might be remembering this totally wrong but didn't a mobile browser (maybe Opera?) offer this feature as well, like 5 or 10 years ago? I seem to remember trying it out for my Android phone back in the day

Yeah opera did this, I remember being amazed at the results in my Nokia e71 - and viewing the desktop site rather than the terrible 201) mobile offerings, but getting great speeds due to the compressed sizes.

Same! Can't remember what it was called, but there was a Java application I used 15 years ago that proxied HTTP and compressed assets, which was useful in New Zealand at the time because bandwidth was limited and not as fast(I'm sure that's changed by now).

This is what an app called Onavo did. Facebook bought them in order to spy on what people were doing with their phones.

https://en.wikipedia.org/wiki/Onavo

I used their compression VPN before Facebook gobbled them up. It worked pretty well.

Google Web Accelerator [0] did this. Requests were pricked via Google. A side effect of this was that you could access internal Google tools that had been restricted to Google's IP address range – oops!

[0] https://en.wikipedia.org/wiki/Google_Web_Accelerator

That sounds like Squid + data compression proxy. I think I set it up a while back and was impressed by how well it worked.

https://gist.github.com/mayli/7d07c5e2913f9d45f3d6a5b122b797...

One company that I worked at used a NetLi (now part of Akamai). The approach that they used (IIRC) had multiple data centers closer to the end users and then a server in each client's datacenter. The server in the client data center and the servers in the edge data centers would establish a pre-negotiated connection that had its TCP parameters optimized for its traffic... and then serve compressed traffic over that connection.

It was pretty impressive back in the days of CGI and JSP - before the presentation was pushed entirely out to the browser and everything was rendered on the server.

Are images not already compressed and always have been on the web?

Compressing an already compressed image will surely not do much.

Compression in the context of (jpeg) images often implies lossy compression. You can apply that multiple times ans still gain size benefits. Other ways are stripping metadata and reducing color palettes. Images on websites are often horribly unoptimized, so if you’re willing to compromise a little on quality you can have substantial gains in bandwidth requirements.

Opera Mini did (and apparently still does) that.

IIRC the proxy server does way more than just compress assets, it re-encodes the page to an internal binary markup format, and handles restricted JS execution with a simplified interaction model (the client had all of 4 events: unload, submit, click, and change, these events would trigger a server call which executes the corresponding handler and sends the updates back).

Not everything worked on that thing (most obviously the complex web applications which were starting to crop up around that time), but it was absolutely magic on unreliable GPRS connections 15 years ago.

Opera mini on my blackberry made the gprs connection usable 15 years ago

The client was actually even simpler than that, it was just clicks. Doing anything else wasn't practical with the average latency back then.

The rest was done on the serverside using the old Opera Presto core - which scaled very economically, since it had gone through a lot of memory optimization efforts when it was ported to early smartphones/japanese weirdphones. We needed to keep the users's browser "tabs"/windows around until the next click, potentially a few minutes away, so memory usage was a key economical concern at the time.

I ran the product/development team from early on until 2014. Glad you liked it. Opera Mini peaked at about 150M monthly active users in like 2012-2013 or so. Since then I'm sure it's been a steady decline. If I were to guess right now, I'd say they new Chinese owners maybe will keep it alive for another 5-7 years, but who knows, they seem to be really focusing on Africa.

I used to use their proxy to bypass every web filter I ever came across haha. Ta for introducing me to the whack a mole that is bypassing porn filters, Opera! Sorry I never used your browser as intended

I remember AOL (circa version 3 or 4) doing this. If you saved one of these (maybe by normal means, or maybe only by poking through the local cache) they'd have an .art filename extension and be some proprietary format that wouldn't load in most image software.

Browsh [1] offers similar functionality via SSH.

[1]: https://www.brow.sh/

I think I know the logic behind this, but could you clarify/confirm it?

In this case download speed is based on your system's clock. For example, 1 minute on your system takes 2 minutes real time. Therefore, your computer thinks downloads finish in half the time it takes in reality.

Let’s say you normally could download 10 kilobytes in a minute. If your computer clock slowed down by half, the kilobytes would download at the same speed, but only 30 seconds would have passed in computer time, so the computer would calculate that you had downloaded 10 kilobytes in 30 seconds, or 20 kilobytes a minute. Really, a minute passes, not 30 seconds, but the computer doesn’t know

Reply on news.ycombinator.com