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

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

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

验证过程:首先断掉客户端重连,用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

0 项奖励
Highlighted
bairichard1
2 Iron

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

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的……这个说起来太复杂了。

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

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

0 项奖励
______5
1 Nickel

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

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

0 项奖励

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

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

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

0 项奖励
happydanye
1 Copper

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

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

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

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

0 项奖励
happydanye
1 Copper

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

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

0 项奖励

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

先回答这个问题:

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

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

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

0 项奖励

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

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.减小吞吐量。

0 项奖励

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

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

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

0 项奖励