通过错误的连接下载大文件

有没有可用的现有工具，可以通过错误的连接下载大文件？

我必须定期下载一个相对较小的文件：300 MB，但是慢速（80-120 KB /秒）的TCP连接会在10-120秒后随机中断。（这是一个大公司的网络。我们多次联系了他们的管理员（在印度工作），但他们不能或不想做任何事情。）问题可能出在他们的反向代理/负载平衡器上。

到目前为止，我使用的是pcurl的修改版本：https : //github.com/brunoborges/pcurl

我更改了这一行：

curl -s --range ${START_SEG}-${END_SEG} -o ${FILENAME}.part${i} ${URL} &

对此：

curl -s --retry 9999 --retry-delay 3 --speed-limit 2048 --speed-time 10 \
    --retry-max-time 0 -C - --range ${START_SEG}-${END_SEG} -o ${FILENAME}.part${i} ${URL} &

我必须添加，--speed-limit 2048 --speed-time 10因为连接失败时大部分时间只会挂起几分钟。

但是最近，即使这个脚本也无法完成。

一个问题是它似乎忽略了该-C -零件，因此它在重试后不会“继续”该段。似乎会截断相关的临时文件，并在每次失败后从头开始。（我认为--range和-C选项不能一起使用。）

另一个问题是此脚本同时下载所有段。它不能有300个段，一次只能下载10个。

我当时正在考虑为此目的用C＃编写下载工具，但是如果有现有工具，或者curl命令可以在不同的参数下正常工作，那么我可以节省一些时间。

更新1：附加信息：不应删除并行下载功能，因为每个连接具有带宽限制（80-120 KB /秒，主要是80），因此10个连接可以使速度提高10倍。我必须在1小时内完成文件下载，因为该文件每小时生成一次。

lftp（维基百科）对此很有帮助。它支持多种协议，可以使用多个并发并行连接下载文件（在由于拥塞而导致大量数据包丢失的情况下很有用），并且可以自动恢复下载。也可以编写脚本。

这里包括您想出的微调（贷记给您）：

lftp -c 'set net:idle 10
         set net:max-retries 0
         set net:reconnect-interval-base 3
         set net:reconnect-interval-max 3
         pget -n 10 -c "https://host/file.tar.gz"'

在您遇到的情况下，我无法为您测试此情况，但您不应将其--range与一起使用-C -。这是手册页关于此主题的内容：

使用 -C -告诉curl自动找出/如何恢复转让。然后，它使用给定的输出/输入文件来解决这一问题。

尝试以下方法：

curl -s --retry 9999 --retry-delay 3 --speed-limit 2048 --speed-time 10 \
    --retry-max-time 0 -C - -o "${FILENAME}.part${i}" "${URL}" &

我也强烈建议您始终对变量加双引号，以使Shell不会尝试解析它们。（考虑一个URL https://example.net/param1=one&param2=two，shell将在其中拆分值&。）

顺便说一下，120 KB / s约为1.2 Mb / s，这是世界许多地方的典型xDSL上传速度。每MB 10秒，因此整个文件不到一小时。并不是那么慢，尽管我很欣赏您更关心可靠性而不是速度。

也许您还有更多的运气wget --continue：

wget --continue ${URL}

另请参阅https://www.cyberciti.biz/tips/wget-resume-broken-download.html

在盒子外面：戴上眼罩并使用bittorrent。创建种子文件时，将块大小减小。显然，对文件进行加密可以使其他任何人在搜索torrent时都无用。

我在上一份工作中遇到了同样的问题（除了在（从办公室）不稳定的连接上进行300GB +的异地数据库备份外）。用户在下载大于大约文件的文件时遇到严重问题。拔出连接前1 GB。由于他们通过RDP连接使用了标准的Windows复制/粘贴文件，因此也就不足为奇了。

我发现的一件事是，我们的VPN设置与网络设置完全不匹配（主要是MTU长度）。第二件事是Windows的文件复印机不是用于通过Internet复制内容的。

我的第一个解决方案是一个简单的FTP服务器，但是它没有解决传输时间的问题（在我们的连接上通常需要3-4小时）。

我的第二个解决方案是使用Syncthing将文件直接发送到内部NAS。备份完成后的每个晚上，Syncthing会将我们需要的一切发送回办公室中的NAS。不仅解决了3个小时以上的传输时间问题，而且在发生危机时，我还节省了1-2个小时的时间来保证数据传输速度。每天早上8点，文件将在NAS上更新，我们已经准备好备份。即使有巨大的文件（某个时候几乎有700GB的数据库），我还没有遇到任何文件损坏或其他问题...

同步很容易设置和管理，并且适用于所有平台（甚至电话），并且可以很好地处理不良连接。如果连接失败，同步只需等待几分钟，然后重试。

您确实需要一个本地文件夹来将内容同步到其中，但是文件几乎在更新后即可使用。

同步的另一个好处是，可以将其设置为仅同步文件中的更改（例如差异备份中的...）……可能可以解决部分带宽问题。

您可能会考虑使用老式的解决方案来通过糟糕的连接-zmodem移动文件。

这是早在2400个波特调制解调器被人们接起电话并炸毁连接的情况下发展起来的。可能值得一试。

您可以尝试使用Kermit：

Kermit协议与其他大多数协议的区别在于它的设置范围广，可以适应任何两种计算机之间的任何类型和质量的连接-包长度，包编码，窗口大小，字符集，错误检测方法，超时，暂停。大多数其他协议被设计为仅在某些种类或质量的连接上和/或在某些种类的计算机或类似文件系统之间起作用，因此在其他地方工作不佳（或根本不起作用），并且几乎没有提供任何方法来适应计划外的情况。 -针对情况。另一方面，Kermit允许您在任何给定的连接上实现成功的文件传输和最高的性能。”