尝试处理hash攻击的filter
1. 背景
去年底爆出来的hash攻击，其基本原理就是在一个请求中构造大量hash值相同的请求参数，导致服务容器在处理的时候hash操作变为链表操作，从而造成服务器load很高甚至瘫痪。
类似请求可以为:

    String s= "POST /test2/b2.do?arg=1&a=22 HTTP/1.1\nAccept: image/gif, image/jpeg, image/pjpeg, image/pjpeg, application/x-shockwave-flash, application/xaml+xml, application/vnd.ms-xpsdocument, application/x-ms-xbap, application/x-ms-application, application/vnd.ms-excel, application/vnd.ms-powerpoint, application/msword, */*\nReferer: http://127.0.0.1:8080/test2/b2.do?arg=1&a=22\nAccept-Language: zh-cn\nContent-Type: application/x-www-form-urlencoded\nUser-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0; chromeframe/16.0.912.77; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; .NET4.0C; .NET4.0E)\nAccept-Encoding: gzip, deflate\nHost: 127.0.0.1:8080\nContent-Length: 18\nConnection: Keep-Alive\nCache-Control: no-cache\n\nfname=abc&lname=1";  

注意Content-Length: 18是关键，让这个值大于实际的http body长度，就会阻塞。

<h3>3.一个实际的尝试</h3>
综上所述，在某些情况下，可以用filter来部分达到过滤的效果。但是考虑到网络状况不好的时候有问题和程序效率，最终还是放弃了filter的方式。不过这里针对tomcat的aprajp情况给一个例子：<a href="http://alicsd.com/wp-content/uploads/2012/02/SecurityFilter.txt">SecurityFilter</a>

通过这个尝试，我们看到了容器处理请求的一些细节，也为以后排查编码等问题带来一些方便。同时我们可以看到，如果构造一些不符合条件的http头，或者人工篡改contentLength的长度，使得容器的读取阻塞，在某种程度上也可以造成一些攻击的效果。（比同等数量的正常情况对容器伤害更大, 而且不容易防，因为不好判断是因为网络状况不好导致的读不到包，还是人为地加长了contentLength）