Bandwidth acceleration using HTTPS and not using UDP. Same results, but much more firewall and corporate network friendly. CrushTunnel uses patent pending technology.

Setup#

Go to the server preferences, and select tunnels.

Create a new tunnel, using the HTTP(S) Tunnel type. Enable Auto start. The name is not important, but something simple will do.

The local client port must be 55555. That is five fives.

The destination host must be 127.0.0.1, and the destination port can be anything as it will be ignored for this configuration.

Set the in Channels, and out Channels to be an appropriate multiplier for the speed gain you are looking for. You want to use the smallest value possible that still gives you the performance you need. I usually suggest something around 10 to 20. The min should be 1, and the max should be between 10 and 20. Enable the Auto checkbox on both as well.

Ports#

Next, go to the IP / Servers tab in the server preferences. Add two new server port items. The first on 55521 (FTP), and the other on 55580 (HTTP). Both should have their IP set to 127.0.0.1, and have the User Connection Group set to the same value as your main server's HTTPS ports value.

These ports, their protocol, and IPs must be set as defined. They will be used internally as part of the tunnel process. They must be FTP and HTTP respectively. They will be tunneled over the secure HTTPS tunnel.

Users#

Open the user manager, and select your user you want to allow to use the accelerated tunnel. Grant them access to that tunnel.

At this point, you can login and use the WebInterface and start getting the accelerated speeds.

The remote endpoint scenario takes this ability one step further by creating always-on CrushTunnel connections that are extending the location of where your CrushFTP server presents itself. The scenario would be a main server located in the US, but high speed endpoint locations located in Europe, and Australia.

A wildcard certificate should be used on the main server in the USA. For example: *.crushftp.com, and then using DNS entries of: us.crushftp.com —> USA IP 0 ms latency eu.crushftp.com —> Europe IP 120ms latency au.crushftp.com —> Australia IP 220ms latency

A virtual machine located in each of those zones would receive the connection, and simply tunnel it to the opposite side (which is always us.crushftp.com). The cert the browser would be presented would always be the same *.crushftp.com, so all of those DNS names would be successfully matched and allowed.

Under normal conditions a 220ms of latency would yield about 2.4Mbit of speed per channel. This assumes default TCP tuning on both ends. Using 20 channels, this would now yield 48Mbit of speed. Adjust the number of channels as needed and appropriate.

No data would be stored on these remote server locations, all data is simply being streamed. Users that are in Australia for instance would use the nearby server’s DNS to get much faster speeds in file transfer since their local machine’s latency to that server would probably be under 40ms, or faster. The end points server locations would need to be located in ideal locations to serve the customers with the lowest latency.

The CrushTunnel solution is CPU intensive, but light on disk usage. Disk would only be used for logging, nothing else. The CPU is used heavily in the HTTPS encryption, and tunnel management. The benefits include on single location of data, one storage location, and one set of users.