All posts by kpdyer

How many users can an fteproxy server serve?

This post will focus on the performance and scalability of fteproxy. Specifically, we’re going to look at it’s maximal throughput in its default configuration and how it scales as the number of simultaneously connected users increases. This is, in part, motivated by the spike in fteproxy users February, which begs the question: how many fteproxy Tor bridges do we need if the number of users increase from 100s, to 1Ks, to 10Ks, etc.

TL;DR We can support at least two orders of magnitude more users with the existing infrastructure of six Tor bridges.

 

Our Environment

We spun up two AWS instances. Our client is an m.large instance in the US East (N. Virgina) region. Our server is an m.medium instance in he US West (Oregon) region. This asymmetry enables us to know the performance limitations of the server-side m.medium instance.

In order to establish a baseline for the performance between the two instances we use iperf. On our server we run:

$ iperf -s -p 8081

This spins up a listener on the server’s port 8081. Then on our client we run:

$ iperf -c $SERVER_IP -p 8081 -P 1
------------------------------------------------------------
Client connecting to $SERVER_IP, TCP port 8081
TCP window size: 85.0 KByte (default)
------------------------------------------------------------
[ 3] local $CLIENT_IP port 34918 connected with $SERVER_IP port 8081
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.1 sec 192 MBytes 160 Mbits/sec

Iperf spins up, generates a single connection and sends as much data as possible within 10 seconds, then reports the throughput. This test reports ~160 Mbits/sec, which was a consistent result across multiple invocations of this test.

 

fteproxy: Single-Connection Performance

Next, we want to use iperf to test the performance of fteproxy between the client and server. We install fteproxy 0.2.19 via PyPI and then spin up the fteproxy client on our client:

$ fteproxy --mode client --server_ip $SERVER_IP

and the fteproxy server on our server:

$ fteproxy --mode server --server_ip 0.0.0.0

Then, client-side, we’re able to run iperf and connect to our local fteproxy listening port in order to tunnel iperf via fteproxy:

$ iperf -c 127.0.0.1 -p 8079 -P 1
------------------------------------------------------------
Client connecting to 127.0.0.1, TCP port 8079
TCP window size: 2.50 MByte (default)
------------------------------------------------------------
[ 3] local 127.0.0.1 port 53831 connected with 127.0.0.1 port 8079
[ ID] Interval Transfer Bandwidth
[ 3] 0.0-10.1 sec 170 MBytes 142 Mbits/sec

Single-threaded performance turns out to be exceptional. We achieve 142Mbps, compared to 160Mbps with a direct connection. This is a performance penalty of only about 12%.

 

fteproxy: Multiple-Connection Performance

As are final test, we use the same configuration as in the single-connection test. However, we use the “-P” switch in iperf in order to create multiple simultaneous datastreams. We performed this test for P=[10,20,…,100] and achieved the following:

raw_performancefteproxy_performance

 

With 100 simultaneous streams fteproxy achieves roughly 1.5Mbps throughput per stream, compared to 3.8Mbps throughput with a direct connection.

 

Conclusion

A cursory analysis of the server-side side performance during these tests indicate the fteproxy is, in fact, CPU bound with 100 simultaneous users. However, this test is extreme in the sense that all connections attempted to send data as aggressively as possible. Whereas in practice a user that is, say, browsing the web using fteproxy will exhibit a less demanding workload. Hence, an fteproxy server hosted on an m3.medium instance will likely scale well beyond 100 simultaneous users.

Given that the current fteproxy usage in Tor has peaked at ~300 users/day, it appears that the fteproxy software will probably scale to serve two orders of magnitude more users with our current infrastructure of six servers.



Automated fteproxy testing for 0.2.18

A new testing framework has been released for fteproxy [1]. The goal of this framework is automate the process of testing fteproxy across a range of platforms and installation strategies

The testing framework validates fteproxy across 12 different platforms and two different installation strategies (via pip or via a tar/zip.) The following is a summary of the configuration used for each platform:

Debian/Ubuntu – Virtual machines were created with VirtualBox, controlled by vagrant, and shell scripts were created for each of the installation methods.

OSX – Licensing is difficult for OSX which makes it difficult to install on VirtualBox, etc. without substantial efforts. Parallels is the only VM that supports OSX as a guest — however, its scripting support is limited. Therefore, the host platform was used to do all pip tests in a virtualenv and all tar tests in a sandbox. This could be adapted to a VM in future.

Windows – VirtualBox images were created for each platform. Cygwin was installed with sshd and the default, insecure, vagrant public keys for SSH access. Vagrant boxes were then packaged, shell scripts were created to download the fteproxy zips from fteproxy.org and bat scripts were created to test the binaries.

The following table is a summary of results against fteproxy 0.2.18.

Screen Shot 2014-10-05 at 3.02.09 PM

Future improvements: include testing for fteproxy’s deployment settings, such as Tor and automate the process of testing inter-version compatibility.

 

-Kevin

[1] https://github.com/kpdyer/fteproxy-tester


This work was made possible with a donation from NLnet foundation. Consider help funding the next stage of development of fteproxy with a donation.



fteproxy 0.2.18 and libfte 0.1.0 released!

These releases address a memory leak and structure the project such that it’s compatible with the debian build process. For more details see [1] and [2].

-Kevin

[1] https://github.com/kpdyer/libfte/releases/tag/0.1.0
[2] https://github.com/kpdyer/fteproxy/releases/tag/0.2.18

This work was made possible with a donation from NLnet foundation. Consider help funding the next stage of development of fteproxy with a donation.



fteproxy 0.2.16 released

We’re pleased to announce version 0.2.16 of fteproxy. This release fixes a number of performance and functional issues.

  • Issue #144: cleanup of build process, remove makefile
  • Issue #147: fteproxy fails unit tests on python 2.6
  • Issue #148: get fteproxy working on Travis CI
  • Issue #149: long-running fteproxy server leaks memory
  • Issue #151: fteproxy fails to close network connections
  • Issue #152: add txsocks and parsley to setup_tbb.py

Binaries and source code is available on fteproxy.org. This package has also been published to PyPI.

 

This work was made possible with a donation from NLnet foundation. Consider help funding the next stage of development of fteproxy with a donation.



fteproxy 0.2.15, libfte 0.0.3 released

We are pleased to announce the release of fteproxy 0.2.15 [1, 2] and libfte 0.0.3 [3, 4].

This release focused on:

  • Separating fteproxy into two projects: fteproxy [5] and libfte [6].
  • Making both fteproxy [1] and libfte [3] compatible with pypi. Now, one can use pip to “pip install fteproxy” on Windows/Linux/OSX.
  • Bugfixes [1, 4, 8]: resolve install issues on Linux and ensure that we package data files correctly, to be compatible with pypi.

Note that compiled binaries are available at [7].

-Kevin

[1] https://pypi.python.org/pypi/fteproxy/0.2.15
[2] https://github.com/kpdyer/fteproxy/releases/tag/0.2.15
[3] https://pypi.python.org/pypi/fte/0.0.3
[4] https://github.com/kpdyer/libfte/releases/tag/0.0.3
[5] https://github.com/kpdyer/fteproxy
[6] https://github.com/kpdyer/libfte
[7] https://fteproxy.org/dist/0.2.15
[8] https://pypi.python.org/pypi/fteproxy/0.2.14

 
This work was made possible with a donation from NLnet foundation. Consider help funding the next stage of development of fteproxy with a donation.



fteproxy 0.2.13 released – precompiled binaries now available

On fteproxy.org  we now have stand-alone executables of fteproxy, available for download for all target platforms: Windows/OSX/Linux.

https://fteproxy.org/download

We also include debian packages for 32-bit/64-bit Debian/Ubuntu systems.

These binaries have been tested on:

  • Debian 7
  • Ubuntu 12.x/13.x/14.04
  • Windows XP, Windows 7, Windows 8.1
  • OSX 10.9

Please download, verify, and test these packages, and let us know if you encounter any issues.

-Kevin

 

