我们有 Mac（无论操作系统版本如何，结果都一样）最终用户，他们在 LAN 上遇到了 Mac 下载速度慢的问题。开始下载时，文件的下载时间不断增加，需要很长时间才能完成下载。有时，下载会超时。我们使用 Windows 的用户不会遇到此问题。Mac 通过以太网连接。即使 Mac 连接到 Wifi，下载仍然像连接到以太网时一样运行。当使用 Mac 进行离线下载时，它可以顺利下载，没有任何问题。问题似乎出在我们的网络中，导致 Mac 下载问题，但我们似乎无法弄清楚是什么问题，也无法找出导致问题的原因。任何帮助解决此问题的帮助都将不胜感激。哪些可能的原因会导致 LAN 上的 Mac 下载速度慢？我不明白为什么它只影响 Mac 机器而不影响 Windows 机器。
最初，我认为可能是 Mac（Mountain Lion OS X 10.8.5）上的主机配置导致了此问题，因此我格式化了驱动器并安装了 El Capitan，但下载时间相同。然后，我在 Mac 和 Windows 上进行了数据包捕获，试图比较可能导致此问题的原因，但我不太熟悉如何分析数据包捕获。通过查看我所知甚少的捕获，我可以看到两者之间的一些连接重置。我甚至还在 Mac 上进行了离线数据包捕获，试图查看在离线下载期间它可能会做哪些不同的事情。有没有办法我可以发布捕获的片段，以便有人可以帮助我分析它，看看是什么可能导致网络上的问题？
答案1
我们最接近的数据包捕获片段服务可能是 CloudShark。
重置很有趣，这可能是您在 OS X 机器上感觉运行缓慢的原因。为了解释原因，我们必须详细了解速度的选择方式。这是基于TCP 滑动窗口，附带带宽延迟积。
给定网络连接的绝对吞吐量由几个因素决定：
- 数据包的传输速度有多快。
- 数据包到达目的地需要多长时间。
- 发送方愿意留下多少未完成（未确认）的数据。
横跨美国的 1GbE 连接单向延迟约为 80ms。由于确认是这里的一个因素，我们必须计算它们的返回时间。因此，往返时间为 160ms。如果 1GbE 连接以全速传输，则在 160ms（1024Gb x .16 秒）内，可以有 20MB 的数据“未完成”。
协商 TCP 连接时，双方握手时要考虑的参数之一是 TCP 窗口的大小。这是第三个要点：发送方愿意留下多少未确认的数据，以及接收方接收数据的缓冲区大小。在传输数据时，双方都会发布关于他们愿意容忍多大窗口的更新。对于快速、干净的网络，这个窗口可能会变得非常大。
但是，如果由于某种原因连接被重置，则该过程将以原始窗口大小重新开始。如果窗口已满，发送方将停止发送，直到这些 ACK 返回。您开始明白为什么连接重置会导致性能问题。
我想提一下这件事的另一个方面，因为我以前见过它导致这种问题。你没有提到你看到了它，但如果你看的话，你可能会看到它们。重新传输。
TCP 初始规范中的新增内容之一是选择性致谢。如果出现数据包丢失，而不是连接重置，则此方法会发挥作用。如果没有 SACK，如果我之前提到的 1Gb、160ms RTT 连接出现数据包丢失，则接收方将坐在那里，在发送方重新发送丢失的数据包之后，将 20MB 的数据丢弃在地板上。这种行为对于我们 1989 年的网络类型来说没问题，但我们当前的网络要快得多，而且更胖。SACK 允许接收方说“我已看到时间戳 123 和 125-137”，这允许发送方仅重新传输丢失的 124 段并继续处理其余部分。
我有确实见过一些案例，连接上缺少 SACK 支持会导致吞吐量非常糟糕。一旦我们在两端都启用了 SACK 支持，性能就会达到理论上的最大值。
这个问题的线索可以在初始 TCP 三次握手中找到。您应该在双方的选项标头中看到 SACK。如果 OSX 计算机没有发出 SACK，但 Windows 发出了，那么您就对问题有了很大的线索。