在果壳网任时经历过多次DDoS反击。那种恐惧的心情，还忆起。难题不是你能做甚么，而是控制室决定了只不过你甚么都做得好。
反击者是控制一个足够多大的分布式系统软件产业来发动反击，各种乱七八糟的包，甚么单厢有。根本不在意你开的甚么服务项目，也没那冷静预测你有甚么服务项目。比如说即便你显然没出UDP的任何人服务项目，但他是发一堆UDP的包，把你频宽清空。还有啥配套措施。
二十多年前的OS还根本无法应对大量TCPmammalian相连，只好那个年代有个SYN flood反击，是一堆SYN包试著击掌。现代也有，效果一落千丈，但是仍然在大网络流量下可以堵塞被害者的通讯能力。
更现实的难题在于，控制室的总频宽有限。当你的伺服器IP段受到反击时，他会间接找上级网络相连西屯庄someone的包在H55N上都失掉。这时虽然晓得自己正在被DDoS反击，但反击包显然就没了控制室，更不用说伺服器，只好只能是守着伺服器，不无网络流量，等待。
上级领导网络相连商多半是寡头垄断国有企业，显然没冷静跟你做任何人深层次合作，间接科季夫是最简单方便的方法。同时，即便这时反击者停止了反击，你也不晓得。而想上级领导网络相连商重新迈入给你的包转发，甚至只好个一天的业务流程。而一旦发现反击还没用，就立刻又是科季夫。
那几年被反击时，也火烧火燎的找配套措施。试著将中文网站布署到云计算平台上，依靠对方提供的频宽输入输出来顶。甚至可能只是拼短期频宽的费用。当时国内的云计算服务商试了几十家，最终都因为没有足够多的频宽应对反击而拒绝了我们。他们都是出于对果壳网的钟爱和完全免费帮的，能努力做到这一步也挺不容易了。
有人提及反击软肋，我感觉真正这样耗费心力去预测的反击者只不过不尽然。不过多半反击确实会躲避一些明显抗反击能力不错的点，比如说很多中文网站的主页会做动态化，所以攻击主页就费时费力。图片反之亦然，对CPU耗用太少了。
几个常见的软肋：
1、登录认证
2、评论
3、用户动态
4、ajax api
总之涉嫌写数据库，联表查询，缓存涧出的都是好目标。
所以，回答是：没有啥好配套措施，冷静等待吧。
看了其他几个回答提供的方案，分别预测一下：
1、拼频宽：或者说拼软妹币，这不是一点点钱能搞定的，果壳网彼时只买了不足100M频宽，所在早期控制室总频宽也不足40G，反击频宽都没见过低于10G的(控制室的人后来告诉我的)。假设某便宜控制室(肯定不在北上广深)，频宽价格为100元/M*月，每月按峰值计费。则要买10G频宽顶一下，需要的月费是100万，100万……
2、网络流量清洗&封IP：如前述，要这么做的前提是反击包至少要到你的控制室。而控制室自保的措施导致了数据包显然到不了控制室，无解
3、CDN服务项目：现代CDN服务商还没有完善的动态网页加速技术，所以结果是，你充其量利用CDN保住动态化的主页可以访问，其他任何人动态中文网站功能就只能呵呵了。
这些与DDoS的周旋发生在二十多年前了。在现代的CDN服务商则有了更多方案来抵御DDoS反击。将网络流量间接委托给CDN服务商，则可以充分利用上这些成熟而强大的方案。下文是著名CDN服务商Akamai的应对案例，很值得大家学习现代DDoS反击原理和基于CDN的防卫手段。
