Put meek HTTP headers on a diet
|Reported by:||dcf||Owned by:||dcf|
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 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 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:
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 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 Chrome extension. But Chromium doesn't allow you to override the Host header when you use SPDY (Chromium #364319), so it doesn't work.)