David, On May 29, 2014, at 10:27 AM, David Krauss <potswa@gmail.com> wrote: > On 2014–05–29, at 9:51 PM, Jason Greene <jason.greene@redhat.com> wrote: > >> >>> On May 29, 2014, at 1:40 AM, Willy Tarreau <w@1wt.eu> wrote: >>> >>> These ones could be advertised in the ALPN name (h2 = failsafe, h2h = >>> hpack version for example) so that we don't need an extra round trip >>> to know what is supported. >> >> You mean disable/disallow the Huffman encoding bit in HPACK right? HPACK with a size 0 table is easy for embedded devices (and everyone else), offers decent reduction in header sizes, and runs no risk of a CRIME style attack. > > I’ve just started debugging an 8-bit friendly Huffman decoder. It looks like under a kilobyte of code & tables, and on the order of 100 instructions executed per symbol. (Could be less than a hundred, could be more. Haven’t profiled yet.) > > Huffman is just a drop in the bucket. I’ll share the code when it’s working. 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... 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? _________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair
Received on Thursday, 29 May 2014 15:01:11 UTC