A compressing proxy is something fantastic for low bandwidth and/or high latency mobile browsing.
Is the source code available so I can run the proxy on my own private server?
If not, here are some open source alternatives that I have used:
http://en.wikipedia.org/wiki/Ziproxy
https://wiki.mozilla.org/Mobile/Janus (written in Node.js)
It is a pain that papers themselves https://static.googleusercontent.com/media/research.google.c... no longer carry the date of publication.
Interesting they felt the need to add:
> The majority of Flywheel code is written in Go, a fact we mention only to dispel any remaining notion that Go is not a robust, production-ready language and runtime environment.
Using it even on desktop Chrome while using a data limited surfstick https://twitter.com/therealmarv/status/592303381093425152 Chrome extension: https://chrome.google.com/webstore/detail/data-compression-p...
I think this is comparable to Opera Turbo, which also runs on iOS and Android. Opera Mini stripping gives even better compression but breaks js apps / complex sites. There is a russion reverse engineered firefox plugin which enables Opera Mini support on desktop operating systems. The Opera Mini server is not commercially available or open source las time I checked. I wonder if and how a PPM based compression proxy would be doable and if it improves existing browser compression support like opera turbo, mini or the google chrome solution.
I once was somewhere where there was only an abolutely minimal wifi connection with a latency and very low bandwith ( < 1 KB/s. Opera mini was still slow but worked wonders, where a regular browser was basicly unusable.
50% savings is not enough, for me, to justify the MITM. I would rather have data sovereignty than data bandwidth at this tradeoff.
I suppose the paper would show a substancial latency reduction would they select high latency networks for sampling.
I guess that on a satellite network (~600ms), latency would be greatly reduced as there is only one (and persistent) TCP connection to the proxy, with HTTP2 (or SPDY) over that (using http2 multiplexing capabilities).
This one tcp connection will be fully established and with a full tcp-window basically the whole time. The TLS with be fully negotiated and setup. Leaving the client with an optimized tunnel to google servers.
Considering that most latency on the path is on the satellite part, and google servers are on the other side of it, tcp handshakes and ssl setups to destination servers will occur on that low-latency side. Google will just push those optimized content over the tunnel to clients.
Looks like paradise.
TL,DR: Satellite clients won't open 4 connections to servers and wait for 4 tcp handshakes and slowly open those 4 connections tcp-windows for every site visited. They will open one connection to google server (on the other side of satellite) and let google do the hard work. High-latency paradise!
Seems remarkably similar to what Opera was doing with the Opera Mini, though not quite as intrusive.
I remember really appreciating how quickly pages rendered on that browser, compared to the stock chrome when I was using android.
"HTTP proxy service that extends the life of mobile data plans by compressing responses in-flight between origin servers and client browsers."
so this is part of the google mobile strategy.
"Flywheel is integrated with the Chrome web browser and reduces the size of proxied web pages by 50% for a median user."
is there any implementation of this outside chrome, OS?
> Flywheel compresses all text responses using GZip.
Since this is for Chrome only, I'm surprised they don't use the other possible compression format: zlib (confusingly named deflate in the RFC). It's 12 bytes less and uses a faster to compute ADLER32 checksum, compared to CRC32 in gzip.
I went to an interview at a startup a year or so ago who were doing this, they sold it as a service to corporations to help cut the cost of employees using too much mobile data along with other security features etc
Interesting idea I guess.
but what's their weisman score?
Are there still that many websites which has not enabled gzip to make this kind of proxy worth it? Enabling gzip is trivial.
For similar products today: CloudFlare and Instart Logic have capabilities to do this.
Sure does feel like https://www.onavo.com was at least taken as inspiration for designing this system.
Or is this simply a service to spy on what people are browsing so that they can improve PageRank?
The paper states that although data use is reduced by 58% on average, the page load time is increased by 6%. Smaller pages are typically slower to load though Flywheel however large pages actually load faster.
They do lots of interesting things beyond gzip. They convert images to WebP and scale the resolution of the image based upon the resolution of the host device. They also minify CSS and HTML. What I noticed which I thought was quite cool was they add ETag headers to improve the client's ability to cache resources.
They rewrite the response headers to lower case to increase the effectiveness of compression and of course everything is served over SPDY (except in special cases where that fails)