- From: Willy Tarreau <w@1wt.eu>
- Date: Thu, 29 May 2014 18:45:18 +0200
- To: David Krauss <potswa@gmail.com>
- Cc: Michael Sweet <msweet@apple.com>, Jason Greene <jason.greene@redhat.com>, Martin Thomson <martin.thomson@gmail.com>, Simone Bordet <simone.bordet@gmail.com>, HTTP Working Group <ietf-http-wg@w3.org>
On Fri, May 30, 2014 at 12:36:34AM +0800, David Krauss wrote: > > On 2014?05?30, at 12:01 AM, Willy Tarreau <w@1wt.eu> wrote: > > > On Thu, May 29, 2014 at 11:12:07PM +0800, David Krauss wrote: > >> > >> 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. > > > > Well, 1.6M instructions for a request is huge, whatever the processor size. > > That would basically limit a 3 GHz CPU to 2000 requests/s when it can currently > > do 300000 in http/1.1. I'm starting to be really worried? > > 3 GHz CPUs don?t do only one instruction per cycle. See the caveats I mentioned. No but my experience tells me that bit manipulation operations are very rarely parallelizable. And anyway,even if they were, we wouldn't run 100 instructions in parallel :-) > If you want to overwhelm the network hardware in a printer, you can easily do > so just given its IP address. Aside from malicious inputs, a printer protocol > with so many headers would be simply broken. That is my only point. I agree and am not trying to "protect" the small devices from being attacked, just trying to figure what optimal performance we can get with/without certain encoding options. Being used to optimize code to reach hundreds of thousands of requests per second with hundreds of thousands of concurrent connections, I'm facing the same challenges as Michael with his MCU in that I'm having a very limited amount of memory and CPU cycles per request, except that I have a wider choice of instructions. > Also, the 100 instructions figure is just a guesstimate from looking at my > compiled binary. I?ve debugged using only the first example from the spec, > but it?s past my bedtime, so maybe someone would like to test further or > profile the code. But, again, it is designed for embedded MCUs and not really > network-oriented hardware. OK. > https://code.google.com/p/lightweight-http2-huffman-decoder/ Thanks for sharing the code, that's really helpful. Willy
Received on Thursday, 29 May 2014 16:46:13 UTC