From 9c315bda0e33041d8c309c1894315ddca1459c39 Mon Sep 17 00:00:00 2001 From: Steven Murdoch Date: Wed, 3 Feb 2010 22:14:34 +0000 Subject: [PATCH] Add new idea: Using the SPDY protocol to improve Tor performance --- doc/spec/proposals/ideas/xxx-using-spdy.txt | 136 ++++++++++++++++++++ 1 file changed, 136 insertions(+) create mode 100644 doc/spec/proposals/ideas/xxx-using-spdy.txt diff --git a/doc/spec/proposals/ideas/xxx-using-spdy.txt b/doc/spec/proposals/ideas/xxx-using-spdy.txt new file mode 100644 index 0000000000..48c51a0e2d --- /dev/null +++ b/doc/spec/proposals/ideas/xxx-using-spdy.txt @@ -0,0 +1,136 @@ +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