抓包|网络分析

tcpdump抓包并用WireShark进行数据分析

2018-07-03  本文已影响0人  小马将过河
tcpdump.png
>>>我的博客<<<

1、使用背景

最近在项目开发时遇到一种情况,写的接口前端同事反馈是400,后端同事认为http status 是4开头的,肯定是前端的问题,前端的同事又不知道接口是怎么写的,需要传的参数也传了,但是就是400,那么作为负责人,不能任由两边踢皮球吧,得拿出个方案看看为啥400。
当然tacpdump这款强大的抓包工具不只是用使用解决我这个很low的问题,我的场景如果是前后端配合得当的话,或者已有默契的话,更好点,如果有文档,就不会有这个问题了。废话少说,直接说怎么做的吧。
最后选择linux服务器上抓好报文,用WireShark这款强大的抓包工具来分析一下啦。

工具介绍

2、实际操作

实际操作过程因为我作为后端工程师,没有前端环境,因此用我本地接口调试神奇postman来模拟前端。
服务端有一个接口是这样的:

    @PostMapping("tests")
    public RtnResult<String> testPost(@RequestBody DataVo vo) {
        logger.info("post data:{}" , JSONObject.toJSONString(vo));
        return new RtnResult<>(0,"保存成功");
    }

用postman本地测试,故意不传参数,效果如下:


参数错误400的场景

接下来,抓包查看。

2.1、准备工作

2.2、抓取服务端报文

例如我截取本机112.224.67.134和主机39.106.35.56之间的数据,在服务器39.106.35.56的任意目录执行如下命令:

[root@dev ~]# tcpdump -A -i eth0 -w dump-file1 host 112.224.67.134
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes

在本地用post请求服务器的接口


9.png

Ctrl+C停止保存抓包,报文内容保存在dump-file1文件内

[root@dev ~]# tcpdump -A -i eth0 -w dump-file1 host 112.224.67.134
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
^C24 packets captured
25 packets received by filter
0 packets dropped by kernel
[root@dev ~]# ll
total 4
-rw-r--r-- 1 tcpdump tcpdump 2880 Jul  3 14:05 dump-file1
[root@dev ~]# 

可以使用tcpdump -r dump-file1命令查看

[root@dev ~]# tcpdump -r dump-file1 
reading from file dump-file1, link-type EN10MB (Ethernet)
14:04:30.636260 IP dev.ssh > 112.224.67.134.26919: Flags [P.], seq 332116900:332116952, ack 3962938602, win 255, length 52
14:04:30.661616 IP dev.ssh > 112.224.67.134.26919: Flags [P.], seq 52:184, ack 1, win 255, length 132
14:04:30.710115 IP 112.224.67.134.26919 > dev.ssh: Flags [.], ack 184, win 66, length 0
14:04:49.658756 IP 112.224.67.134.26920 > dev.ssh: Flags [P.], seq 3449703456:3449703492, ack 3469026640, win 64, length 36
14:04:49.698057 IP dev.ssh > 112.224.67.134.26920: Flags [.], ack 36, win 255, length 0
14:05:04.771846 IP 112.224.67.134.58166 > dev.d-s-n: Flags [S], seq 3379667287, win 17520, options [mss 1400,nop,wscale 8,nop,nop,sackOK], length 0
14:05:04.771914 IP dev.d-s-n > 112.224.67.134.58166: Flags [S.], seq 2331290743, ack 3379667288, win 29200, options [mss 1460,nop,nop,sackOK,nop,wscale 7], length 0
14:05:04.811492 IP 112.224.67.134.58166 > dev.d-s-n: Flags [.], ack 1, win 68, length 0
14:05:04.820465 IP 112.224.67.134.58166 > dev.d-s-n: Flags [P.], seq 1:415, ack 1, win 68, length 414
14:05:04.820496 IP dev.d-s-n > 112.224.67.134.58166: Flags [.], ack 415, win 237, length 0
14:05:04.824051 IP dev.d-s-n > 112.224.67.134.58166: Flags [P.], seq 1:354, ack 415, win 237, length 353
14:05:04.824297 IP dev.d-s-n > 112.224.67.134.58166: Flags [P.], seq 354:359, ack 415, win 237, length 5
14:05:04.871458 IP 112.224.67.134.58166 > dev.d-s-n: Flags [.], ack 359, win 67, length 0
14:05:05.911468 IP 112.224.67.134.58166 > dev.d-s-n: Flags [.], seq 414:415, ack 359, win 67, length 1
14:05:05.911526 IP dev.d-s-n > 112.224.67.134.58166: Flags [.], ack 415, win 237, options [nop,nop,sack 1 {414:415}], length 0
14:05:06.951486 IP 112.224.67.134.58166 > dev.d-s-n: Flags [.], seq 414:415, ack 359, win 67, length 1
14:05:06.951537 IP dev.d-s-n > 112.224.67.134.58166: Flags [.], ack 415, win 237, options [nop,nop,sack 1 {414:415}], length 0
14:05:08.011588 IP 112.224.67.134.58166 > dev.d-s-n: Flags [.], seq 414:415, ack 359, win 67, length 1
14:05:08.011644 IP dev.d-s-n > 112.224.67.134.58166: Flags [.], ack 415, win 237, options [nop,nop,sack 1 {414:415}], length 0
14:05:09.051406 IP 112.224.67.134.58166 > dev.d-s-n: Flags [.], seq 414:415, ack 359, win 67, length 1
14:05:09.051452 IP dev.d-s-n > 112.224.67.134.58166: Flags [.], ack 415, win 237, options [nop,nop,sack 1 {414:415}], length 0
14:05:10.091399 IP 112.224.67.134.58166 > dev.d-s-n: Flags [.], seq 414:415, ack 359, win 67, length 1
14:05:10.091451 IP dev.d-s-n > 112.224.67.134.58166: Flags [.], ack 415, win 237, options [nop,nop,sack 1 {414:415}], length 0
14:05:10.130248 IP 112.224.67.134.26919 > dev.ssh: Flags [P.], seq 1:53, ack 184, win 66, length 52
[root@dev ~]# 

2.2、用wireshark分析报文内容

了解tcp网络协议的,看到以上报文,应该已经了解一二了。
为了将其转换成常用的http协议,我们用wireshark这款工具再分析一下。
下载该文件,在windows上可以直接将该文件拖入到wireshark,会自动打开。


tcpdump文件在WireShark中打开

可以看到三次握手的具体报文。同时看到了一个post的http request和一个http status为200的http response。右击post请求,选择【追踪流】->【TCP流】:


TCP流查看
看到了前端传过来的参数和返回值。

当然,查看服务器log,也看到了日志信息

2018-07-03 14:24:16.660  INFO 29004 --- [nio-8086-exec-6] com.hczt.shop.weixin.config.CorsFilter   : requesturi is : /weixin/tests
2018-07-03 14:24:16.661  INFO 29004 --- [nio-8086-exec-6] c.h.s.weixin.controller.TestController   : post data:{"address":"山东青岛","age":28,"name":"张三","sex":"男"}

这里演示的正常返回的,如果接口是400,服务端也就没有这条log,这时候抓包也才更有意义了。
到这里,基本的使用就介绍完了。至于WireShark在本地怎么使用,怎么添加过滤器等,查看其它博文学习。

3、推荐

WireShark抓包使用教程
tcpdump语法介绍与常用参数举例

上一篇 下一篇

猜你喜欢

热点阅读