过多的“TCP Dup ACK”和“TCP快速重传”导致networking上的问题。 这是什么原因造成的？

刚才发布了我发现的内容。 地铁以太网服务提供商在周六前往我们的总部。 他们断开了那里的networking，在附近的一个分支也有人。 他们连接了两端的networkingtesting设备，很快就能确定是否存在问题。 几个小时后，他们能够隔离问题。 从供应商中心办公室到我们的主要办公室的铜线是一个问题。 他们说框架正在疯狂下降，这是造成转播的原因。 他们在中央办公室用铜线来解决这个问题（他们说他们必须一次一根地拉开每根电线，听起来像是BS），但是在他们的中央办公室里这样做后，问题就解决了。

我意识到这个答案是简化的，并不像我希望的那样明确，所以如果你有关于一个步骤的问题，请问！

在Wireshark打开这个文件后向下滚动一下，我们看到一些不同颜色的帧。 看起来很糟糕，对吧？ 那么，这不是那么糟糕。 等一下，我们会到达那里。

检查SYN数据包（第37帧），我们看到TCP选项中的SACK和窗口缩放。 好。 同样的事情在SYN / ACK（帧38），SACK和Windows缩放。 真棒。 没有看到什么奇怪的SACK。

卸载的RTT的估计是SYN数据包和第一个ACK（帧39）之间的时间。 这大约是9.3毫秒，与您的发现相符。 请注意，SYN / ACK和ACK（帧38和39）之间的时间比SYN和SYN / ACK（37和38）之间的时间要低得多。 这意味着，这个捕获文件是在接收器，并看看为什么这不理想，我们将不得不回到学校。

在发送者和接收者之间，有一部分networkingpath是最小的，这限制了带宽。 我们刚刚从握手中获得的RTT估计给了我们对这个networkingpath长度的估计。 我们可以在这个pipe道中容纳多less个数据包的测量值是pipe道容量或带宽延迟乘积 ，即PC [bits] = R [bits / s] * RTT [s]，其中R是最小的带宽。 然后pipe道容量是一个体积的测量。

想象一下花园软pipe。 它的体积测量是由它的长度和宽度以同样的方式定义的？ 为了获得最多的水，需要将水完全充满，否则会有气隙限制水stream。 如果我们设法完全填充它，它可能会溢出。 我们可以使用一个水桶，这样我们就不会弄湿地板，如果水桶溢出，不会影响水stream。

事实certificate，在networkingpath中完全一样。 我们需要填充pipe道…换句话说，pipe道容量是发送器和接收器之间的最小字节（在pipe道+桶中有多less水），充分利用最小的带宽（不会导致气隙）。 所以如果在飞行中的字节> PC，那么我们是好的！

查看TCP跟踪 统计信息 – > TCP StreamGraph – >时序图（tcptrace），我们可以在Y轴上看到字节，在X轴上看到时间。 这条曲线的导数是字节/秒，或吞吐量。 注意黑色“线”是如何平坦的，这意味着吞吐量是稳定的！ 尽pipe它被蓝线中断（这些是重复ACK中的SACK范围），但是可以看出，它不影响吞吐量。

看看右下方的灰色实线（放大一点，就是ACK）是否真的接近黑色的TCP段？ TCP段和ACK之间的时间是RTT，这几乎是0！ 这意味着在飞行中没有多less段通过这个捕捉点。 这反过来意味着我们不能使用它来估计正在飞行的字节，这就是为什么发送端数据包捕获更好。

这里的数据包自然会在捕获点之前丢失。 在丢失时正在运行的每个数据段都会触发重复的ACK。 因此，我们可以使用重复的ACK数量来估计丢包时的在飞行中的字节数。 在这里，我们看到大约9,16和23段。 每个段有1448字节的数据，所以这给我们一个13k和33k之间的字节。 这里的吞吐量大约是3 Mbit / s（来自IO图 ），并且在我们得到pipe道容量小于3e6 [bits / s] * 10e-3 [s] / 8 bytes = 3750字节之前测量的RTT，或者less于3个部分。

由于在这些损失时飞行中的字节不是真的一样（很难说这里有这么less的样本），我真的不能说这些是否是随机损失（坏坏坏）或损失发生，因为一个队列/桶溢出，但在飞行中的字节> PC时发生，因此吞吐量不受影响。

你的回答似乎表明，它们确实是随机的，但并不是太多会导致低吞吐量。

看看你提供的捕获（谢谢你这样做！）我可以看到一个非常经典的转发模式开始。 你可以在数据包50中看到它。在51到52之间有一个丢失的数据包。发生什么事情是这样的：

1. – >数据包50数据
2. – 分组51的ACK分组50。
3. – >数据包52数据
4. – 分组53包ACK 50。
5. – >数据包54数据
6. <分组55的ACK分组50

一个数据包被丢弃了，接收者通过继续确认数据包到目前为止所看到的数据包。 这里有趣的是双方在协商连接时TCP SACK Permitted Option = True ，所以数据包55应该有一个SACK头，而不是。 select性的确认允许接收者指出“我已经看到了所有高达51，但也53-55”，这减less了所需的重新传输的数量，以恢复全速。

发生什么事情，因为它不能使用SACK，它是回到标准的TCP重发方法重复“我见过多达50”，直到对方计算出来，并重新发送所有50和更晚。

在分组66中有一个重传，紧接着一个ACK直到分组56.在第二次重传（分组72）之后，连接重新开始。

首先，看起来SACK头部可能会被sonicwalls剥离出来，从而阻止了重新恢复，就像他们协商的那样快。 就我个人而言，我认为SACK剥离是毫无意义的，但其他人可能不同意。

根据我所知道的这个捕获，你偶尔会看到丢包，这导致TCP连接通过正常的重传协议。 防火墙正在阻碍双方协商的重传方式不被允许。