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