freedom2
1 Copper

Re: 网络基本功系列:细说网络那些事儿(1月28日更新)

你好,我有一个问题,比如有5个分片,序号从1开始。

当分片1,2都收到并且返回ACK后,分片3丢失,分片4,5接续被收到,之后分片3被重发后收到,为什么这是ACK里的序号还是1呢?

另外,为什么会出现SEQ相同,而ACK Number不同的ACK报文呢?

谢谢!

0 项奖励
Zhang_Jiawen
4 Beryllium

Re: 网络基本功系列:细说网络那些事儿(1月28日更新)

有抓包吗?

0 项奖励
freedom2
1 Copper

Re: 网络基本功系列:细说网络那些事儿(1月28日更新)

没有抓包,只有一个图,如下

Capture.PNG.png

另外的那个问题:为什么会出现SEQ相同,而ACK Number不同的ACK报文呢?应该是Wireshark的TCP segment of a reassembled PDU问题。应该是数据超出了TCP的最大MSS,导致在TCP层被分片。


谢谢!

0 项奖励
Zhang_Jiawen
4 Beryllium

Re: 网络基本功系列:细说网络那些事儿(1月28日更新)

你好,我有一个问题,比如有5个分片,序号从1开始。

当分片1,2都收到并且返回ACK后,分片3丢失,分片4,5接续被收到,之后分片3被重发后收到,为什么这是ACK里的序号还是1呢?

这里ACK的序列号SEQ是1。TCP是双向的,一个连接中双方都各自维护了一个序列号。每一个报文的SEQ=上一个报文的SEQ+LEN。这张图上接收方每次发送数据LEN为0,所以每次SEQ就等于上一次的SEQ+0,就一直为1.

另外,为什么会出现SEQ相同,而ACK Number不同的ACK报文呢?

发送窗口决定了一次能发送多少字节,而MSS决定了这些字节分多少个包发完。发送方在一个窗口里发送多个包,但TCP是累积确认的,所以确认包会少一些。ACK=接收到的SEQ+LEN。所以ACK是不一样的。

0 项奖励
Highlighted
Zhang_Jiawen
4 Beryllium

Re: 网络基本功系列:细说网络那些事儿(1月28日更新)

网络基本功(二十四):Wireshark抓包实例分析TCP重传

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

介绍

TCP发送一个或一组报文,会等待收到报文的确认信息。重传,即发生在报文没有到达或确认信息没有及时返回的情况下。当发现网速变慢时,原因之一可能就是重传。发生重传的原因有多种,在客户机或服务器两边端口应用Wireshark有助于诊断问题。本文通过抓包实例阐述各种可能性。


更多信息

诊断过程:

  1. 在相应端口开始抓数据。
  2. 找到Analyze | Expert Info菜单。
  3. Notes之下,查找Retransmission
  4. 点击(+)符号即可打开重传列表。鼠标点击各行可在抓包面板看到重传报文。
  5. 现在问题来了,怎样定位问题呢?
  6. 通过以下方式查看重传来自哪里:
  • Expert Info窗口一个一个查看报文,在抓包面板查看哪些是重传报文(适合于有经验的用户)
  • 在报文面板,配置显示过滤器expert.message == “Retransmission (suspected)”,即可看到抓包文件中所有重传报文
  • 应用过滤器,在Statistics & Conversations窗口查看Limit to display filter部分。

Case 1:重传至多个目的地址

以下截屏中,可看到有多次重传,分布于多台服务器,目的端口号为80HTTP)。也可以发现重传由端口10.0.0.5发送,因此报文是丢失在发往Internet的途中,或确认信息没有及时从web服务器发回。

image002.jpg

问题发生在发往Internet的线路上,怎样知道是什么问题呢?

  1. Statistics菜单,打开IO Graph
  2. 本例中,可看到链路负载非常低。可能是有故障,或有另一条高负载链路。
  3. 可以通过登录到通信设备或SNMP浏览器查看引起重传的原因:报文丢失及错误。参考以下截屏:

image003.jpg

Case 2:重传至单一连接

如果所有重传发生于同一IP,同一TCP端口号,则可能是慢速应用引起。看以下截屏:

image004.jpg

对于单一连接的重传,进行以下操作:

  1. Statistics菜单打开Conversations,选择Limit to display filter,可以看到所有发生重传的会话,本情况下,是一个单一会话。
  2. 如下图所示,通过选择IPv4标签可看到从哪个IP地址重传:

image005.jpg

   3.  如下图所示,通过选择TCP标签看到重传来自哪一端口:

image006.jpg

要定位问题,进行以下步骤:

  1. 查看IO graph,确保链路不忙。(链路忙的表征例如流量接近带宽。例如,带宽为10Mbps,在IO graph中看见流量接近10Mbps,这就表明链路负载较高。不忙的链路IO会有很多高低起落,峰值以及空闲间隙)。
  2. 如果链路不忙,则可能是服务器对于IP地址10.1.1.200有问题(10.90.30.12发送了绝大多数重传,所以可能是10.1.1.200响应较慢)
  3. 从报文面板可以看出应用是FTP数据。有可能FTP服务器工作于active模式。因此在端口2350打开连接,服务器将端口更改为1972,所以可能是慢速FTP软件响应问题引起的重传。

