2010-02-03 23:14:34 +01:00
|
|
|
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.
|
|
|
|
|
2010-03-14 20:07:52 +01:00
|
|
|
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.
|
|
|
|
|
2010-02-03 23:14:34 +01:00
|
|
|
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
|
2010-03-14 20:07:52 +01:00
|
|
|
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.
|
2010-02-03 23:14:34 +01:00
|
|
|
|
|
|
|
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
|