未解决
此帖子已超过 5 年
1.2K 消息
23
312863
如果看了这个你还是不会用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
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
235 消息
0
2014年9月4日 17:00
这个搞网络分析的能用上吧 存储貌似很少用着个
Zhang_Jiawen
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
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
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
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
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了连接