为什么数据包丢失会影响性能？

最后更新
另存为PDF

Knowledge Base guidance

This article may include metadata, visibility, validation state, and related support guidance.

适用场景

所有NetApp产品
TCP通信
CIFS、NFS和iSCSI

问题解答

丢包会影响发生原因性能的原因有很多
本文的目标是介绍数据包丢失通常是如何导致性能问题的、而不是发生丢失的原因
- 发现数据包丢失时、拥塞算法会限制网络上的TCP数据量、以防止进一步丢失。
  - 升级到9.6及更高版本后读取性能不佳- NetApp知识库
- 此算法设置的限制是拥塞窗口(cwin)、在有损网络中、平均拥塞窗口用于查看丢包前发送的数据量。
- 带宽延迟产品(b带宽延迟产品)(bected Delay Product、bDEP))会将此拥塞窗口与往返时间关联起来、以提供平均预期吞吐量。
- 当数据包丢失时、接收器会停止响应新数据包、直到重新传输为止、从而导致延迟可能持续长达半秒。
要查看哪些数据包已被确认为重新传输，请执行以下操作：
- 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、则即使拥塞窗口允许、发送方也不会在字节4000之后发送数据包
- 拥塞窗口：
  - 在TCP中、拥塞窗口是决定可随时发出的字节数的因素之一
  - 拥塞窗口由发送方维护
  - 请注意、不要将其与接收器维护的滑动窗口大小相混淆
  - 拥塞窗口是一种阻止发送方和接收方之间的链路因过多流量而过载的方法
  - 它是通过估计链路上的拥塞程度来计算的。
- 往返时间(RTT)：
  - 这是发送方、接收方确认字节数和发送方接收确认所需的字节数
  - 通常以毫秒(ms)为单位

在ONTAP 9.1及更低版本(包括Data ONTAP 8)或9.5及更高版本中，netstat命令将具有一个“重新传输”列。

在ONTAP 9.1及更低版本中、称为 Retransmits
在ONTAP 9.5及更高版本中、称为 Rexmit
在此检查增量重新传输也会很有用(可能比创建跟踪、安装和查看更快)。