分两种情况，一种是对着 IP 瞎鸡儿发包，一种是尝试构造异常请求。

如果是瞎鸡儿发包这种，设计的比较完善的交互协议，本身就有做强校验的。一般是在分两种情况。

如果是自有的二进制协议，适用于 app 请求场景，这种本身伪造的难度就很高。
一般是发到网络的请求包就带加密了，伪造协议无法正常交换密钥，在接入层解密的时候就会失败。

如果是公开协议，比如 http ，这一类很容易通过脚本构造请求包，
这类解决方式一般是在前端代码中混淆嵌入密钥和算法，然后给请求生成签名。
计算签名时，携带时间戳和随机数，然后接入层校验的时候就能拦截掉。
这类校验逻辑无上下文状态，节点很容易 scaling 。

实际业务中，除非是对内部实现有了解的人，否则很难通过非端环境构造合法报文。
大的系统都有专门的接入层，只负责协议加解密转发之类的，节点数远多于业务节点数，请求进接入层之前还要走 LB 。真正打垮接入层很难，成本极高。

如果是异常请求，但是通过了校验，比如别人拿了客户端代码改了直接发包。
这种就只能上验证码之类的了。