これはServerfaultに適しているかもしれませんが、ここにしか来ない多くのWeb開発者は、おそらくこの質問に対する可能な回答から恩恵を受けるでしょう。
問題は、Webサーバーに対するサービス拒否攻撃からどのように効果的に身を守るかということです。
この記事を読んだ後、私はこれを自問しました
よく知らない人のために、私が覚えていることは次のとおりです。DoS攻撃は、偽のヘッダーをサーバーに繰り返し送信することにより、すべての接続を占有しようとします。
そうすることで、サーバーは可能な同時接続の制限に達し、その結果、通常のユーザーはサイトにアクセスできなくなります。
ウィキペディアはさらにいくつかの情報を提供します：http：//en.wikipedia.org/wiki/Denial_of_service
万能薬はありませんが、次のいくつかを実行することで、DoS 攻撃をより困難にすることができます。
調整された要求をキューに入れるのではなく、調整された要求を完全に拒否することが重要です (たとえば、HTTP 503: Service Unavailable応答または使用しているプロトコルに適した同様の応答を使用)。それらをキューに入れると、キューがすべてのメモリを消費するだけで、DoS 攻撃はスロットリングを行わなかった場合と少なくとも同じくらい効果的になります。
HTTP サーバーに関するより具体的なアドバイス:
POSTWeb サーバーが、ヘッダーを伴わないメッセージを拒否Content-Lengthし、指定された を超えるリクエストを拒否 (および問題のクライアントを抑制)し、 (または) がサービスに対して不当に長い を含むContent-Lengthリクエストを拒否するように構成されていることを確認してください。を目的としたContent-LengthPOSTPUTこの特定の攻撃（リクエストがGETである限り）では、ロードバランサーまたはWebサーバーへの完全なリクエストのみに基づくWAFが機能します。
これが悪意のあるPOSTなのか、ユーザーからのアップロードが非常に遅いのかわからないため、GET POSTの代わりに使用すると（簡単です）、問題が発生します。
DoS自体からは、単純な事実のためにWebアプリを実際に保護することはできません。リソースは限られていますが、攻撃者はDoSを実行するための時間とリソースに制限がない可能性があります。そして、ほとんどの場合、攻撃者が必要な手順を実行するのは安価です。たとえば、上記のこの攻撃は、数百の低速接続接続->問題ありません
たとえば、非同期サーバーは、この特定の形式の攻撃に対して多かれ少なかれ免疫があります。たとえば、私は Nginx リバース プロキシを使用して Django アプリを提供していますが、攻撃はその操作にまったく影響を与えていないようです。別の一般的な非同期サーバーは lighttpd です。
この攻撃は、接続が遅い 1 台のマシンでも実行できるため、危険です。ただし、一般的な DDoS 攻撃は、サーバーを大量のマシンと戦わせます。攻撃から身を守るためにできることはほとんどありません。
簡潔な答え：
DoS から身を守ることはできません。
そして、DoS はセキュリティの問題として分類され、プログラミングに明確に関連しているため、それが serverfault に属することに同意しません。