1 2 3 4 5 上一个 下一个 112 回复 最新回复: Jun 1, 2015 2:07 AM Zhang,Jiawen 转至原始发贴 RSS
  • 30. Re: 如果看了这个你还是不会用Wireshark,那就来找我吧(7月14日更新)
    Zhang,Jiawen

     

    问题:业务突然变慢,客户端(确定)和服务端(应该)都没有改动。

    问题定位:根据经验判断是网络质量变差,现在需要验证判断。(服务端无法协调联查,但服务端处理很多客户端,未见其他地方的客户端有同样问题)。

    验证过程:首先断掉客户端重连,用wireshark抓包发现tcp三次握手都还行。客户端发数据包也很快,服务端回tcp的ack也挺快,但数据包的响应就慢了一些。客户端发大数据包的时候,干脆就没响应包回来(但也不是必然)。根据逻辑,服务端和网络都有可能有问题,客户端出问题的可能可以排除。不过业务的服务端是nb的中国移动,客户端所在的网络是中国电信的网络,因此我们基本可以把问题归结为网间互通。

    有趣的问题是:小包看起来是ok的,大数据包延迟(或丢包)的现象很严重。

     

    非常感谢分享.很高兴这篇文章能帮到你.从现象来看像是服务器和客户端中间的某个环节出现了问题.不知道这个问题现在解决了没有,如果有进一步发现再来一起讨论~

     

    关于这几个问题:

    1、在wireshark上,如何方便查一个tcp报对应的响应包(或响应包对应的原始包)。可以手工根据sequence id和ack id来判断,但是wireshark提供方便的工具么?

     

    可以参考楼下大牛的回答~

     

    2、有没有技巧可以方便的统计延时的情况,例如某时间段中,发包到收到ack的延时超过1s的数据包数量?

     

    添加一列按照每一个报文据上一个报文的延时来显示:

    扩展TCP报文头。右键Time since previous frame in the TCP stream,然后选择Apply as a Column,这样产生新的一列。

    如下图所示。就可以方便的看到每一个报文距离上一个报文的延时了。然后可以根据延时从大到小来排列。

    Capture.PNG.png

     

    3、有没有技巧可以方便的统计丢包的情况,例如某时间段中,发出去的包没收到ack的有多少?

    可以尝试应用display filter过滤条件,输入tcp.analysis,wireshark会列出关于TCP问题和性能的过滤条件,其中有关于重传报文(tcp.analysis.retransmission)的过滤:

    Capture.PNG.png

    另外给出一个TCP显示过滤条件的详细说明:

    Wireshark · Display Filter Reference: Transmission Control Protocol

  • 31. Re: 如果看了这个你还是不会用Wireshark,那就来找我吧(7月14日更新)
    Peiman Lin

    1, “业务突然变慢,客户端(确定)和服务端(应该)都没有改动。

    [沛满]:如果怀疑是网络有问题,可以在业务慢的时候抓个500MB左右的网络包分析一下。论坛可以上传的话我也可以帮忙分析。

    2,“在wireshark上,如何方便查一个tcp报对应的响应包(或响应包对应的原始包)。可以手工根据sequence id和ack id来判断,但是wireshark提供方便的工具么?----我们的业务是在一个tcp长连接中发很多包。

    [沛满]:这个要从基本原理讲起。TCP的工作方式不是逐个包发送的,而是一口气发出多个包,从而提高传输效率。就像快递员会一次性携带很多包裹到我司前台一样,为的是减少消耗在路上的往返时间。接收方收到这些包之后有两个选择,既可以每个包都确认(也就是你提到的响应),也可以只确认最后一个来暗示所有包都收到了。举个例子,发送方发出了10个包,编号1至10,且没有一个丢失的,那接收方既可以回复10个确认包,也可以只回复“ack 11”,表示10以及10之前的所有包都收到了。当有丢包发生时,比如还是发送了10个包的情况,编号也是1至10,但其中10号包丢失了,那接收方可以回复9个确认包,也可以只回复“ack 10”,表示9以及9之前的包都收到了。

     

    了解了这个原理,我们就知道在Wireshark上没有必要去对应每个ack和seq,因为大多数包即便正常收到后也不会有ack。

    3,“有没有技巧可以方便的统计延时的情况,例如某时间段中,发包到收到ack的延时超过1s的数据包数量?

    [沛满]:如果你只是想了解网络延时状况,那用ping最简单准确了,没有必要用Wireshark。一般我们在乎的是应用层的延时,比如向一个服务器发送读请求,到收到读响应的时间差究竟有多少。Wireshark上有提供这个功能,比如CIFS协议那就可以用“smb.time > 1”来过滤出所有超过一秒钟的延时的CIFS操作。如果是NFS,就用rpc.time(因为NFS是基于RPC的协议)。HTTP也有http.time。

    4,“有没有技巧可以方便的统计丢包的情况,例如某时间段中,发出去的包没收到ack的有多少?

    [沛满]:还是那句话,没有收到ack不一定是丢包了。如果是想看丢包重传的统计,那就Analyze-->Expert Info,然后看warnings or notes tab. 虽然要统计出结果很容易,不过使用者需要理解tcp的基础知识才能解读这个结果,比如一个超时重传,导致的后果远远超过一个快速重传。有启用SACK的时候,处理多个丢包的效率远高于没有启用SACK的……这个说起来太复杂了。

  • 32. Re: 如果看了这个你还是不会用Wireshark,那就来找我吧(7月14日更新)
    Zhang,Jiawen

    感谢沛满,解释的非常清楚

  • 33. Re: 如果看了这个你还是不会用Wireshark,那就来找我吧(7月14日更新)
    易隐者

    妹子的确是认真的干了这件事情,赞一个,择机转到我的个人博客www.vants.org,欢迎文章作者妹子来访切磋,本人做科来4年半,现在在合肥组织一群技术兄弟创业中

  • 34. Re: 如果看了这个你还是不会用Wireshark,那就来找我吧(7月14日更新)
    Zhang,Jiawen

    朋友也在创业,我很理解创业的辛苦不足为外人道之处,向创业的兄弟致以由衷的敬意~

     

    拜访了你的博客,非常专业细致的总结~

  • 35. Re: 如果看了这个你还是不会用Wireshark,那就来找我吧(7月14日更新)
    happydanye

    哈哈,又有高手出没,感谢解答。继续发问:

     

    1、既然可以只确认最后一个,那么接收方的确认机制通常有哪几种?(每n个包确认一次?),如果收到1,2,3,4,5,7,8,9,10个包(包6丢了),如何回复确认消息?

     

    2、ping这个我是知道的,但是有的服务器禁ping。另外,我还发现有ping正常的包,但是实际业务包延迟厉害。我刚测试了一下,ping的时候,包大小很有关系。900以下比较正常,超过1000的包都收不到,900和1000之间的包时好时坏。这个结果有参考意义么?

  • 36. Re: 如果看了这个你还是不会用Wireshark,那就来找我吧(7月14日更新)
    happydanye

    晕,找不到“Time since previous frame in the TCP stream”,展开tcp报文头,【seq/ack analysis】后面就是pdu了。

  • 37. Re: 如果看了这个你还是不会用Wireshark,那就来找我吧(7月14日更新)
    Zhang,Jiawen

    先回答这个问题:

    晕,找不到“Time since previous frame in the TCP stream”,展开tcp报文头,【seq/ack analysis】后面就是pdu了。

    需要在TCP protocol preferences开启Calculate conversation timestamps让它显示出来。

     

    此外,还有一个显示过滤条件也可以使用:tcp.time_delta>X。

  • 38. Re: 如果看了这个你还是不会用Wireshark,那就来找我吧(7月14日更新)
    Zhang,Jiawen

     

     

    1、既然可以只确认最后一个,那么接收方的确认机制通常有哪几种?(每n个包确认一次?),如果收到1,2,3,4,5,7,8,9,10个包(包6丢了),如何回复确认消息?

     

     

    举个例子解释一下这一过程:(在Edit | Preferences列配置,显示下图tcp.seq和tcp.ack值,回答之前的问题

     

    7645_09_16a.jpg

    如上图,服务器626.219.24.171发送序列号为120185105的报文,之后发送序列号为120186557的报文,客户端10.0.0.7接收到之后,通过ACK=120188009告知服务器下一个报文序列号。之后服务器发送序列号为120188009的报文,这样下去。

    7645_09_16b.jpg

     

    当一个报文的ACK丢失,或是ACK没有及时到达的时候,报文会重传,发送方会做两件事情:

    1.再次发送报文,(可以参考前文)

    2.减小吞吐量。

  • 39. Re: 如果看了这个你还是不会用Wireshark,那就来找我吧(7月14日更新)
    Zhang,Jiawen

     

    2、ping这个我是知道的,但是有的服务器禁ping。另外,我还发现有ping正常的包,但是实际业务包延迟厉害。我刚测试了一下,ping的时候,包大小很有关系。900以下比较正常,超过1000的包都收不到,900和1000之间的包时好时坏。这个结果有参考意义么?

    发现延时的时候,首先应当做的事情就是ping。这个结果有啥意义,我暂时想不到,等沛满来看看。

  • 40. Re: 如果看了这个你还是不会用Wireshark,那就来找我吧(7月14日更新)
    Peiman Lin

    1、“既然可以只确认最后一个,那么接收方的确认机制通常有哪几种?(每n个包确认一次?),如果收到1,2,3,4,5,7,8,9,10个包(包6丢了),如何回复确认消息?”

    [沛满]:通常有两种,一种是每个包都确认,一种是只确认(连续的)最后一个包。如果不是连续的(中间有包丢失),就确认丢包之前的那一个。以你所举的“如果收到1,2,3,4,5,7,8,9,10个包(包6丢了)”为例,那确认包就是ack 6, 表示12345收到了,在等待6。6没有丢,只是乱序到10后面了,那发送方在收到4个ack 6之后,又会收到ack 11。


    2、“ping这个我是知道的,但是有的服务器禁ping。另外,我还发现有ping正常的包,但是实际业务包延迟厉害。我刚测试了一下,ping的时候,包大小很有关系。900以下比较正常,超过1000的包都收不到,900和1000之间的包时好时坏。这个结果有参考意义么?”

    ping正常而实际业务包延迟得厉害,正符合我昨天提到的,“一般情况下我们更关注的是应用层的延迟”。比如你发送一个http request给IIS服务器,但是IIS当时很忙,所以就回复得很慢,从客户端看起来就是高延迟。ping包则不一样,收到后基本都是及时回复的,所以更能反映网络上的延迟。

    ping的大小在MTU以内应该关系不是非常明显,假如900以下正常,超过1000的全收不到,那得好好查查网络了,比如是不是路上有个设备的MTU比较小。

  • 41. Re: 如果看了这个你还是不会用Wireshark,那就来找我吧(7月22日更新)
    Zhang,Jiawen

    一站式学习Wireshark(八):应用Wireshark过滤条件抓取特定数据流

     

    转载请在文首保留原文出处:EMC中文支持论坛https://community.emc.com/go/chineseimage001.gif

     

    介绍

     

    应用抓包过滤,选择Capture | Options,扩展窗口查看到Capture Filter栏。双击选定的接口,如下图所示,弹出Edit Interface Settints窗口。

    image002.png

    下图显示了Edit Interface Settings窗口,这里可以设置抓包过滤条件。如果你确知抓包过滤条件的语法,直接在Capture Filter区域输入。在输入错误时,Wireshark通过红色背景区域表明无法处理过滤条件。最有可能的情况是,过滤条件中含有输入错误,或是使用了display filter的语法。

     

    点击Capture Filter按钮查看并选择已保存的抓包过滤条件。

    image003.png

    更多信息

     

    抓取指定IP地址的数据流:

     

    如果你的抓包环境下有很多主机正在通讯,可以考虑使用所观察主机的IP地址来进行过滤。以下为IP地址抓包过滤示例:

    ·         host 10.3.1.1:抓取发到/来自10.3.1.1的数据流

    ·         host 2406:da00:ff00::6b16:f02d:抓取发到/来自IPv6地址2406:da00:ff00::6b16:f02d的数据流

    ·         not host 10.3.1.1:抓取除了发到/来自10.3.1.1以外的所有数据流

    ·         src host 10.3.1.1:抓取来自10.3.1.1的数据流

    ·         dst host 10.3.1.1:抓取发到10.3.1.1的数据流

    ·         host 10.3.1.1 or 10.3.1.2:抓取发到/来自10.3.1.1,以及与之通讯的所有数据流,与10.3.1.2,以及与之通讯的所有数据流

    ·         host www.espn.com:抓取发到/来自所有解析为www.espn.comIP地址的数据流

     

    抓取指定IP地址范围的数据流:

     

    当你需要抓取来自/发到一组地址的数据流,可以采用CIDR(无类别域间路由,Classless Interdomain Routing)格式或使用mask参数。

    ·         net 10.3.0.0/16:抓取网络10.3.0.0上发到/来自所有主机的数据流(16表示长度)

    ·         net 10.3.0.0 mask 255.255.0.0:与之前的过滤结果相同

    ·         ip6 net 2406:da00:ff00::/64:抓取网络2406:da00:ff00:0000(IPv6)上发到/来自所有主机的数据流

    ·         not dst net 10.3.0.0/16:抓取除了发到以10.3开头的IP地址以外的所有数据流

    ·         not src net 10.3.0.0/16:抓取除了来自以10.3开头的IP地址以外的所有数据流

    ·         ip proto <protocol code>:抓取ip协议字段等于<protocol code>值的报文。如TCP(code 6), UDP(code 17), ICMP(code 1)

    ·         ip[2:2]==<number>ip报文大小

    ·         ip[8]==<number>TTL(Time to Live)

    ·         ip[9]==<number>:协议值

    ·         icmp[icmptype]==<identifier>: 抓取 ICMP代码等于identifierICMP报文, icmp-echo 以及 icmp-request

    方括号中第一个数字表示从协议头开始的偏移量,第二个数字表示需要观察多少位。

    image004.png

     

    抓取发到广播或多播地址的数据流:

     

    只需侦听广播或多播数据流,就可以掌握网络上主机的许多信息。

    ·         ip broadcast:抓取广播报文

    ·         ip multicast:抓取多播报文

    ·         dst host ff02::1:抓取到IPv6多播地址所有主机的数据流

    ·         dst host ff02::2:抓取到IPv6多播地址所有路由器的数据流

     

    小贴士:

    Wireshark包含了一些默认的抓包过滤条件。点击主工具栏的Edit Capture Filters,跳转到已保存抓包过滤列表。你会发现一些常见抓包过滤的示例。

     

    抓取基于MAC地址的数据流:

     

    当你需要抓取发到/来自某一主机的IPv4IPv6数据流,可创建基于主机MAC地址的抓包过滤条件。

    应用MAC地址时,需确保与目标主机处于同一网段。

    ·         ether host 00:08:15:00:08:15:抓取发到/来自00:08:15:00:08:15的数据流

    ·         ether src 02:0A:42:23:41:AC抓取来自02:0A:42:23:41:AC的数据流

    ·         ether dst 02:0A:42:23:41:AC:抓取发到02:0A:42:23:41:AC的数据流

    ·         not ether host 00:08:15:00:08:15:抓取除了发到/来自00:08:15:00:08:15以外的所有数据流

    ·         ether broadcastether dst ff:ff:ff:ff:ff:ff:抓取广播报文

    ·         ether multicast:多播报文

    ·         抓取指定以太网类型的报文:ether proto 0800

    ·         抓取指定VLANvlan <vlan number>

    ·         抓取指定几个VLANvlan <vlan number> and vlan <vlan number>

     

    抓取基于指定应用的数据流:

     

    你可能需要查看基于一个或几个应用的数据流。抓包过滤器语法无法识别应用名,因此需要根据端口号来定义应用。通过目标应用的TCPUDP端口号,将不相关的报文过滤掉。

    ·         port 53抓取发到/来自端口53UDP/TCP数据流(典型是DNS数据流)

    ·         not port 53抓取除了发到/来自端口53以外的UDP/TCP数据流

    ·         port 80:抓取发到/来自端口80UDP/TCP数据流(典型是HTTP数据流)

    ·         udp port 67:抓取发到/来自端口67UDP数据流(典型是DHCP据流)

    ·         tcp port 21抓取发到/来自端口21TCP数据流(典型是FTP命令通道)

    ·         portrange 1-80:抓取发到/来自端口1-80的所有UDP/TCP数据流

    ·         tcp portrange 1-80:抓取发到/来自端口1-80的所有TCP数据流

     

    抓取结合端口的数据流:

     

    当你需要抓取多个不连续端口号的数据流,将它们通过逻辑符号连接起来,如下图所示:

    ·         port 20 or port 21抓取发到/来自端口2021UDP/TCP数据流(典型是FTP数据和命令端口)

    ·         host 10.3.1.1 and port 80:抓取发到/来自10.3.1.1端口80的数据流

    ·         host 10.3.1.1 and not port 80:抓取发到/来自10.3.1.1除了端口80以外的数据流

    ·         udp src port 68 and udp dst port 67:抓取从端口68到端口67的所有UDP数据流(典型是从DHCP客户端到DHCP服务器)

    ·         udp src port 67 and udp dst port 68:抓取从端口67到端口68的所有UDP数据流(典型是从DHCP服务器到DHCP客户端)

    ·         抓取TCP连接的开始(SYN)和结束(FIN)报文,配置tcp[tcpflags] & (tcp-syn|tcp-fin)!=0

    ·         抓取所有RST(Reset)标志位为1TCP报文,配置tcp[tcpflags] & (tcp-rst)!=0

    ·         less <length>:抓取小于等于某一长度的报文,等同于len <=<length>

    ·         greater <length>:抓取大于等于某一长度的报文,等同于len >=<length>

     

    SYN: 简历连接的信号

    FIN: 关闭连接的信号

    ACK: 确认接收数据的信号

    RST: 立即关闭连接的信号

    PSH: 推信号,尽快将数据转由应用处理

     

    ·         tcp[13] & 0x00 = 0: No flags set (null scan)

    ·         tcp[13] & 0x01 = 1: FIN set and ACK not set

    ·         tcp[13] & 0x03 = 3: SYN set and FIN set

    ·         tcp[13] & 0x05 = 5: RST set and FIN set

    ·         tcp[13] & 0x06 = 6: SYN set and RST set

    ·         tcp[13] & 0x08 = 8: PSH set and ACK not set

    tcp[13]是从协议头开始的偏移量,0,1,3,5,6,8是标识位。

    image005.png

     

    尽量避免使用抓包过滤。即便多看几个报文,也比漏看一个报文要好。当你抓取了大量报文的时候,用显示过滤(过滤选项也更多)来重点查看某一数据流。

     

    小贴士:

    如果你需要查看TCP帧中的某一ASCII字符串,用Wireshark String-Matching Capture Filter Generator(http://www.wireshark.org/tools/string-cf.html)。例如,想要抓取HTTP GET报文,输入GET并将TCP偏移量设置为0

     

     

     

     

                 

  • 43. Re: 如果看了这个你还是不会用Wireshark,那就来找我吧(7月22日更新)
    happydanye

    To 沛满:非常感谢,受益良多。

    我们这个网络涉及电信和移动的互联互通,我们怀疑是电信动了手脚(有先例,不过那次是整个断了,这次电信升级了手段?)