为什么数据包丢失会影响性能?
不可不使用
适用场景
- 所有 NetApp 产品
- TCP 通信
- CIFS , NFS 和 iSCSI
问题解答
- 数据包丢失会对发生原因性能产生多种影响
- 本文的目标是介绍数据包丢失通常是如何导致性能问题的,而不是发生丢失的原因
- 当发现数据包丢失时、拥塞算法会限制网络上的 TCP 数据量以防止进一步丢失。
- 此算法设置的限制是拥塞窗口(cwin)、在有损网络中、平均拥塞窗口用于查看丢包前发送的数据量。
- Badwidth Delay Product (Badwidth延迟产品、BDEP)将此拥塞窗口与往返时间关联起来、以提供平均预期吞吐量。
- 数据包丢失后,接收方将停止响应新数据包,直到重新传输为止,从而导致延迟可能长达半秒。
- 要查看Wireshark标记为重新传输的数据包:
tcp.analysis.retransmission
- 某些系统会标记 一个名为 sack (例如 ONTAP )的 TCP 标志,此标志可用于标识一次缺少多少个数据包。
- 通过此筛选器,您可以查看以下数据包:
tcp.options.sack.count > 0
- 通过此筛选器,您可以查看以下数据包:
追加信息
-
定义
-
-
数据链路容量(以每秒位数为单位)及其往返延迟时间(以秒为单位)的乘积
-
结果是以位(或字节)为单位测量的数据量,相当于任意给定时间网络电路上的最大数据量,即已传输但尚未确认的数据
-
带宽延迟产品可通过将端口链路速度(以每秒位数为单位)除以 10 来估算,并在交换机中承受负载的往返时间 - 通常按 1 毫秒左右的顺序排列: 40 Gbps / 10 ~ = 4 GB/ 秒 * 0.001 秒 = 4.2 MB 缓冲区内存
-
往返时间不仅包括线路传播延迟和交换机延迟,还包括交换流量时交换机,主机或存储系统内的任何缓冲
-
在不同链路速度之间切换的交换机应在参与端口上提供此范围内的缓冲区内存。
-
-
-
接收窗口:
-
通信吞吐量受两个窗口限制:拥塞窗口和接收窗口
-
拥塞窗口尝试不超过网络容量(拥塞控制);接收窗口尝试不超过接收器处理数据的容量(流量控制)
-
例如,如果数据非常繁忙(例如 Web 服务器),则接收方可能会被数据覆盖
-
每个 TCP 分段都包含接收窗口的当前值
-
例如,如果发件人收到确认字节 4000 并指定接收窗口 10000 (字节)的 ack ,则即使拥塞窗口允许,发件人也不会在字节 1400 之后发送数据包
-
-
-
在TCP中、拥塞窗口是决定可随时发出的字节数的因素之一
-
拥塞窗口由发件人维护
-
请注意,这一点不能与接收器维护的滑动窗口大小相混淆
-
拥塞窗口可防止发送方和接收方之间的链路因流量过多而过载
-
它是通过估计链路上的拥塞量来计算的。
-
-
-
这是由发件人发送的字节数,用于确认字节数的接收方以及用于接收确认的发件人所需的时间
-
通常以毫秒(毫秒)为单位进行说明
-
-
在 ONTAP 9.1 及更低版本(包括 Data ONTAP 8 )或 9.5 及更高版本中, netstat 命令将具有一个 retransmit 列。
-
在 ONTAP 9.1 及更低版本中,它称为
Retransmits
-
在 ONTAP 9.5 及更高版本中,它称为
Rexmit
-
在此处检查是否增加了重新传输也会很有用(并且可能比创建跟踪,安装和查看数据更快)。