Idea: Using the SPDY protocol to improve Tor performance

["Steven J. Murdoch" <tor+Steven.Murdoch@xxxxxxxxxxxx>]

Filename: xxx-using-spdy.txt
Title: Using the SPDY protocol to improve Tor performance
Author: Steven J. Murdoch
Created: 03-Feb-2010
Status: Draft
Target:

1. Overview

   The SPDY protocol [1] is an alternative method for transferring
   web content over TCP, designed to improve efficiency and
   performance. A SPDY-aware browser can already communicate with
   a SPDY-aware web server over Tor, because this only requires a TCP
   stream to be set up. However, a SPDY-aware browser cannot
   communicate with a non-SPDY-aware web server. This proposal
   outlines how Tor could support this latter case, and why it
   may be good for performance.

2. Motivation

   About 90% of Tor traffic, by connection, is HTTP [2], but
   users report subjective performance to be poor. It would
   therefore be desirable to improve this situation. SPDY was
   designed to offer better performance than HTTP, in
   high-latency and/or low-bandwidth situations, and is therefore
   an option worth examining.

   If a user wishes to access a SPDY-enabled web server over Tor,
   all they need to do is to configure their SPDY-enabled browser
   (e.g. Google Chrome) to use Tor. However, there are few
   SPDY-enabled web servers, and even if there was high demand
   from Tor users, there would be little motivation for server
   operators to upgrade, for the benefit of only a small
   proportion of their users.

   The motivation of this proposal is to allow only the user to
   install a SPDY-enabled browser, and permit web servers to
   remain unmodified. Essentially, Tor would incorporate a proxy
   on the exit node, which communicates SPDY to the web browser
   and normal HTTP to the web server. This proxy would translate
   between the two transport protocols, and possibly perform
   other optimizations.

   SPDY currently offers five optimizations:

   1) Multiplexed streams:
      An unlimited number of resources can be transferred
      concurrently, over a single TCP connection.

   2) Request prioritization:
      The client can set a priority on each resource, to assist
      the server in re-ordering responses.

   3) Compression:
      Both HTTP header and resource content can be compressed.

   4) Server push:
      The server can offer the client resources which have not
      been requested, but which the server believes will be.

   5) Server hint:
      The server can suggest that the client request further
      resources, before the main content is transferred.

   Tor currently effectively implements (1), by being able to put
   multiple streams on one circuit. SPDY however requires fewer
   round-trips to do the same. The other features are not
   implemented by Tor. Therefore it is reasonable to expect that
   a HTTP <-> SPDY proxy may improve Tor performance, by some
   amount.

3. Design outline

   One way to implement the SPDY proxy is for Tor exit nodes to
   advertise this capability in their descriptor. The OP would
   then preferentially select these nodes when routing streams
   destined for port 80.

   Then, rather than sending the usual RELAY_BEGIN cell, the OP
   would send a RELAY_SPDY_BEGIN cell, to indicate that the exit
   node should translate between SPDY and HTTP. The rest of the
   connection process would operate as usual.

   There would need to be some way of elegantly handling non-HTTP
   traffic which goes over port 80.

4. Implementation status

   SPDY is under active development and both the specification
   and implementations are in a state of flux. Initial
   experiments with Google Chrome in SPDY-mode and server
   libraries indicate that more work is needed before they are
   production-ready. There is no indication that browsers other
   than Google Chrome will support SPDY (and no official
   statement as to whether Google Chrome will eventually enable
   SPDY by default).
   
   Implementing a full SPDY proxy would be non-trivial. Stream
   multiplexing and compression are supported by existing
   libraries and would be fairly simple to implement. Request
   prioritization would require some form of caching on the
   proxy-side. Server push and server hint would require content
   parsing to identify resources which should be treated
   specially.

5. Security and policy implications

   A SPDY proxy would be a significant amount of code, and may
   pull in external libraries. This code will process potentially
   malicious data, both at the SPDY and HTTP sides. This proposal
   therefore increases the risk that exit nodes will be
   compromised by exploiting a bug in the proxy.

   This proposal would also be the first way in which Tor is
   modifying TCP stream data. Arguably this is still meta-data
   (HTTP headers), but there may be some concern that Tor should
   not be doing this.

   Torbutton only works with Firefox, but SPDY only works with
   Google Chrome. We should be careful not to recommend that
   users adopt a browser which harms their privacy in other ways.

6. Open questions:

  - How difficult would this be to implement?

  - How much performance improvement would it actually result in?

  - Is there some way to rapidly develop a prototype which would
    answer the previous question?

[1] SPDY: An experimental protocol for a faster web
    http://dev.chromium.org/spdy/spdy-whitepaper
[2] Shining Light in Dark Places: Understanding the Tor Network Damon McCoy,
    Kevin Bauer, Dirk Grunwald, Tadayoshi Kohno, Douglas Sicker
    http://www.cs.washington.edu/homes/yoshi/papers/Tor/PETS2008_37.pdf

-- 
http://www.cl.cam.ac.uk/users/sjm217/