- From: David Krauss <potswa@gmail.com>
- Date: Thu, 29 May 2014 23:12:07 +0800
- To: Michael Sweet <msweet@apple.com>
- Cc: Jason Greene <jason.greene@redhat.com>, Willy Tarreau <w@1wt.eu>, Martin Thomson <martin.thomson@gmail.com>, Simone Bordet <simone.bordet@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
On 2014–05–29, at 11:00 PM, Michael Sweet <msweet@apple.com> wrote: > I do appreciate your efforts. But 100 instructions per byte is at least one order of magnitude more instructions than a literal copy of those bytes requires... For 16k worth of header data that translates into 1.6 million instructions executed just for one header frame - fairly significant for an embedded processor… If the MCU sees more than a hundred Huffman-encoded bytes per stream, you’re Doing It Wrong. There are plenty of other ways for a malicious party to crash a printer. 1.6 million instructions is still only a blink of an eye even for a small MCU. > For point of reference, proxying Richard's ~6B requests would require on the order of 10^15 instructions to be executed to decode all of the headers, and then perhaps another 10^15 instructions to re-encode them (depends on how it stores its header tables). Perhaps not unreasonable for fast proxy hardware over a period of a day, but is it necessary? Yes, byte-by-byte decoding is inherently branchy and may cause branch misprediction. However, the topic was low-end embedded processors and they aren’t pipelined. Anyway, my code is not optimized for that, and there’s no extrapolating MCU cycles to Xeon cycles.
Received on Thursday, 29 May 2014 15:12:50 UTC