Put meek HTTP headers on a diet
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 [[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 (Chromium #364319), so it doesn't work.)