分布式拒绝服务攻击（DDoS）会用大量流量或请求耗尽服务资源。ET 的软路由可隐藏后端的直连地址、提供转发入口，但仅增加软路由不能保证防住 DDoS：公网入口的带宽和处理能力仍会受到攻击。下面记录的是我当时对 ET 软路由方案的理解，具体行为要以使用的版本和部署配置为准。
ET框架里的软路由就是个UDP请求转发服务器，就是将能直接访问的服务器与客户端之间又加了一层。普通的游戏，网关服务器绑定的地址是公网地址可以直接访问的，这样可能会被DDos打死，加了软路由后，暴露在外的只是一堆软路由。网关和其他服务器都是内网地址，外面不能直接访问。当客户端发一个到网关的请求时，先发到这个路由，再由路由向内网转发。
软路由是怎样工作的？
- 可以部署多个软路由入口，配合健康检查和地址下发做故障切换。但多个 IP 或机器不自动等于有抗 DDoS 能力；同一上游链路、带宽或下发服务仍可能成为瓶颈。客户端从 CDN 获取地址是本文讨论的部署方案，不是软路由机制本身的必备条件。
- 客户端在访问CDN得到软路由地址与realm内网地址和其他服务器内网地址后，选择一个软路由发送请求，请求里包括客户端想要访问的内网地址，软路由收到请求后将udp包转发给想要访问的内网地址。
- 软路由转发 UDP，客户端与服务器之间使用 KCP；连接状态、重传与故障切换依赖协议和应用层实现。切换入口时是否丢消息、重复消息或中断连接，需要按会话状态与重连流程验证，不能仅凭 KCP 就保证“消息不丢失”。
- 客户端连接会每隔2秒ping一次，在ping消息10秒没有收到回复时，重新请求获取一个新的软路由去连接。
加了软路由是否就安全了？
加了软路由后是否就高枕无忧了呢？并不是，还是要有其他安全措施的。
如果后端只允许软路由访问，外部无法直接向 gate、realm 的私网地址发送流量；但经过转发的恶意请求仍可能消耗后端资源，软路由本身和上游链路也可能被打满。入口需要限流、鉴权和容量防护，后端也需要对应用层请求做资源控制。
所以理论上来说会存在这么一种攻击方案：
首先解包游戏客户端。每个软路由都给一定的流量去发伪造的登录sdk的验证请求，发给登录验证服，登录验证服需要通过http请求访问登录sdk服务器去验证。当有大量流量都去访问sdk服务器，也是会对游戏服务器产生压力。
可参考 Azure DDoS Protection 对网络层与应用层攻击的区分；本文不等同于对某一版 ET 代码或实际部署的安全审计。
读到这里，感谢你。