[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[or-cvs] [tor/master 1/3] Add new idea: Using the SPDY protocol to improve Tor performance
Author: Steven Murdoch <Steven.Murdoch@xxxxxxxxxxxx>
Date: Wed, 3 Feb 2010 22:14:34 +0000
Subject: Add new idea: Using the SPDY protocol to improve Tor performance
Commit: 9c315bda0e33041d8c309c1894315ddca1459c39
---
doc/spec/proposals/ideas/xxx-using-spdy.txt | 136 +++++++++++++++++++++++++++
1 files changed, 136 insertions(+), 0 deletions(-)
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 0000000..48c51a0
--- /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
--
1.6.5