未解决
此帖子已超过 5 年
2 Intern
•
1.2K 消息
23
313561
如果看了这个你还是不会用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网络协议实现细节,检查安全问题,网络协议内部构件等等。
Zhang_Jiawen
2 Intern
2 Intern
•
1.2K 消息
0
2014年8月11日 18:00
非常专业~
bryan_Sd
1 消息
0
2014年8月28日 23:00
不但人美的不像话,文章也好的不像话,
shadanhua
2 消息
0
2014年9月4日 02:00
HI, Jiawen,请教下,Client用FTP下载Server的数据,在中途会重新中断的情况,从抓包来看Server侧回了一个426-Compression,Response code为Connection closed,transfer aborted(426)。是否可以判断是Server侧的原因导致而非网络原因。盼回复。谢谢!
yansheng
2 Intern
2 Intern
•
235 消息
0
2014年9月4日 17:00
这个搞网络分析的能用上吧 存储貌似很少用着个
Zhang_Jiawen
2 Intern
2 Intern
•
1.2K 消息
0
2014年9月4日 18:00
从这个截图,并不能证明问题一定在服务器或是一定在网络。
确实,server端发了一个reset包回复client连接已关闭,但是server端发reset之前最后一个包是fin ack,编号为371718,时间为60秒之前。也就是说,server的确收到了来自client的包,但是过了60秒,server似乎没有收到来自client的包。但到底有没有收到,从这个截图中看不出,我们只能看到client的retransmission,不知道是由于server死了,还是371730到371744的包在网络中丢失了。直至60秒之后,server端才关闭了这个半关闭连接。
Roger_Wu
2 Intern
2 Intern
•
4K 消息
0
2014年9月4日 18:00
恩,iSCSI问题有时可以用上。
xiaolei1
1 消息
0
2014年10月20日 19:00
整理这么多,很受用,也很辛苦,让我不得不回复
Anonymous User
1 消息
0
2014年10月29日 02:00
讲的很详细,虽然也经常使用wireshark抓包分析,但总觉得所懂还很浅,今天看了你的文章和分析,从中又有所悟,多谢;
Zhang_Jiawen
2 Intern
2 Intern
•
1.2K 消息
0
2014年10月29日 18:00
我写这篇之前也是生疏了。看看文章再实际操作一下,比较不容易忘记。
540663670
5 消息
0
2014年12月27日 22:00
微信号多少,我关注下,谢谢
Yanhong1
1.6K 消息
0
2014年12月28日 06:00
可以搜索“易安信中国技术社区”,或者在论坛首页右上角有微信的二维码
多谢关注,新年快乐!
shadanhua
2 消息
0
2014年12月31日 21:00
Hi,Jiawen。新年快乐!今天又来请教问题了。客户端跟58.61.37.52服务器交互数据,怀疑是服务器端做了些限制之类的,但苦于表达不够强烈未能说服客户。麻烦Jiawen有空帮忙看下我的判断是否正确。非常感谢!
原始文件:http://pan.baidu.com/s/1o6sR938
bairichard1
107 消息
0
2015年1月4日 00:00
我尝试回答一下:
网络包是在客户端192.168.2.254上抓的。客户端和服务器之间的RTT(往返时间)应该在50毫秒以内,不算大。问题是有些包从客户端发出去之后,服务器收不到,或者是过很长时间才能收到,于是最终服务器关闭了TCP连接。
如果客户很难沟通,建议你在客户端和服务器上同时抓包,让他们看到某些包明明从客户端发出去了,服务器却收不到,估计在路上丢失了。如果客户比较好说话,而且懂TCP协议,那你这个包就可以作为证据了。
Zhang_Jiawen
2 Intern
2 Intern
•
1.2K 消息
0
2015年1月4日 18:00
感谢沛满!
补充一下:从抓包看来server和client之间的通信是有问题的,server发的syn+ack(972),client回复了ack(973),可是server看上去没有收到,又重发了一次(993),因为client认为连接已完全建好,就开始发包,可是一直没有收到server的ack,然后不断重发,server最终发了fin,client就reset了连接
Zhang_Jiawen
2 Intern
2 Intern
•
1.2K 消息
0
2015年1月4日 18:00
感谢沛满!
补充一下,从抓包看来server和client之间的通信是有问题的,server发的syn+ack(972),client回复了ack(973),可是server看上去没有收到,又重发了一次(993),因为client认为连接已完全建好,就开始发包,可是一直没有收到server的ack,然后不断重发,server最终发了fin,client就reset了连接