【发布时间】：2014-02-24 18:29:36
【问题描述】：
好的，对于我的应用程序，我正在尝试确定一种尽可能抗 DDoS 的架构。显然它永远不会是完美的，但我想保护免受简单的攻击。
目前我想到了一些：
1) 每个连接单线程。
这种方法似乎存在令人难以置信的可伸缩性问题，而且在连接数量众多的情况下，拥有太多线程似乎对操作系统来说是一场调度噩梦。
2) 2 个线程。第一个线程将接受连接并将它们附加到列表中，第二个线程循环遍历列表（此处使用适当的同步）并检查InputStream 中是否有任何内容。找到东西后，读一行。任何实际工作都将在一个新的事件线程中完成，包括回复。新线程刚刚通过读取的行。
这种方法似乎有更大的问题。看起来好像一个简单的cat /dev/urandom | telnet server port 会锁定它。
3) 这类似于#2，但在每次迭代时只从每个连接中读取一个字节，并在我到达换行字节时将其作为字符串处理。
到目前为止，这似乎是我最好的选择，但这意味着如果攻击启动大量连接并在所有连接上发送输入，它可能会大大减慢循环速度。
还有其他可能更适合这项工作的潜在架构吗？
【问题讨论】：
-
您的解决方案的问题是他们似乎试图限制速率，这与您想要做的相反。面对 DDoS 攻击时，您希望增加容量，以便在正常用户流量之外吸收 DDoS 流量。速率限制会同时断开用户和攻击者的连接，但攻击者不在乎，因此只会伤害用户。
-
@akirilov 他们的速率限制是什么意思？第一个是每个人一开始就学习的幼稚方法。其他的只是我想出的架构，我注意到了其中的缺陷。DDoS 最近是一件大事，所以在我写它之前，我一直在努力看到潜在的问题。我不知道该怎么办。我是否应该接受 DDoS 是一股不可忽视的力量？我为防止 DDoS 而设计的唯一一个是第三个，但其他两个显然更糟
-
基本上，这些方法最多只有两个工作线程。这对于大量合法流量来说还远远不够，更不用说 DDoS 攻击了。基本上，DDoS 依赖于用大量垃圾连接淹没您，这会使合法用户饿死（他们被困在等待服务器处理垃圾连接并经常超时）。
-
@akirilov 我可能应该提到工作线程只是用于查找输入。任何要采取的行动都会产生事件线程。
-
啊好的。在这种情况下，#2 中的想法是正确的，将有助于缓解发送空请求的非常简单的 DDoS 攻击，但我认为这是不太可能发生的情况。基本上，我会选择可以最快处理最多连接的那个（可能是＃2，尽管我也主张拥有多个可以接受连接的线程）。 DDoS 本质上是一种非常不雅但难以缓解的攻击。这是一场蛮力的战斗。最好的选择是拥有大量功能强大的服务器。
标签： java security network-programming