未解决
此帖子已超过 5 年
1.2K 消息
23
312950
如果看了这个你还是不会用Wireshark,那就来找我吧(8月6日完结)
一站式学习Wireshark(一):Wireshark基本用法
转载请在文首保留原文出处:EMC中文支持论坛https://community.emc.com/go/chinese
介绍
应用Wireshark显示过滤器分析特定数据流(下) NEW
应用Wireshark诊断网络性能 - TCP重传与重复ACK
应用Wireshark诊断网络性能 - TCP窗口与拥塞处理
更多信息
按照国际惯例,从最基本的说起。
抓取报文:
下载和安装好Wireshark之后,启动Wireshark并且在接口列表中选择接口名,然后开始在此接口上抓包。例如,如果想要在无线网络上抓取流量,点击无线接口。点击Capture Options可以配置高级属性,但现在无此必要。
点击接口名称之后,就可以看到实时接收的报文。Wireshark会捕捉系统发送和接收的每一个报文。如果抓取的接口是无线并且选项选取的是混合模式,那么也会看到网络上其他报文。
上端面板每一行对应一个网络报文,默认显示报文接收时间(相对开始抓取的时间点),源和目标IP地址,使用协议和报文相关信息。点击某一行可以在下面两个窗口看到更多信息。“+”图标显示报文里面每一层的详细信息。底端窗口同时以十六进制和ASCII码的方式列出报文内容。
需要停止抓取报文的时候,点击左上角的停止按键。
色彩标识:
进行到这里已经看到报文以绿色,蓝色,黑色显示出来。Wireshark通过颜色让各种流量的报文一目了然。比如默认绿色是TCP报文,深蓝色是DNS,浅蓝是UDP,黑色标识出有问题的TCP报文——比如乱序报文。
报文样本:
比如说你在家安装了Wireshark,但家用LAN环境下没有感兴趣的报文可供观察,那么可以去Wireshark wiki下载报文样本文件。
打开一个抓取文件相当简单,在主界面上点击Open并浏览文件即可。也可以在Wireshark里保存自己的抓包文件并稍后打开。
过滤报文:
如果正在尝试分析问题,比如打电话的时候某一程序发送的报文,可以关闭所有其他使用网络的应用来减少流量。但还是可能有大批报文需要筛选,这时要用到Wireshark过滤器。
最基本的方式就是在窗口顶端过滤栏输入并点击Apply(或按下回车)。例如,输入“dns”就会只看到DNS报文。输入的时候,Wireshark会帮助自动完成过滤条件。
也可以点击Analyze菜单并选择Display Filters来创建新的过滤条件。
另一件很有趣的事情是你可以右键报文并选择Follow TCP Stream。
你会看到在服务器和目标端之间的全部会话。
关闭窗口之后,你会发现过滤条件自动被引用了——Wireshark显示构成会话的报文。
检查报文:
选中一个报文之后,就可以深入挖掘它的内容了。
也可以在这里创建过滤条件——只需右键细节并使用Apply as Filter子菜单,就可以根据此细节创建过滤条件。
Wireshark是一个非常之强大的工具,第一节只介绍它的最基本用法。网络专家用它来debug网络协议实现细节,检查安全问题,网络协议内部构件等等。
yot1
9 消息
0
2014年8月10日 19:00
前面不是我的回复...好像是别人回复我,就会自动发一条···是有设置什么自动回复之类的吗???
我今天才刚上线···
我去整理一下包,先谢谢。
Zhang_Jiawen
1.2K 消息
0
2014年8月10日 19:00
好像还是看不到附件。可以再试一下吗?按照Jason提到的那个帖子里的方法。
Zhang_Jiawen
1.2K 消息
0
2014年8月10日 19:00
开了一个新的帖子:网络基本功系列:细说网络那些事儿 欢迎留言,提问或砸砖。
Jason_Zhou
1.2K 消息
0
2014年8月10日 19:00
估计是你的邮件系统里那时开启了自动回复外部邮件功能吧?这里论坛回贴可以有两种方式:1. 直接用浏览器登录论坛打开帖子回帖 2. 收到帖子更新提醒的系统通知邮件后,直接回复那封邮件并写上想要回复的内容也能回帖。估计你的对外邮件自动回复功能自动回复了论坛系统的通知邮件,所以多出来几个空白的回复
yot1
9 消息
0
2014年8月10日 20:00
谢谢,我邮箱好像是有设置自动回复。以去掉!
yot1
9 消息
0
2014年8月10日 20:00
附件是发送端抓的包。
同样的信息发送,正常情况和异常情况。
异常情况中可以看到的ack742多次重复。发送端也多次重传!
这次看到win窗口是变小了···是缓冲区问题吗。
2个附件
正常.txt
异常.txt
bairichard1
107 消息
0
2014年8月10日 22:00
example:
tcpdump -i eth0 -w /tmp/tcpdump.cap
这样存下来的才是完整的包。
bairichard1
107 消息
0
2014年8月10日 22:00
yot1
9 消息
0
2014年8月10日 22:00
呃,在linux下,这是tcpdump抓的。
不完全是指传送信息没显示全吗?
其他的好像都全的吧?
yot1
9 消息
0
2014年8月10日 23:00
21不是会一直重传吗,但是一直传不过去,这时候122是可以给21传数据的。
21也能收到,只是发不出去,堵在重传了。
这种情况只能断掉连接重连了吗?
bairichard1
107 消息
0
2014年8月10日 23:00
分析完了:
10.98.128.21在给183.129.202.122传数据的过程中,有些时间段网络包会一直丢失,所以就出错了。至于在网络中哪个节点丢失的,我们从这个包中无法得知。两端的接收窗口都没有问题,问题出在网络上。
yot1
9 消息
0
2014年8月10日 23:00
呃,重新上传了。有劳~
2个附件
tcpdump.cap
tcpdump_error.cap
bairichard1
107 消息
0
2014年8月11日 00:00
是的,21一直尝试重传一个长度为1452的数据段,但是传不过去。它也能收到122发过来的包,但是没有用,业务(应用层)要求的是21把数据传给122。这种情况下即便断掉重连也不一定能解决,因为如果网络很差,你传着传着还是会连续丢包。不过有时候断掉重连恰好碰上网络状况好转,就显得似乎是通过重连解决的样子。
就像感冒之后一直吃维生素C,吃着吃着就好了,但是我们无法判断维C有没有起作用一样。
yot1
9 消息
0
2014年8月11日 01:00
嗯,又抓了几次包,看到重传有时候能过去,有时候死活过不去。
网络环境如此,看来只能从其他方面想想怎么解决了。
非常感谢peiman和jiawen,在这里了解了tcp很多。
bairichard1
107 消息
0
2014年8月11日 15:00
不客气。以这种网络条件,我们在应用层和TCP层再怎么优化都不会有好成绩,在这个包中我看到ssh和http同样有严重丢包。还不如想办法解决网络瓶颈。