VPN跑了480M流量681K个包，竟然收到GFW的RST包957K，VPN发一个包，GFW回来1.4个reset包。GFW也太狠了。

@unwiredkite 上面哪个主题计算有错误。理论上的确有可能，只要大家都发包，引发GFW回来RST包。

@BOYPT 应该是有可能的，研究一下他发包机制，让他大量的发包，cpu跑满100%，正常翻墙的链接就不会被强奸。

@gonbo 不太可能的，你一台机器不可能和TBit级的设备对抗。
而且Wa11有多个节点，就算你搞垮了一个，其他出口一切正常。

@gonbo 现在的高性能网络设备数据包根本就不用过CPU的好么～

@chenshaoju 我觉得这个是一个正确思路。dns污染完全可以搞死。

@BYPT 这种需要计算的封禁肯定是cpu的。

而且你收到这么多个RST不是因为人家故意发给你那么多个，是因为同时触发了多个节点，有时候有些节点忙别的就不发给你了，

GFW的这个模式是个完美的 flexible extensive module

@gonbo 肯定不是。

很奇怪LZ一直这样drop rst还能继续使用VPN，rst发到一定程度应该就直接封ip了

@gonbo CPU计算量很小。特征匹配、校验和都是硬件完成。

你要想完美就搞个国外的卫星通道，架个小锅，就不受GFW约束了

@zeeler 延迟比较大呀。

@BOYPT
@ShadowStar 我觉得他们做基于流量特征的分析，肯定需要大规模计算量的。

@SAGAN 把两边把RST都drop了，所以能够用VPN，不过速度很慢。

@gonbo 特征分析一般是在后端服务器群做，前端接入设备简单高效。

@ShadowStar Openvpn的TLS握手特征那种就扔后端做，所以一般改端口后有几个小时能用的；

关键字触发RST这种机制即时性高，完全就硬件级别识别的了。cisco的流处理单元但是很牛x的。

@gonbo 以 GJ 雄厚的财力，一秒 TB 级别的 RST 包根本就没感觉。

如果真要这样 DDOS ，估计 GFW 不倒国际出口先被搞挂了。GFW 用的都是曙光超级计算集群，流量分析还不是小 Case 。如果容量不够了尽管加机器，看谁能撑得住。

@gonbo 现在是两边都 drop reset 所以还能连上，要是它能自动升级为封 ip 呢，还能通讯么？

另外，这是个什么状况？有点不大理解。按常规，墙完全可以弄个小脚本来自动地跑，一旦超过某个值，就触发程序来封你服务器的 ip 不就完了嘛，为啥没这么做？还是说你又做了什么反制手段，让它停留在 reset 的级别，所以还能跑？

感觉 DDOS 是主动碰线，不如想什么办法，悄悄地进村，碰线地不要。

@BOYPT 基本是这样的，现在的设备除了通常的黑白名单外，还会有灰名单，对于不确定的流量丢到后端做（行为、特征）分析学习，然后将生成的特征下发到前端设备，后续的相同流量就前端直接处理了。

想把GFW弄死，理论上可以，实际操作起来基本不可能。

@jackyz 可能是因为旁路上没法封IP，主干路由上封IP不是说封就封的，路由表多了会影响转发速度，只有极少数IP享受这种待遇

@treo 封IP和路由没关系。通常手段只有2种：串接阻断和旁路RST。从整体可靠性上来看，一般都比较保守的采用旁路方式。

你这是在与GM开玩笑

@enj0y 有足够多的带宽，的确可以这样做呀。

很早以前我做过测试，当时的环境是如果连续触发墙，那么一段时间墙就不发送RST了，更早以前就直接在国际出口处断开你的国际互联网连接，注意，是彻底断开，你的整个国际出口就没有了。

如果要说墙的负载，是的，墙的确有负载，去年什么时候墙封掉了整个 *.co.jp 域名，结果洪水一样的请求的确淹没了墙（猜测是国内的图片/JS引用，证券或商业交易等），RST延迟骤升： http://twitpic.com/9x2sph

真想淹没墙？等 *.com 域名被墙掉了再说。

@gonbo 有足够多的带宽做这个就会有行政/刑事人员找你了（有关部门