RStudio Server part 3: using an ssh tunnel for high performance

In part 2 of this series of posts on RStudio Server, I commented that I suspected that RStudio Server would be fast. The first time I tried this from a remote connection, I was disappointed with the performance. Many companies filter their http traffic, for example to be able to block Youtube. This takes time ofcourse, and reduces performance. If the company allows ssh connections, you can use a neat trick to get much better performance with RStudio Server by using an ssh tunnel. Assuming you have access to a bash shell (Linux, Mac, and Cygwin should work), open an ssh tunnel like this:

The ssh command is built up like this (partly from the manpage of ssh):

  • -f: Requests ssh to go to background just before command execution
  • -N: Do not execute a remote command. This is useful for just forwarding ports.
  • -L: Specifies that the given port on the local (client) host is to be forwarded to the given host and port on the remote side.
  • 1234: local port
  • localhost: local host
  • 443: remote port
  • username and hostname of the server where RStudio Server is running

Accessing RStudio can now be done be typing localhost:1234 into your web browser. Now the connection is secure through ssh, and fast because it is not seen as http traffic. This vastly increased performance in my case.

Tagged with: , ,
Posted in R stuff
2 Comments » for RStudio Server part 3: using an ssh tunnel for high performance
  1. Presumably this is compared to using unsecured HTTP (port 80) as the protocol; otherwise I am at a loss as to how this helps?

    If you are using secure HTTP (https: as the protocol which is what port 443 is normally for) then the contents is encrypted and your corporate filters can not inspect the body of the communications. That is the same as with the ssh tunnel. As for the headers, TCP traffic to port 443 on the remote machine is just TCP traffic to the port on the machine whether it originates from Firefox or ssh, and the corporate filter will apply.

    So the only place I can see this making a difference is where you have a corporate filter that inspects the contents of the HTTP requests (or responses) AND you are comparing http (not https) protocol with ssh.

    Otherwise the ssh tunnel is TCP over TCP which is a Bad Idea™, see for example for a discussion.

Leave a Reply

Your email address will not be published. Required fields are marked *

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    Markdown is turned off in code blocks:
     [This is not a link](

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see