之前在本机研究dropwizard时,本着默认的情况下应该开启gzip压缩,因此在相应的yml配置中开启gzip标记(它本身也是开启的).但是在相应的请求返回中并没有出现相应的gzip标识,在chrome浏览器下的标识信息为如下的响应所示:
从上面的标识来看,在响应头上并没有gzip标识.
然后开始痛苦的处理过程,从浏览器,客户端,服务端,然后最后从网络层逐步处理,最终找到问题的原因及出处.
刚开始是怀疑chrome会自动进行解压缩,从而让响应中的content-encoding标识被去除.但google之后,并没有找到相应的资料.因此,尝试自己使用特定的socket协议来原生实现http请求,以跳过浏览器来进行请求,以查看相应的响应信息.
相应的客户端java代码如下所示:
Socket socket = new Socket("127.0.0.1", 8082);
OutputStream outputStream = socket.getOutputStream();
final String header = "GET /demo/1.0/items/ HTTP/1.1\r\n" +
"HOST: 127.0.0.1:8082\r\n" +
"Connection: close\r\n" +
"User-Agent: AppleWebKit/537.36\r\n" +
"Accept-Encoding: gzip, deflate, sdch\r\n" +
"\r\n";
outputStream.write(header.getBytes());
outputStream.flush();
InputStream inputStream = socket.getInputStream();
FileCopyUtils.copy(inputStream, new FileOutputStream("d:/y1.txt"));
以上的代码应该算是最原始的请求了.其中的User-Agent是从chrome中直接copy过来.响应信息直接写入txt中,但是查看txt,相应的结果如下:
HTTP/1.1 200 OK
Date: Mon, 20 Jun 2016 02:38:20 GMT
Content-Type: application/json;charset=UTF8
X-TOTAL: 10
Vary: Accept-Encoding
Connection: close
[{"id":0,"itemDate":"2016-06-20T10:38:20.495+0800","value":{"id":0,"itemDate":"2016-
同样可以看到,在原始的响应中都没有相应的gzip标识.
然后就是认为在服务端的处理有问题,因为在调试过程中,发现在刚才的java代码中,如果把User-Agent头去掉,相应的gzip数据就出来了.因此怀疑是不是服务端对User-Agent有特殊的处理方式,然后就是手动对jersey和jetty代码进行断点调试,一切无果.
调试了半天,确定服务端是使用了BiDiGzipFilter来进行压缩,同时也在响应中写入了gzip标识,但到了客户端就没有了. 到了这一步,因此可以考虑是不是网络上的原因,一种想法就是数据在网络中被处理过了,比如公司网关,或者是什么信息.
Wireshark
因为之前听说过wireshark网络工具,因此下载之,同时为了避免公司网络监控原因(可能存在),回家按照教程配置一下,开启8082端口监听.响应如下所示:
因为是本机,因此要开启相应的回环监听,让其监听本地连接信息(同时把防火墙关掉,这一点很重要),从上面的信息中可以看到,相应的网络流中是存在gzip压缩的.但是再次查看相应的输出文件,仍然是未压缩的数据.
因此,可以确定的是,肯定是本地有什么工具在起作用,而且此工具是与网络相关的.开始一个一个地关,首先是防火墙,然后结果是相应的程序.只留下java程序,当关掉杀毒软件nod32时,结果变正常了.然后相应的chrome访问也正常了.相应的正常响应如下所示:
因此,可以确定的是,肯定是nod32有处理网络相关的监控,而且会自动对网络访问进行解包.打开相应的设置,直到找到以下一项:
OK,问题终于解决.关掉即可,同时注意的是,在上面的http协议的端口,虽然我在测试中使用的是8082,并不是上述的端口列表.因此可以确定上述列表填了没用,最后的解决方法就是把http扫描去掉.(确信自己的防木马能力还是有的)
结论
后来google了一下,确实也有很多出现了类似的问题.
此篇文章的目的在于,中间的处理过程感觉很戏剧性,但是仍然有一定的问题处理思路(思路发散).同时善用相应的工具,比如这里提到的wireshark,之前一直没有尝试过,这次强行学习并使用之,真是网络处理以及协议分析的一大神器.
附:wireshark使用指南:http://blog.jobbole.com/101476/
转载请标明出处:i flym
本文地址:https://www.iflym.com/index.php/code/201606200001.html