Case 3:重传模式

观察TCP重传的一个重要考量是是否能看出一些重传模式。在以下截屏中,可以看见所有重传来自单一连接,位于客户端与服务器的NetBIOS会话服务(TCP端口139)。

image007.jpg


看起来像一个简单的服务器/客户端问题,但查看抓包面板,如下图所示:

image008.jpg

可以看见重传总是周期性的每30ms发生一次。问题是由于客户端在软件中执行了财务进程,导致软件每30-36ms就减速一次。

Case 4:应用无响应导致重传

另一个可能导致重传的原因是客户端或服务器没有响应请求。这种情况下,会看到五次重传,时间也会逐渐延长。五次连续重传后,发送方认为连接断开(某些情况下,会发送reset来关闭连接,取决于软件实施)。断开连接之后,可能会发生两件事情:

  • 发送SYN请求至客户端,以打开一个新的连接。这种情况下用户会看到应用冻结,过了15-20秒之后重新开始工作。
  • 不发送SYN,用户需要重新运行应用程序(或应用程序的一部分)

下图显示了打开新连接的情况:

image009.jpg

Case 5:由于延时变化导致重传

TCP能够充分容忍延时,前提是延时大小不发生变化。当延时改变时,就会发生重传。诊断是否由该原因引起的方法:

  1. 第一件事是ping目的地址,并且得到检查通信链路延时的第一条信息。
  2. 检查延时变量,可能由以下原因引起:
  • 由于不稳定或繁忙通信链路引起。这种情况下,可以看到ping命令的延时变化,通常由于带宽较窄。
  • 由于应用过载或资源不足,这种情况下,只有该应用发生很多重传。
  • 通信设备过载(CPU,缓存)引起延时。检查方式直接连接通信设备。

   3.  使用Wireshark工具诊断延时问题。

如果重传达到0.5个百分比,性能就会下降,断开连接将会达到5个百分比。这取决于应用及其对于重传的敏感性。

定位重传问题

当你看到通信链路上发生重传,进行以下步骤:

  1. 定位问题——是一个特定IP地址,特定连接,特定应用,还是其他问题。
  2. 查看问题是否由于通信链路,丢包,慢速服务器还是PC。查看应用是否慢速。
  3. 如果不是由于上述原因,检查延时变化。

工作原理:

TCP序列号/确认机制详见前文:网络基本功(十):细说TCP确认机制 。那么重传是由什么原因引起呢?当报文确认信息丢失,或ACK没有及时到达,发送方会进行以下两步操作:

  1. 再次发送报文
  2. 减少吞吐量。


更多TCP重传内容详见前文:网络基本功(九):细说TCP重传


以下图中展示了重传减少发送方吞吐量(红色细线):

image010.jpg

参考

Network Analysis Using Wireshark Cookbook

             

0 项奖励
freedom2
1 Copper

Re: 网络基本功系列:细说网络那些事儿(1月28日更新)

谢谢!

0 项奖励
angeloyan
1 Nickel

Re: 网络基本功系列:细说网络那些事儿(1月28日更新)

从头到尾挑自己感兴趣的看了一遍,支持下楼主

0 项奖励
Zhang_Jiawen
4 Beryllium

Re: 网络基本功系列:细说网络那些事儿(1月28日更新)

谢谢支持!

0 项奖励
angeloyan
1 Nickel

Re: 网络基本功系列:细说网络那些事儿(2月3日更新)

有个问题想请教一下,比如说连接在同一台交换机下的多个设备,不管他们的IP地址是否相同或者不在同一网段,理论上如果二层通讯的话只需要知道mac地址就行了,那我考虑是否可以发送一个类似于arp的二层广播包(包数据自定义),收到这个自定义数据的二层广播包的设备回复自己的mac地址,这样就可以跟同一交换机下的能够理解这个自定义二层广播包的设备通信了,而不用管他们的IP是怎么设置的。不知道我的这个想法有没有问题?如果想法没问题的话,如何通过编程实现?(貌似对二层数据的封包和拆包是操作系统干的事情,难道像linux这样开源的要修改操作系统内核才能实现?还是有什么编程语言能够实现二层数据的收发,感觉不太现实啊),这些都是我看到有的交换机出厂默认IP都一样,可以用厂商提供的工具直接修改交换机的ip想到的,有点疑惑,所以想请教一下。

问题有点长

0 项奖励
Zhang_Jiawen
4 Beryllium

Re: 网络基本功系列:细说网络那些事儿(2月3日更新)

一般二层数据收发是通过主板上的二层交换芯片来完成的,通过软件实现协议栈理论上没什么问题,C语言就可以。但是会非常非常缓慢。。。

0 项奖励