我与 ISP 建立了一条 384kbps 的 ADSL 连接（入门级“宽带”），该连接通过该国唯一电话提供商提供的强制性模拟语音线路运行。“已调整”意味着某些协议（如点对点流量）在网络上的优先级较低。这个问题与普通 HTTP 下载有关，与点对点下载无关。
在过去的几个月里，我一直遇到各种站点的 HTTP 下载停滞且无法恢复的情况。我首先在 Windows XP 下的 iTunes 中注意到了这个问题，但进行了广泛的测试以试图找出问题所在。我下载的文件中约有 5% 停滞且无法恢复。
直到最近，这些都是 MP3 文件（播客），但在下载 Android 应用程序时也出现了这个问题。在下面的列表中，“文件”是指几个停滞且无法恢复的文件中的任何一个。
- 即使使用最新版本的 iTunes 也会出现该问题。
- 路由器和计算机已重启多次；问题已持续数月。
- 在 Windows 或 Linux 下下载文件
wget（通过无线或有线连接）会导致文件下载到指定点，然后吞吐量降至零。在某些情况下，如果wget保持运行，连接最终会超时或报告已重置。 - 使用
-c标志会导致除了启动 HTTP 连接之外无法取得进一步的wget效果。使用标志时则无区别。wget--no-cache - 在 Windows 中使用其他下载管理器下载文件也会出现同样的问题。在
curlLinux 下使用下载也会出现同样的问题。 - 该文件可以在其他地方成功下载，无论是从完全不同的网络上的计算机，还是从使用相同 ISP 的其他计算机，因此文件的损坏版本不会滞留在缓存中，源服务器上的文件也不会不完整。
- 我把路由器带到了使用同一 ISP 的另一个位置，文件下载成功。我把路由器从那个位置带到了我的位置，文件停滞了，无法恢复。
- 我的 ISP 已将我的线路和帐户升级到 1mbps 以进行测试。但这并未解决问题。
- HTTP 浏览、音频或 YouTube 视频流以及除 MP3 文件之外的大多数下载似乎不受影响。最近 Android 应用程序无法完成。当我连接到由其他公司运营的本地无线热点时，应用程序下载完成。
- 如果我在不同网络上的远程计算机上下载文件并通过安全连接传输它（
scp），则文件将成功下载。 - 如果我连接到由其他 ISP 运营的本地无线热点，文件将会下载。如果我尝试通过热点链接恢复停滞的下载，下载将会恢复。如果我暂停该文件并重新连接到我的 ADSL，文件将会完成，因为它已经过了停滞点。
- 如果我使用来自我的 ISP 的未成形的测试帐户或其他 ISP 的测试帐户进行连接，则文件会停滞并且无法恢复。
- 如果 ISP 的代表尝试从他们的测试机器下载该文件，则会成功下载。
几年前我也遇到过同样的问题，经过多次讨论，我的 ISP 最终同意让电话提供商将我的线路移至本地 DSLAM 上的其他端口。这解决了当时的问题。尽管这次进行了所有测试和讨论，但我的 ISP 报告说电话提供商不会移动我的线路，因为他们执行的线路测试表明线路状况良好并且线路运行正常。
（几年前，另一个遇到类似问题的人在本地论坛上发帖称，某个特定的字节序列“挂起了”某些硬件设备。发帖人声称已经做了一些测试，并确定了确切的字节序列。我并不是说这是导致我的下载停滞的原因，但这种解释确实与事实非常吻合。）
因此，我可以得出结论，问题与我上游的某些硬件有关，但与我的 ISP 无关吗？还有什么可能导致此问题？
附加信息：这是命令行 WireShark 程序在文件停滞（几个月前创建）时产生的跟踪。此文件一开始就停滞，甚至无法启动；除此之外，症状与在其他时间点停滞的文件相同。我假设我现在遇到的问题是由之前导致这些问题的原因引起的。我曾多次将这些日志发送给我的 ISP，但没有收到任何回复。但我不知道此日志捕获是否有用。我用粗体标出了下载停滞的时间点：
7.052812 192.168.1.105 -> 192.168.1.254 DNS Standard query AAAA www.diablopodcast.com
7.322756 192.168.1.254 -> 192.168.1.105 DNS Standard query response
7.322816 192.168.1.105 -> 192.168.1.254 DNS Standard query AAAA www.diablopodcast.com
7.362412 192.168.1.254 -> 192.168.1.105 DNS Standard query response
7.362450 192.168.1.105 -> 192.168.1.254 DNS Standard query A www.diablopodcast.com
7.363014 192.168.1.254 -> 192.168.1.105 DNS 标准查询响应 A 89.107.69.77
7.363111 192.168.1.105 -> 89.107.69.77 TCP 36393 > http [SYN] Seq=0 Win=5840 Len=0 MSS=1460 TSV=1389507963 TSER=0 WS=6
7.631255 89.107.69.77 -> 192.168.1.105 TCP http > 36393 [SYN, ACK] Seq=0 Ack=1 Win=5792 Len=0 MSS=1452 TSV=2814359613 TSER=1389507963 WS=7
7.631269 192.168.1.105 -> 89.107.69.77 TCP 36393 > http [ACK] 序列号=1 确认=1 Win=5888 长度=0 TSV=1389508030 TSER=2814359613
7.631300 192.168.1.105 -> 89.107.69.77 HTTP GET /wp-content/uploads/2011/04/tdp-ep2-max-part2.mp3 HTTP/1.0
7.914077 89.107.69.77 -> 192.168.1.105 TCP http > 36393 [ACK] 序列号=1 确认=168 Win=6912 长度=0 TSV=2814359684 TSER=1389508030
> 8.204796 89.107.69.77 -> 192.168.1.105 HTTP [TCP 上一个段丢失] 连续或非 HTTP 流量
8.204803 192.168.1.105 -> 89.107.69.77 TCP [TCP Dup ACK 80#1] 36393 > http [ACK] Seq=168 Ack=1 Win=5888 Len=0 TSV=1389508173 TSER=2814359684 SLE=1441 SRE=2881
8.258734 89.107.69.77 -> 192.168.1.105 HTTP 连续或非 HTTP 流量
8.258740 192.168.1.105 -> 89.107.69.77 TCP [TCP Dup ACK 80#2] 36393 > http [ACK] Seq=168 Ack=1 Win=5888 Len=0 TSV=1389508187 TSER=2814359684 SLE=1441 SRE=4321
8.501360 89.107.69.77 -> 192.168.1.105 HTTP 延续或非 HTTP 流量
8.501378 192.168.1.105 -> 89.107.69.77 TCP [TCP Dup ACK 80#3] 36393 > http [ACK] Seq=168 Ack=1 Win=5888 Len=0 TSV=1389508247 TSER=2814359684 SLE=1441 SRE=5761
10.649646 192.168.1.105 -> 89.107.69.77 TCP 36392 > http [FIN，ACK] 序列号=1 确认=1 Win=3353 Len=0 TSV=1389508785 TSER=2814347814 SLE=40321 SRE=142562 SLE=36001 SRE=37441 SLE=20161 SRE=21601
36.377648 192.168.1.105 -> 89.107.69.77 TCP 36392 > http [FIN，ACK] 序列号=1 确认=1 Win=3353 Len=0 TSV=1389515217 TSER=2814347814 SLE=40321 SRE=142562 SLE=36001 SRE=37441 SLE=20161 SRE=21601
46.249883 192.168.1.105 -> 89.107.69.77 TCP 36393 > http [FIN，ACK] Seq=168 Ack=1 Win=5888 Len=0 TSV=1389517685 TSER=2814359684 SLE=1441 SRE=5761
46.512795 89.107.69.77 -> 192.168.1.105 TCP http > 36393 [ACK]序列=5761 确认=169 胜利=6912 长度=0 TSV=2814369332 TSER=1389517685
答案1
通过使用不同型号的路由器（来自同一制造商）解决了这个问题。我测试的备用路由器（问题中提到）与我的路由器非常相似；我的路由器运行的是最新固件。问题似乎出在该型号的软件/固件上。