我是一名新晋系统和网络管理员。我的经验主要集中在系统和服务器的硬件和软件方面，网络部分对我来说相当新。我熟悉将数字插入网络配置，但如果您问我有关子网划分或数据包丢弃 (;) 的问题，您会看到我脸上闪过一丝非常迷茫的表情。我正在学习。
这是我的问题：
在接管这里的网络管理员大约两个月前，他们就报告说，他们在下载大型文件时遇到了问题。其实，不仅仅是大型文件，大型文件更令人沮丧。现在我负责下载（从随机驱动程序到 Technet 订阅和许可协议中的最新发行版和 SP，再到我们各个部门的数 GB 工程软件包），我必须“照看”下载，每次都要在办公桌前呆上几个小时。
如果我不暂停并重新启动下载，在下载失败之前，下载会顺利开始，并达到从几 K 到几 G 的随机点，然后下载会停滞并失败。有时暂停/重新启动会立即起作用，下载会加快速度并取得一点进展，然后循环重复。有时我必须经历几次暂停/重新启动循环，下载才会真正开始再次下载。
网络和 ISP 详细信息：
- 我们的 ISP（我们当地的城市就是我们的 ISP）提供光纤互联网连接。下载速度通常稳定在 1.1Mbps 左右，峰值最高可达 1.6Mpbs。有时在暂停/重启周期中，我们会看到速度低至几百 Kbps，但几个周期后速度又会加快。不同主机的速度相当一致。
- 我们的内部网络中没有代理，而且据我所知没有防火墙阻止连接。我们使用 Cisco 1811W 作为网关，但之前没有遇到任何问题。
该问题最早是在九月份左右被发现的，当时我们这边没有做出任何可以归咎于此的变化。
我应该进行什么测试、检查等来确定问题出在我们这边还是 ISP 身上？
更新：
我正在查看 wireshark feed，它过滤了几天来一直困扰我的大型下载的 TCP 流。大多数流量帧都标记为...
持续或非 HTTP 流量
...我假设这只是构成下载的后续数据包。但是，相对频繁（每 3-20 秒之间）且与 Firefox 报告的下载速度下降几乎完全对应的是标记为... 的大段帧
[TCP 重传] 连续或非 HTTP 流量
还有一些随机帧，通常分散在重传数据包周围，两侧有几十帧，标记为......
[TCP 上一个段丢失] 连续或非 HTTP 流量
...你知道吗，下载到 3.2GB 的文件一半时就失败了。最后一帧是 TCP Previous Segment Lost 帧。这是在我不得不暂停下载并尝试重新启动后立即发生的：队列立即失败。
下载的最终帧为http [确认]其次是http [FIN，确认]，我相信这表明 TCP 连接“优雅”关闭。
我没有看到任何其他迹象表明中间人进行了干扰。
更新 2
所有浏览器和下载应用中都存在此问题，暂停/重启功能在所有允许暂停/重启的应用中 99% 的时间都有效。我可以轻松复制此问题的特定应用和浏览器：Firefox（当前版本）、IE（9）、iTunes（为 iOS 设备下载应用和更新）。我不确定这些应用和浏览器是否都使用相同的功能来实现下载中的暂停/恢复功能。
iTunes 从允许重新启动的服务器下载（iOS 更新文件除外），因此我暂停下载多长时间都没关系。我下载大型文件的大多数网站（MS、PTC、Solidworks、AutoDesk）都不支持恢复已停止/取消的下载（MS 支持，但只能从其基于 Java 的下载管理器恢复），因此我最多只能暂停大约 15 秒，之后尝试恢复时下载将立即失败。
更新 3
使用 mturoute（感谢 Tom H），我发现一致路由的最大 MTU 在碎片化之前为 1500 字节，并且路径从一端到另一端承载了碎片为 10000 字节的 ICMP 有效负载，没有太多问题，包括通过我的 ISP 设备的跳数。因此问题似乎不是碎片化或不兼容的 MTU 设置。
尽管我没有使用 BT 下载这些文件，但我的 ISP 也没有阻止 ICMP，BitTorrent 也没有阻止。
更新 4
因此，根据 WireShark 日志判断，我需要研究如何确定重传和上一节丢失帧的原因。我该如何隔离这些可能的来源？
答案1
通常，你可以通过系统地证明网络的各个部分是好的来隔离和解决问题。这是一个自信地说“我知道这是通过使用适当的工具进行调查来实现的，通过部分调查，你将得到拼图的最后一块，然后说，我知道这就是问题所在，因为其他一切都很好！
如果你可以在连接到两个都以太网和无线然后将问题隔离在网络 <=> Cisco 1811W <=> DSL 光纤 <=> ISP <=> 和互联网之间的最终链路中
如果你只在有线网络中看到问题或者无线设备，那么您可以定位 Cisco 1811W 上的有线以太网或无线配置。然后您可以检查问题网段的通用设置，作为下一步。
在测试某些设备时，通常重新安装任何通常连接的以太网电缆，并尝试更换 DSL 电缆（如果可用）。
检查路由器上为 DSL 设置的 MTU 和自动协商设置，并查看来自 IOS 的路由器日志文件。
路由器将运行 IOS 12 或类似版本，它将有一些通过 ssh 访问的良好命令行工具来检查协商设置。
使用该show interfaces命令查看错误统计信息，例如重新发送和丢弃的数据包。它甚至可能有一个 Web 界面（但我目前没有使用 cisco IOS 设备，因此这不是仅根据我在解决 cisco 网络故障时所做的一些笔记进行测试的）
但是，您应该能够使用以下命令从 cisco 控制台调出每个端口的错误统计表
# show interfaces status
# show interfaces counter errors
对于特定端口，例如
# show interface GigabitEthernet 5/28 status
# show interface GigabitEthernet 0/24 switchport
编辑：这是一个小视频有人展示了如何使用 ios“显示接口计数器错误”来解决问题。这确实很酷，但可能太过深入，但它为您提供了检测双工不匹配或自动协商设置所需的信息。
附言：您可以通过将备用 DSL 路由器插入光纤连接来证明路由器部分的连接，如果下载工作正常，找到它们，则说明问题出在这一侧，而不是 ISP 侧。
答案2
一些 ISP 做出了奇怪的决定阻止交换机或防火墙上的所有 ICMP 数据包。这会阻止计算路径 MTU，这意味着当数据包通过具有较低 MTU 的路由时，会出现更多碎片数据包。也许您已经看到了这种结果。
碎片化的数据包必须重新组装，如果还存在数据包丢失，那么这可能会是个问题！假设您正在尝试下载大文件，那么数据包的碎片化和丢失都会是一个更大的问题。路径 MTU 发现旨在减少碎片化。
那么，您如何知道您的 ISP 是否对您这样做了？您可以询问他们 - 但是，根据我的经验，ISP 更愿意让您花几天/几周的时间进行基本的故障排除，而不是承认他们可能做错了什么。当然，有时他们这样做是对的！
您应该收集信息，向他们展示您所看到的内容。像您在 Wireshark 中所做的或在防火墙上收集的数据包捕获很有帮助，因为它们通常可以揭示碎片的程度。您可以使用tracepath(*nix) 或mturoute（视窗）。
如果您发现 pMTU 不起作用，则可能是您的 ISP 或您尝试下载的网站的 ISP 的问题。如果您在从多个网站下载时都遇到问题，则很可能是您的 ISP 的问题。
当然，也可能是很多其他的事情 :-) 祝你好运！
答案3
您是否使用 BitTorrent 下载这些大文件？许多 ISP 都安装了特殊硬件来检测和限制流量滥用者。
我会打电话给你的 ISP，询问他们你与他们有什么计划，以及他们是否知道任何流量整形或限制。
以下是我的 ISP 使用的：
如果发现存在任何此类硬件/软件速率限制设备，我将把它留给 OP 作为练习来确定如何绕过它们。
答案4
问题已解决！
这个问题极难诊断，因为它发生的频率不规律，而且，虽然不是罕见，但也不频繁（是的，这是一个矛盾，我会接受它）。
最终，问题似乎变得越来越严重，并影响到我们连接的其他方面，我能够在丢失的 ping 等情况下捕获它，并且我清楚地知道问题不在我们的网络中。
我们的 ISP（当时）是转售的 AT&T 连接，因此我首先与经销商进行了交谈，向他们提供了我收集的信息（这是我从记忆中得到的，这个问题大约在 6 个月前就解决了，所以技术细节很少，抱歉），证明问题不是我们网络内部的。他们发现他们自己的一个交换机有问题，并更换了它，但这并没有解决问题，所以他们进行了测试，发现 AT&T 上游存在问题，AT&T 能够证实并解决这些问题。
我不能完全确定问题只出在 AT&T。根据症状的升级方式，我认为升级是由于 AT&T 方面的问题，但最初的问题出在我们自己的本地 ISP 上，因此我们在那里存在信任问题。
我们更换了 ISP，因此放弃了当地的经销商，转而选择 AT&T。我知道，我们逃出困境又陷入困境。但现在我们支付的费用少了很多，但保证的服务更多，而且 AT&T 一发现问题，就立即修复了，这对我们来说还算可以接受。