This work was made possible with a donation from NLnet foundation. Consider help funding the next stage of development of fteproxy with a donation.



fteproxy 0.2.12 and fteproxy-builder 0.0.2 released

fteproxy 0.2.12 addresses the following issue raised against fteproxy on Windows:https://trac.torproject.org/projects/tor/ticket/11286.

In addition, this release addresses:

Issue #120: problems building on Windows
Issue #126: ensure that we have compatibility for all 0.2.x versions of obfsproxy
Issue #127: where “make test” sometimes fails on Windows.
Issue #130: improved warn/error/exception handling

The release of fteproxy-builder 0.0.2 addresses issues for building window binaries, and support for debian binaries.

 

This work was made possible with a donation from NLnet foundation. Consider help funding the next stage of development of fteproxy with a donation.



fteproxy 0.2.10 released

In support of issues raised against version 3.6-beta-1 [1] of the Tor Browser, we’ve released versions 0.2.8/0.2.9/0.2.10 of fteproxy. These releases resolve the following issues:

Issue #121: support target in Makefile for producing debian packages
Issue #122: resolve issues where fteproxy sometimes terminates long-running Tor connections
Issue #123: Provide support for Tor Extended OR Port functionality
Issue #124: PyCrypto import error investigated and closed
Issue #125: Network connections, in some cases, close prematurely

In addition, updates to the README and BUILDING files add additional details for BUILDING on Linux/OSX.

[1] https://blog.torproject.org/blog/tor-browser-36-beta-1-released

 

This work was made possible with a donation from NLnet foundation. Consider help funding the next stage of development of fteproxy with a donation.



fteproxy 0.2.7 and fteproxy-builder 0.0.1 released

We are pleased to announce the release of fteproxy 0.2.7, and the initial release of fteproxy-builder 0.0.1. The purpose of this separation is to delineate between issues that are inherent to the design and engineering of fteproxy and issues that are due to building/packaging fteproxy for specific platforms.

The goal of the fteproxy-builder project is to streamline the process of building fteproxy for multiple target platforms and architectures. We are using Vagrant, VirtualBox and modern cross-compilers such that Linux, OSX, and Windows binaries of fteproxy can be built from OSX/Linux. For more details, please see the README.

The current version of fteproxy-builder supports OSX as the host platform and the binaries produced have been tested on Debian 7.1.0, Ubuntu 12.x/13.x, and Windows Vista/7/8. There is a known issues on Windows XP, which has been raised here : fteproxy-builder issue #1.

In support of fteproxy-builder, we performed a complete overhaul of the fteproxy build system. Our Makefile now supports the following options:

  • make – Compiles fteproxy for the host platform.
  • make dist – Compiles fteproxy and creates a distributable (tar.gz or zip) in the “dist” folder.
  • make dist-[platform]-[arch]  – Performs cross-compilation and builds a package for [platform]/[arch] and places the file in the “dist” folder. Currently, only supported on Linux host machines.

Current [platofrm]-[arch] combinations supported are: linux-i386, linux-x86_64, windows-i386, and osx-i386.

For more details about each of these projects, please see:

 

This work was made possible with a donation from NLnet foundation. Consider help funding the next stage of development of fteproxy with a donation.



fteproxy awarded grant from the NLnet Foundation

The fteproxy project has been awarded a generous grant of $16,000 from the NLnet Foundation. This grant was awarded as a result of NLnet’s November 2013 award cycle.

This award from NLnet will be instrumental in continued success of development, testing and deployment of fteproxy during 2014. As a few examples of our goals this year, we plan to:

  • Ensure and improve the quality, security, and performance of the fteproxy software.
  • Improve our testing/deployment infrastructure (e.g., automate the building/packaging system.)
  • Establish more fteproxy-powered Tor servers (bridges).
  • Promote fteproxy as a censorship circumvention tool.
  • Develop new features, to support the wide-spread and diverse uses of fteproxy.

The generous support from NLnet will accelerate the timeframe in which we achieve these goals in 2014. For that, we are very grateful.

-Kevin P. Dyer

 

NLnet logo
Learn more about the NLnet Foundation.