我一直在尝试解决一个网络问题，该问题表现为 TCP 重传率非常高。36 个样本（使用在 32 位 Windows 7 上运行的 Wireshark 1.10.8 采集）总计超过七个小时，每个样本持续 2 到 53 分钟，显示重传占用了总入口带宽的 43% 到 61%。
让我困惑的是，据我所知，这种问题只有两个原因：丢包的不稳定链接和拥塞。我认为我已经排除了这些。让我来描述一下我们的情况，我很想听听比我更有知识的人对解决问题的其他方向的看法。
有问题的网络位于海上的一艘船上。它使用卫星链路与互联网通信。不幸的是，这种类型的链路的带宽成本非常高，所以我们只能使用 1Mbps 下行/512kbps 上行连接。由于是卫星链路，它的 ping 时间约为 650ms。目前，船上大约有 300 人，所有人都共用这条管道。
网络由两个 VLAN 组成（一个用于船上的计算机，另一个用于客人）。两个 VLAN 都通过管道连接到 SonicWall TZ 215（运行 SonicOS Enhanced 5.8.1.2-6o），该设备控制通向 Internet 的管道。两个 VLAN 都有有线和无线客户端。有线网络由一系列 Cisco 2900 千兆交换机运行。无线网络由众多 Cisco AP 提供（海上钢船中的信号传播非常糟糕）。
我首先想到的是这是一个拥塞问题，所以我寻求了各种解决方案（阻止视频聊天和流媒体等高带宽服务，催促公司办公室支付更大的管道费用等）。遗憾的是，我们没有得到更大的管道。其他方法有点帮助，但不足以产生真正的影响。
但这个周末，我又回到了原点。在一次演习中，船长要求我禁用访客上网。我趁机用 Wireshark 截取了网络，当时不是拥塞。令我惊讶的是，10 分钟的样本显示 TCP 重传率几乎与所有其他捕获相同 - 58%。在该样本的持续时间内，平均带宽使用率为 98kbps，因此肯定不是拥挤。
由此看来，数据包丢失可能是唯一的原因。为了测试这一点，我运行了 12 个小时的 ping。最后，程序报告的数据包丢失率不到 1%。
剩下的...是什么？我不知道。如果有任何补充想法，我将不胜感激。
答案1
检查网络之前的所有事项。例如：卫星链路不稳定。可能是该侧物理层面上的任何原因 - 校准不良，等等。
根据福尔摩斯的方法，这是唯一剩下的东西。数据包丢失是因为它们丢失了。
答案2
检测丢失的一个好方法是使用 UDP 数据包流（有各种工具可以做到这一点，主要用于 QoS 测试）。您可以改变大小、频率、延迟。它应该会显示您是否有实际丢失。
答案3
为了测试这一点，我运行了 12 个小时的 ping。最后，程序报告的数据包丢失率不到 1%。
Ping 使用 ICMP 数据包 - 即互联网控制消息协议。ICMP 旨在确保流量流动（即告诉其他机器如何路由流量），因此设备必须使 ICMP 优先于其他数据包类型。
即这是检测拥塞的最糟糕的方法。
答案4
同意 ping 测试，设置 DF 位，看看您的 MTU 上限在哪里。流量是否封装？我想是的，通过 SAT 封装，这将进一步减少流量。当我读到 1Mbps 的用户数量时，我流下了眼泪……上传饱和将进一步影响它。我知道您无能为力，但考虑到如今网页的设计方式，您正在打一场必败之战。我们试图将公共无线服务限制为每个客户端 256kbps，但体验并不好，我甚至无法想象今天用 56k 调制解调器加载页面，而您的请求是 15 比 1。