Two days ago, a new exploit was released (via milw0rm) that highlights a new way of performing a DoS (Denial of Service) attack with a relatively low bandwidth requirement. Oftentimes, DoS attacks are simply a matter of which side has the fastest connection.
It is relatively simple to set up a SYN flood, for example, and if you have the faster connection, there's a pretty good chance you'll keep your victim offline until your victim adjusts their connection or yours is forcibly adjusted (e.g., by your ISP once it detects your DoS). There have been variations of this attack, such as Smurf, which uses broadcast addresses to amplify the traffic, but this recent exploit plays on the "kindness" of the webserver so to speak.
Essentially, it sends a connection request to the victim's webserver, much like any other normal request that a browser would send. However, it doesn't quite finish the request, but rather leaves off the last carriage return, and instead sends another header. The webserver will wait to receive the rest of the header, which never comes. Instead, new headers are sent, keeping the connection open and preventing other users from using that thread to connect with.
As might be expected, not a lot of bandwidth is needed to accomplish this attack, just enough to keep the webserver 'expectant' of more data, so to speak. As most webservers have a preset limit for the amount of incoming requests that it will accept at a time, send the traffic as described above will fill up the connection queue, preventing legitimate users from sending their own connection requests, and effectively taking the webserver offline with much less effort than is normally required. Interestingly, this attack is effective on Apache and others, but not on Microsoft IIS 6 & 7. You can find the exploit here: http://www.milw0rm.com/exploits/8976.
Right now, this isn't much of a patch to defend against this. It will almost certainly involve patching the way Apache and similar webservers process incoming connections, likely by limiting the amount of time a connection has to transmit its header information before dropping the connection entirely. Hopefully, this will get patched soon - with 47% of webservers being Apache, it has a lot to lose if this isn't fixed quickly.