使用nod32导致客户端响应中没有gzip压缩标识的问题

2016/06/20 11:18:58 No Comments

之前在本机研究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

相关文章:

留下足迹