Eri*_*own 5 networking internet tcp satellite
我一直在尝试解决 TCP 重传率非常高的网络问题。36 个样本（使用在 32 位 Windows 7 上运行的 Wireshark 1.10.8 获取）总计略多于 7 个小时，每个样本持续 2 到 53 分钟，显示重传占用总入口带宽的 43% 到 61%。
让我感到困惑的是，据我所知，此类问题只有两个原因：丢包的不稳定链路和拥塞。我相信我已经排除了这些可能性。让我列出我们的情况，我很乐意听取比我更有知识的人关于解决问题的其他调查方向的意见。
该网络位于海上的一艘船上。它使用卫星链路与互联网进行通信。不幸的是，这种类型的链路的带宽成本非常高，因此我们只能使用 1Mbps 下行/512kbps 上行连接。作为卫星链路，它的 ping 时间约为 650 毫秒。目前，我们船上大约有 300 人，全部共用该管道。
该网络由两个 VLAN 组成（一个用于船上计算机，另一个用于访客）。两个 VLAN 均通过管道传输至 SonicWall TZ 215（运行 SonicOS 增强版 5.8.1.2-6o），该 SonicWall TZ 215 控制通往 Internet 的管道。两个 VLAN 都有有线和无线客户端。有线网络由一系列 Cisco 2900 千兆交换机运行。无线网络由众多思科 AP 提供（海上钢船上的信号传播非常糟糕）。
我的第一个想法是这是一个拥塞问题，因此我寻求了各种解决方案（阻止视频聊天和流媒体等高带宽服务，窃听公司办公室支付更大的管道费用等）。遗憾的是，我们没有得到更大的管道。其他事情有一点帮助，但不足以产生真正的影响。
但这个周末我又回到了原点。队长要求我在演习期间禁止访客访问互联网。我利用这个机会在网络不拥塞时使用 Wireshark 捕获了网络。令我惊讶的是，10 分钟的样本显示 TCP 重传率与所有其他捕获几乎相同 - 58%。在该样本的持续时间内，平均带宽使用率为 98kbps，因此绝对不拥堵。
这使得数据包丢失成为可能的原因。为了测试这一点，我运行了 12 个小时的 ping。最后，该程序报告丢包率低于 1%。
哪个留下...什么？我不知道。任何额外的想法将不胜感激。