The main reason why Tor currently has bad performance is that it multiplexes multiple circuits (and therefore the streams in those circuits) under the same TLS(TCP) connection. This is very important from the security perspective, but causes problems when any link in the circuit that you chosen is under congestion. When a link is under congestion, packet drops in that connection will make the TCP connection to slow down (tcp transforms reduced bandwidth into latency). Thus if only one stream is of heavy traffic, the latency of all other streams that share that connection will be increased. It is now known that bulk traffic accounts for >40% of Tor's exit traffic (It is impossible to estimate hidden traffic) thus there is a very high probability that you are sharing the connection with one of those streams. Further if there are any hosts in you circuit that do not use TCP extensions for high bandwidth-delay products (windows machines have this options disabled by default), this 'side-effect' would be increased.
To test this, even on a 'fast circuit' try making 2 bulk downloads while simultaneously browsing.. the latency of the browsing will be abysmal, even tough the total throughput is ok. Currently, there are two research paths to solve this on Tor : A proposal by Joel Reardon that creates per circuit and hop userspace TCP stacks for each circuit and a proposal by Camilo Viecco (myself) to use a single TCP session for active each stream from the application at the client to the exit node. There is running source code (and a running network) for my proposal mostly as a Proof on concept (that is ,the network is really small, ,the code is still not ready for production, is not available as binaries, nor compiles in windows machines (only linux, and osx)) but that you can use now for testing purposes. To download from the public svn repo: 'svn checkout */http/*://tdor.googlecode.com/svn/trunk/ tdor-read-only'/ . This code illustrates that you can have low latency while keeping anonymity. I would love to hear more from testers, but I will restate the caveat : this network provides very little anonymity as I am in control of all of the infrastructure (And why would you trust me). I am very confident that some solution to the latency will be available in Tor in the next two years, but for now we have to live with this Camilo PS. The paper with the traffic statistics is available here: http://www.cs.washington.edu/homes/yoshi/papers/Tor/PETS2008_37.pdf Dominik Schaefer wrote: > Alessandro Donnini schrieb: > >> True, I did take that into account. I could be mistaken but I think the main >> problem lies with the proxy software. >> > I seriously doubt that. But you can check that if you use > Polipo/Privoxy, but not Tor. > > Dominik > >