Changes between Version 74 and Version 75 of doc/FireFoxTorPerf


Ignore:
Timestamp:
Apr 23, 2010, 4:47:55 AM (9 years ago)
Author:
trac
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • doc/FireFoxTorPerf

    v74 v75  
    33== Introduction ==
    44Tor is known for being secure but slow. If you want to improve browsing speed a bit, please follow the following simple instructions for tweaking the Firefox web browser's settings:
    5 
    6 == Table of contents ==
    7  * Procedure 1
    8  * Advanced Tuning of Tor
    9  * Advanced Tuning of Polipo
    10  * Advanced Tuning of Privoxy
    11  * Advanced Tuning of Windows
    12  * The proof is in the pudding, results
    135
    146== Procedure 1 ==
     
    2113network.http.pipelining.maxrequests:8 (No default)
    2214network.http.proxy.keep-alive:true (Default- true, but double check)
    23 network.http.proxy.pipelining:true (Default- false) - See NOTE1 below.}}}
     15network.http.proxy.pipelining:true (Default- false) - see Proecedure 2 below.}}}
     16Afterwards, just restart the browser and experience the difference! For some automated additional performance hacks, check out [http://www.totalidea.com/freestuff4.htm FireTune]. Currently, Fire{{{}}}Tune is only for Win32, but you can do the same tweaks manually with the help of [http://www.tweakfactor.com/articles/tweaks/firefoxtweak/4.html this page].
    2417
    25 Afterwards, just restart the browser and experience the difference! For some automated additional performance hacks, check out the [[https://addons.mozilla.org/firefox/addon/1269|FasterFox extension]]. You also can do the same tweaks manually with the help of [[http://www.tweakfactor.com/articles/tweaks/firefoxtweak/4.html|this page]].
     18== Procedure 2 - an update and addendum to Procedure 1 ==
     19These results were arrived at empirically, using the win32 bundle, Tor & Privoxy & Vidalia bundle: 0.1.2.5-alpha
    2620
    27 NOTE1: Proxy pipelining may not be well supported by Privoxy. For this reason, you may want to install [[http://www.pps.jussieu.fr/~jch/software/polipo/|Polipo]] and use that instead of Privoxy to get the performance benefits of pipelining. If you use [[https://torbutton.torproject.org/|Torbutton]] (which you should, if you want [[https://www.torproject.org/torbutton/design/#attacks|any anonymity at all]]), all of the Tor-relevant privacy scrubbing features of Privoxy are no longer necessary.
     21 * [https://torbutton.torproject.org/ Tor Button]
     22 * [http://https://addons.mozilla.org/en-US/firefox/addon/4420 Configuration Mania for Firefox]
     23 * [http://www.speedguide.net/downloads.php TCPOptimizer (win32)]
     24 * [http://www.speedguide.net/read_articles.php?id=1497 Event ID 4226 Patcher (win32)]
     25 * DNS Latency
    2826
    29 NOTE2: Do not use page prefetching. Disable this if it is enabled. Prefetching is a speculative feature, which assumes that you will read the pages referenced by the links in the current page you are viewing. This places undue load on the Tor network and clog your circuits with unnecessary traffic. Its unlikely you will read all the pages referenced by the current page, especially in the case of search engines results.
     27=== Tor Button - enable / disable Tor access in FireFox ===
     28This provides an optional button or text in the bottom right of the browser window in Firefox. This allows you to switch Tor on and off.
    3029
    31 === Using Polipo Proxy (example assumes Windows - adjust accordingly) ===
    32 Polipo as a proxy instead of Privoxy has been discussed in some places online, with reports that it is more performant.
    33 To use this proxy:
    34  * Install Polipo to the default location
    35  * Set Vidalia's Proxy application to:
    36     'C:\Program Files\Polipo\polipo.exe' - without quotes.
    37  * Set Vidalia's Proxy application arguments to:
    38     -c "C:\Program Files\Polipo\config"
     30=== Configuration Mania - Modify performance related settings in FireFox ===
     31This plugin modifies the networking and cache settings for Firefox. When you load Configuration Mania, select the HTTP Network settings tab.
    3932
    40 You will not see a shell window for Polipo, but the process will be created and visible in the Task Manager. Check the process exists to assure it is working correctly.
     33    * Tor may perform better with HTTP1.0 over HTTP1.1. Its worth experimenting with this setting. It is claimed that some proxies and firewalls do not work well with HTTP1.1, but it may be ascertained empiracally, through experimentation, which is best.
     34    * Tor may or may not work well with HTTP1.1 pipelining. Ensure pipelining is disabled (default) for proxy connections. There is some confusion over this setting, which a cursory search will reveal. [http://www.google.co.uk/search?q=firefox+pipelinening&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-GB:official&client=firefox-a Search on Firefox Pipelining]
     35    * Tor may or may not not work well with Persistent HTTP connections. Ensure this option is disabled for proxy connections. Again some confusion abounds as a cursory search reveals [http://www.google.co.uk/search?q=firefox+keep-alive&ie=utf-8&oe=utf-8&aq=t&rls=org.mozilla:en-GB:official&client=firefox-a Search on HTTP Keep-Alive]. In any case, there may be issues with decreased anonymity with persistent connections.
    4136
    42 == Advanced Tuning of Tor  ==
    43 If you follow the previous authors work you should have well performing access. To go that bit further lets consider the ideal behaviour of our Tor client.
    44 
    45 You will need: [[https://www.torproject.org/tor-manual.html.en|The on-line reference to Tor properties, that can be placed in torrc.]] Always back up this file before editing.
    46 
    47 === A Tor Non-Functional Requirement (NFR) ===
    48 Lets think of a Non-Functional Requirement we might like to place on our Tor client.
    49 
    50  * we want it to establish circuits as quickly as possible. If it takes too long to do this ignore them, by timing out the building of circuits quickly.
    51  * now we have circuit build time-outs occuring more frequently, we need to encourage Tor to try to generate circuits more often.
    52  * Once we have established a circuit, we are assuming its a good one and we dont want it being timed out by firewalls or anything else. We need to make sure a ping occurs on the circuit to prevent this.
    53 Given this NFR, lets come up with some properties that may help satisfy it.
    54 
    55  * CircuitBuildTimeout NUM
    56   . Try for at most NUM seconds when building circuits. If the circuit isn't open in that time, give up on it. (Default: 1 minute.) Force circuits that are quick to establish and thus likely to push traffic more quickly. Values as low as 2 seconds have been tried with good results, although this can cause severe damage to the Tor network if your network connection is simply not fast enough to establish any circuits in this time. The effect is a smaller 'Topological Radius' of servers used for Tor, ie the network connections available from your connection. Unfortunately, the smaller you make this number, the smaller the number of paths your client will use, and the less your anonymity.
    57   As of Tor v0.2.1.9-alpha, the CircuitBuildTimeout has been clipped to 30 seconds, which affects some of the tuning recommendations here. From the release notes:"
    58   ''Clip the CircuitBuildTimeout to a minimum of 30 seconds.
    59   Warn the user if lower values are given in the configuration.
    60   Bugfix on
    61   0.1.1.17-rc. Patch by Sebastian.''"
    62  * NumEntryGuards NUM
    63   . If we are going to be decreasing the CircuitBuildTimeout, you want to increase the likelihood you have a guard node fast enough to build these fast circuits for you. NUM=5 to 8 are good choices here.
    64  * KeepalivePeriod NUM
    65   . To keep firewalls from expiring connections, send a padding keepalive cell every NUM seconds on open connections that are in use. If the connection has no open circuits, it will instead be closed after NUM seconds of idleness. (Default: 5 minutes)
    66  * NewCircuitPeriod NUM
    67   . Every NUM seconds consider whether to build a new circuit. (Default: 30 seconds) Lets make Tor ready to establish a new circuit more readily.
    68 
    69 Settings that you may append to the end of the torrc configuration file are as follows:
    70 {{{
    71 # Try for at most NUM seconds when building circuits. If the circuit
    72 # isn't open in that time, give up on it.
    73 # (Default: 1 minute.)
    74 CircuitBuildTimeout 5
    75 
    76 # Increase the number of guards to increase the likelihood that
    77 # you will have a few guards fast enoiugh to build these circuits.
    78 # (Defaults to 3.)
    79 NumEntryGuards 6
    80 
    81 # Send a padding cell every N seconds to keep firewalls from closing
    82 # our connections while Tor is not in use.
    83 # (Default: 5 minutes)
    84 KeepalivePeriod 60
    85 
    86 # Force Tor to consider whether to build a new circuit every NUM
    87 # seconds.
    88 # (Default: 30 seconds)
    89 NewCircuitPeriod 15
    90 }}}
    91 
    92 As an added bonus, with these settings the "New Identity" button in Vidalia also effectively becomes a "This circuit is WAY too slow" button that you can mash to get a faster, more responsive circuit if Tor ever starts choking up on you. This is necessary because sometimes circuits will start out fast, but then get overloaded as traffic from other clients bursts and overwhelms the slowest node in the path.
    93 
    94 ----
    95 == Advanced Tuning of Polipo ==
    96 Within Polipo's config file, add the following parameters at the top:
    97 {{{
    98 pmmFirstSize = 8192
    99 pmmSize = 2048
    100 socksParentProxy=localhost:9050
    101 proxyPort=8118
    102 disableVia=true
    103 censoredHeaders=from,accept-language,x-pad
    104 censorReferer=maybe
    105 allowedClients="127.0.0.1"
    106 diskCacheRoot=""
    107 localDocumentRoot=""
    108 logFile="/polipo.log"
    109 serverSlots=2
    110 serverMaxSlots=4
    111 dnsNegativeTtl=0
    112 chunkHighMark = 50331648
    113 objectHighMark = 16384
    114 }}}
    115 
    116 The settings above enable Polipo to replace Privoxy, but still enables the Tor toggle button to operate, if you are using the Tor FireFox plugin.
    117 
    118 
    119 == Advanced Tuning of Privoxy ==
    120 Privoxy is set to be a 'straight-through' proxy server, with the toggle switch. Its buffer is reduced to below that of RWIN. This is because RWIN represents the largest TCP receive window. Its value is chosen to be above Tor default socks size = 252KB
    121 ||Privoxy||config.txt||
    122 || -- || -- ||
    123 ||Privoxy:buffer || 265 (KB)||
    124 ||toggle || 0||
    125 
    126 == Advanced Tuning of Windows ==
    127 This section has been included last for those who are technically capable.
    128 
    129 === Processor Scheduling (win32) ===
    130 Windows enables the program running in the foreground to have heightened processor resources. If this option is switched to 'Background Processes', Tor appears to return consistently higher performance. This option can be found in 'My Computer | Right click | Properties | Advanced Tab | Performance Settings | Advanced tab again.
     37NOTE: Do not use page prefetching. Disable this if it is enabled. Prefetching is a speculative feature, which assumes that you will read the pages referenced by the links in the current page you are viewing. This places undue load on the Tor network. Its unlikely you will read all the pages referenced by the current page, especially in the case of search engines results.
    13138
    13239=== TCPOptimizer -  2K/XP's throughput (win32) ===
    133 Windows XP has a self-tuning IP stack, but it can still benefit from a little help. Using the TCP Optimiser tool from above you can tune the MTU, RWIN, SACK OPTS (rfc 2038), and tcp1323opts controlling window scaling. The tool has one button optimise. This setting is sufficient to benefit from immediate increases to Tor throughput. To increase throughput further you can try experimenting with lower values of the IP TTL (Time To Live). Values as low as 32 will work and result in improved performance. Also try experimenting with smaller TCPWindowSizes. This setting is automatically adjusted when you move the slider marked 'Connection Speed' of the TCPOptimizer  tool.
     40Windows XP has a self-tuning IP stack, but it can still benefit from a little help. Using the TCP Optimiser tool from above you can tune the RWIN, SACK OPTS (rfc 2038), and tcp1323opts controlling window scaling. The tool has one button optimise. This setting is sufficient to benefit from immediate increases to Tor throughput. To increase throughput further you can try experimenting with lower values of the IP TTL (Time To Live). Values as low as 32 will work and result in improved performance. Also try experimenting with smaller TCPWindowSizes. This setting is automatically adjusted when you move the slider marked 'Connection Speed' of the TCPOptimizer  tool.
    13441
    135 ||Windows||in TCP Optimizer||
    136 || -- ||-- ||
    137 ||RWIN|| TCPOptimizer max setting||
    138 ||MTU|| 576, 1500 or 1492 - try all 3 settings||
    139 ||Window Scaling|| On||
    140 ||TcpIP TTL || 128 (hops)||
    141 ||LANBufferSize || 65535 (bytes)||
     42Use '''''ping -f -l NNN www.google.com''''', on Windows, to find your maximum MTU (Maximum Transmissionn Unit), where NNN represents the largest integer value for the size of your MTU BEFORE fragmentation occurs.
     43This could vary between PPPoE (3G Cards) and PPPoA (ADSL Broadband). Use the smallest of any RWIN value you find, to cover all your potential types of connection to the net. The value should be around 1472, so start testing at around this value, moving the value higher until the packet fails delivery due to the requirement to fragment it.
    14244
    143 You can view your connection parameters and their effects on your connections, both with Tor and without Tor, at [[http://www.dslreports.com/tweaks|DSLReports]]
     45You can view your connection parameters and their effects on your connections, both with Tor and without Tor, at [http://www.dslreports.com/tweaks DSLReports]
    14446
    14547=== Event ID 4226 Patcher - Remove the limit on TCP connection attempts XP SP2 (win32) ===
    146 [[http://www.speedguide.net/read_articles.php?id=1497|Remove the limit on TCP connection attempts]] SpeedGuide.net has an interesting article detailing this restriction introduced in XP SP2. Microsoft have restricted the amount of half-open TCP/IP connections with the proviso that it would reduce the pace that worms spread. As noted by SpeedGuide, internet worms spread isotropically (multi-directionally) and so their infecton rate is exponential. As such, placing a constant (limit) on the rate of connection creation for every computer running XP SP2 will slow the rate of worms spreading (for that group of computers) but not by much. Consider the population of humans on the planet. Its over ~6 billion.
     48[http://www.speedguide.net/read_articles.php?id=1497 Remove the limit on TCP connection attempts] SpeedGuide.net has an interesting article detailing this restriction introduced in XP SP2. Microsoft have restricted the amount of half-open TCP/IP connections with the proviso that it would reduce the pace that worms spread. As noted by SpeedGuide, internet worms spread isotropically (multi-directionally) and so their infecton rate is exponential. As such, placing a constant (limit) on the rate of connection creation for every computer running XP SP2 will slow the rate of worms spreading (for that group of computers) but not by much. Consider the population of humans on the planet. Its over ~6 billion.
    14749
    14850Supposing all these people are running Windows XP SP2, with rate limited half-open connections. Rate limiting is set to 10 half-open connections per second. To infect the entire population of computers would take: We are assuming optimum forward infection here. In the first second we have infected 10 machines. The 2nd second to elapse will cause (10 x 10) + 10 = 110 computers to be infected. The 3rd second to elapse would cause:
     
    15759Use the Event ID 4226 Patcher to mitigate against this.
    15860
    159 === DNS Catching time ===
    160 Reducing DNS caching time reduces the risk of an invalid DNS resolve, given Tor servers may be operating in a DHCP environment that updates the IP each time the network connects.
    161 ||Windows||registry:TCPIP service||
    162 || -- || -- ||
    163 ||DNS Cache || 36000(seconds (10 hours)) set in registry by hand, HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters||
     61=== DNS Latency - Reducing Latency ===
     62You can use [http://www.opendns.org OpenDNS] to reduce your DNS latency for all operating systems.
    16463
    165 == The proof is in the pudding, results ==
    166 With the changes made from Procedure 1 and 2, and a 2Mb connection, you can realise a sustained throughput of >100k, peaking at ~256k or more, with a ping response time of between 250 and 900ms. In other words, experimentation away from default settings, should enable you to saturate your internet connection (depending on Tor node capacity), which is the ideal result. All results tested under Tor v0.1.2.7-alpha(r17216)
     64== Procedure 3 - A Tor NFR (Non-Functional Requirement) ==
     65If you follow the previous authors work you should have well performing access. To go that bit further lets consider the ideal behaviour of our Tor client.
    16766
    168 These figures were arrived at by using [[http://speedtest.net|SpeedTest.net]]
     67You will need: [https://www.torproject.org/tor-manual.html.en The on-line reference to Tor properties, that can be placed in torrc.] Always back up this file before editing.
    16968
    170 CategoryHowTos
     69Lets think of a Non-Functional Requirement we might like to place on our Tor client.
     70
     71 * we want it to establish circuits as quickly as possible. If it takes too long to do this ignore them, by timing out the building of circuits quickly.
     72 * now we have circuit build time-outs occuring more frequently, we need to encourage Tor to try to generate circuits more often.
     73 * Once we have established a circuit, we are assuming its a good one and we dont want it being timed out by firewalls or anything else. We need to make sure a ping occurs on the circuit to prevent this.
     74Given this NFR, lets come up with some properties that may help satisfy it.
     75
     76 * CircuitBuildTimeout NUM
     77  . Try for at most NUM seconds when building circuits. If the circuit isn't open in that time, give up on it. (Default: 1 minute.) Force circuits that are quick to establish and thus likely to push traffic more quickly. Values as low as 2 seconds have been tried with good results, although the author is not sure on the effect on anonymity. The effect is a smaller 'Topological Radius' of servers used for Tor. The Topological Radius being the radius obtained topologically, in this case the network connections available from your connection.
     78 * KeepalivePeriod NUM
     79  . To keep firewalls from expiring connections, send a padding keepalive cell every NUM seconds on open connections that are in use. If the connection has no open circuits, it will instead be closed after NUM seconds of idleness. (Default: 5 minutes)
     80 * NewCircuitPeriod NUM
     81  . Every NUM seconds consider whether to build a new circuit. (Default: 30 seconds) Lets make Tor ready to establish a new circuit more readily.
     82Settings that you may append to the end of the torrc configuration file are as follows:
     83{{{
     84# Try for at most NUM seconds when building circuits. If the circuit
     85# isn't open in that time, give up on it. (Default: 1 minute.)
     86CircuitBuildTimeout 2
     87
     88# Send a padding cell every N seconds to keep firewalls from closing
     89# our connections while Tor is not in use. (Default: 5 minutes)
     90KeepalivePeriod 60
     91
     92# Force Tor to consider whether to build a new circuit every NUM
     93# seconds. (Default: 30 seconds)
     94NewCircuitPeriod 15
     95}}}
     96== The proof is in the pudding ==
     97With the changes made from Procedure 2 and 3, and a 2Mb connection, you can realise a sustained throughput of >100k, peaking at ~256k or more, with a ping response time of between 250 and 900ms.
     98
     99These figures were arrived at by using [http://speedtest.net SpeedTest.net]