HN user
jgc AT cloudflare DOT com
The chaps that keep the CloudFlare global network running do seem a bit busy than usual today. I asked if there were "more attacks than usual" and they replied "Yes" and rushed off to do something.
Which sites?
Yes, but SPDY does compression of headers and so the same cookie being sent should be compressed.
We'll blog about it later.
Similar lack of structure exists at CloudFlare.
You could use CloudFlare as a front end to take some of the load.
"Oh I get that this is the key fact, I put a smiley in there because I was fishing for a more exact number that is unlikely to be given"
The honest truth is that I actually don't know how many servers we have because it's not a number that I have to worry about.
I do know that floor(log_10(#servers)) = 2.
Hundreds of servers in 23 locations worldwide, each server running multiple instances of Nginx: http://blog.cloudflare.com/a-tour-inside-cloudflares-latest-... The key fact is that this type of scale is possible with Nginx + Lua + hundreds (not thousands) of servers.
If that were to happen (and I think it's a big "if" because of the complexity of predicting what will throw it off given that the attacker doesn't know the code we are running) then we'd see the WAF latency increase and alarms would be generated immediately. That, in turn, would cause a bunch of other mechanisms to come into play.
We are entirely Linux not NetBSD and are not currently using Lua in the kernel at all. We did, however, sponsor some of Mike Pall's work on LuaJIT based on our particular workload: http://luajit.org/sponsors.html#sponsorship_perf
We use Lua for the WAF (as Mike says), but also for all request processing. This is in part because we use Nginx and in part because employ agentzh (http://agentzh.org/) and he works on OpenResty. Fairly recently we moved all processing of requests through CloudFlare to a Lua-based system inside Nginx.
That's >5B pages views per 24 hours going through LuaJIT-ed code.
From the post:
A recent example illustrates the power of this approach:
Cloudflare's WAF (web application firewall) basically generates
Lua code for the (highly non-linear) maze of firewall rules. An
incoming attack triggers certain rules and the corresponding paths
are turned into linearized traces. These can be heavily optimized
by LuaJIT, much more so than you could ever hope to do with a
static compiler.
When a different attack wave is started, it'll spawn different
traces -- i.e. the generated code dynamically adapts to the
specific attacks.
The result is a much higher firewall throughput than you might be
able to achieve with a data-driven or a static compilation
approach. This directly equates into money saved on machines
needed to handle the load.
The bottom line is that LuaJIT is very fast and very flexible.
It would be interesting to know if there are 'flagging rings' in the same way there are 'voting rings' and whether HN actively detects the former as it does the latter.
I'll poke around and have a look to see why. The Ray ID will be different each time; it's a debugging feature that identifies the request when something goes wrong.
If this persists please contact support AT cloudflare DOT com so we can track it.
What's the Ray ID?
I guess the OP thought HN would be interested in it. We (CloudFlare) didn't submit it; it's just one of many, many posts on our blog.
Can be SSL or not to the origin. Plus there's the Railgun option that also uses TLS.
Not a web host, but if you use CloudFlare with SSL in front of your host you get PFS: http://blog.cloudflare.com/staying-on-top-of-tls-attacks
typerandom: if you have time I'd be interested in understanding the performance problems you reported on CF. My email is in my profile.