[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
[tor-bugs] #12778 [meek]: Put meek HTTP headers on a diet
#12778: Put meek HTTP headers on a diet
-------------------------+---------------------
Reporter: dcf | Owner: dcf
Type: enhancement | Status: new
Priority: normal | Milestone:
Component: meek | Version:
Keywords: | Actual Points:
Parent ID: | Points:
-------------------------+---------------------
Let's shorten the headers added by meek-client and meek-server where we
can, to reduce the overhead of each request. I did some calculations
recently and the overhead was greater than I expected, about 85% when the
client sends a single Tor cell.
Here's a header sent by the Firefox meek-http-helper in the 3.6.2-meek-1
bundles, which use [https://gitweb.torproject.org/pluggable-
transports/meek.git/shortlog/refs/tags/0.7 meek 0.7]:
{{{
POST / HTTP/1.1\r\n
X-Session-Id: RAIzBBZBR5FFKxii7TBOldDAXUsBYI5+GhSKQPaQO6s=\r\n
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101
Firefox/24.0\r\n
Host: meek-reflect.appspot.com\r\n
Content-Type: application/octet-stream\r\n
Content-Length: 543\r\n
Connection: keep-alive\r\n
Accept-Language: en-US,en;q=0.5\r\n
Accept-Encoding: gzip, deflate\r\n
Accept:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8\r\n
\r\n
}}}
It's 413 bytes (which can vary a bit depending on the Host and Content-
Length headers). When it gets wrapped in its own TLS Application Data
record, it adds about 50 bytes (the ciphersuite I get with Google is one
that has to pad up to a block length).
(BTW I got the header by disabling the [https://gitweb.torproject.org
/pluggable-
transports/meek.git/blob/refs/tags/0.7:/firefox/components/main.js#l76
headlessness] of the browser extension, opening the browser console with
Ctrl+Shift+J, and clicking on a request.)
A Tor cell is 514 bytes, and inside a TLS Application Data record it is
543 bytes. Therefore the overhead for sending one cell is (413+â50)/543 â
85%. Of course, the overhead is less when several cells are sent at once:
â43% for two, and â28% for three.
Stuff set by meek-client that we could reduce:
* X-Session-Id: is 32 bytes (44 base64-encoded); could be 16 (24).
* Content-Type: is unnecessary, I think; remove it.
Stuff added by Firefox that we could reduce:
* User-Agent: could probably be removed.
* Accept-Language: could probably be removed.
* Accept-Encoding: could probably be removed.
* Accept: could probably be removed.
Stuff we should leave alone:
* Host
* Content-Length
* Connection
With meek-client changes we could save up to 60 bytes, and with meek-http-
helper changes we could potentially save up to 217 bytes, leading to a
header as small as 136 bytes, or an overhead of (136+â50)/543 â 34% when
sending one Tor cell; â17% for two; and â11% for three.
We should also check what the server's response headers.
(NB not that I think HTTP header overhead is the main cause of perceived
slowness; I'll bet [[ticket:12428|serialization of requests]] has a bigger
effect.)
(What about SPDY? Does it have smaller headers? Yes, good thought. It is
actually possible to use SPDY with the [[ticket:11393|Chrome extension]].
But Chromium doesn't allow you to override the Host header when you use
SPDY ([https://code.google.com/p/chromium/issues/detail?id=364319 Chromium
#364319]), so it doesn't work.)
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/12778>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs