Am 21.01.2012 15:39, schrieb [email protected]: > I see three different ways to compress traffic. 1), 2) and 2) They could > be all implemented alone or all in combination. > > 1) website compression > Long time ago I tested services like traffic compressor (a free legitimate > public proxy). It really enhanced the speed, especially websites with lots > of high quality pictures.
According to Andrew Lewmann lot's of stuff is already compressed. He also says, bandwidth isn't the problem, CPU is the critical resource. > The exit server would hook into all outgoing unencrypted http connections > and compress the website using a similar mechanism like services like > traffic compressor. An option to opt-out or opt-in this feature for the > exit and the Tor-user would be needed as well. That would add CPU load to the exit, which hurts the network because the exit can't handle that much onion-skins. > 2) caching proxy > Just like existing caching proxys. The exit server would safe bandwidth if > they wouldn't always request all websites fresh but use a local cache. > Also option for both, Tor-user and exit server if they wish to use the > feature. That could indeed save bandwidth, but only for popular sites. The cache would have to be refreshed from time to time. Also this would require space for the cached files. I'm sure that this would work. This has nothing to do with compression IMO, just saving bandwidth. You could post it as separate idea. Keep in mind that the torproject knows it's requirements and that bandwidth doesn't seem to be the problem. I'm not sure if that would be used. When I'd use Tor for anonymity I wouldn't want something to store anything on my behalf. ON the other hand, when the website doesn't need to be fetched from it's original server it might be harder to monitor for an adversary. > 3) connection compression >>From Tor-user to exit server. > - it would put more cpu load on the Tor-user, but he could get an option > if wants to use compression or not Yes, in my case the user requested compression if he could handle the decompression, the sever could opt in or out. > - it would put more cpu load on the exit node as it would have to > uncompres the date before sending it to the target server The problem is that it causes that extra CPU load the exit can't afford. > - therefore also the exit nodes could get an option if they accept > compressed connections or not, if they want to safe cpu load That's included in mine as well, but the majority of exit are already overloaded, so they would have to opt out, which makes compression requests useless, because those won't be honored. > - this method of compression would put less load on the entry and middle > nodes That was what I had in mind, but to quote Andrew: "What tor does in the middle is irrelevant." (in terms of compression, because it's already compressed) Regards, bastik_tor _______________________________________________ tor-talk mailing list [email protected] https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-talk
