tor/doc/spec/proposals/ideas/xxx-using-spdy.txt

144 lines
5.8 KiB
Plaintext
Raw Normal View History

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.
The consequences on caching need to be considered carefully.
Most of the optimizations SPDY offers have no effect because
the existing HTTP cache control headers are transmitted without
modification. Server push is more problematic, because here
the server may push a resource that the client already has.
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_BEGIN_TRANSFORMED cell, with a parameter 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