| Bluntness is okay, but aren't you wrong about me being wrong here? I didn't say it was a Slowloris attack. I said Slashdotting was "in effect" the same thing. Which it is, both problems are one of exhausting limited concurrency. > The problem with "Slashdotting" was the number of concurrent connections. Exactly the same problem a Slowloris attack exploits. > Responses are heavy and can tie up slow connections... Yes, responses tie up the limited number of available httpd processes. The problem was that Apache couldn't even serve static files to many clients because of its heavy weight httpd processes and the fact that clients were so slow. If your web server can only handle 200 concurrent connections, and you want to serve a 500 KB screenshot of your 1337 Linux desktop to clients that download at 3.5 kbyte/s, you can handle like ~1.4 req/s. Doesn't take much to get Slashdotted. Whereas, event-based webservers could handle at least 10x more connections on the same hardware even before epoll existed. I had this problem in 1998 and fixed it with select/poll based servers, and then eventually other epoll-based servers before nginx existed. |
I guess I wrote what I did because the comparison to Slowloris seemed to over-emphasize the importance of handling high numbers of concurrent connections, since that is the only mitigation for Slowloris.
But, for a flood of real traffic, concurrent connections and throughput are related. The faster your web server can serve responses, the fewer concurrent connections it will need to handle. And as the percentage of dynamic DB-backed sites has increased over time, so has the value of caching. Basic page caching can speed up a Wordpress blog by hundreds of times for unauth'd users, for example. For most little sites, implementing caching will get them more than installing nginx.
And really, what good are valid concurrent connections if the throughput isn't there? For most users, a site that waits 5 minutes on a blank page is no better than a server that's down.