给你分享个案例，加深下理解： 我之前做的 gps 服务端，正常来讲就是服务器承载外边进来的上百万 tcp 连接，正常来说每个连接就是一台 gps 终端。 然而我需担心的场景是：我服务器集群全挂了，这时候我手动启动了 1 台，结果是这台必然很快就扛不住巨大的连接数挂掉。 这里最起码应该改成：在我完成整个后端几十台服务器的启动之后，再从防火墙一股脑的把连接放进来。 当然实际上的业务场景还有很多值得优化的地方，不到了具体问题面前甚至都讲不出来这些过程。
@brader 10 万台肉鸡，却发挥出 100 万台肉鸡的效果，也不过才每个肉鸡发起 10 个连接。 要知道你的根本在于，不能给对方回复，因为一旦接起连接，从接起开始就已经消耗了服务器端资源，连接的建立本身，可能已经比你发送的几个字节消耗资源更大了
攻击者的资源相比于服务提供者来讲肯定是更充裕的，要不然也没办法对你进行 dos 攻击。这就是一场资源的比拼，你要是能用更少的资源处理掉这些攻击，那你就建立了防御的优势。 我想表达的意思是，你都打算封 ip 了，那么丢数据包的行为越往前，肯定处理成本越小。在报文进入内核协议栈之前就把拉黑 ip 的报文丢掉不更爽嘛。
