根据实验的需要，我将MTU设置为8000。执行此操作后，当我使用scp复制大文件时，它会与0.00%停滞不前。我尝试了scp -l或scp -C并开启/关闭了tcp_sack，但它仍无效。并且我无法更改实验结果比较的MTU大小。还有其他方法可以提供帮助吗？
答案 0 :(得分：65)
尝试全面解决方案，因为根据您的情况可能存在一些问题和限制。
我的首选方案：使用rsync 不会出现此问题并且在我看来更具通用性，例如：它会跟踪哪些文件已经存在，所以如果连接确实中断，它可以从它停止的地方开始 - try the --partial flag too - among other things。
而不是
scp local/path/some_file usr@server.com:"/some/path/"
你可以做到
rsync -avz --progress local/path/some_file usr@server.com:"/some/path/"
我已经在scp给我提出同样的问题时多次测试过这个问题 - 现在我只是默认使用rsync。
不是OP的解决方案，因为MTU在这种情况下是固定的（这可能不是问题），但如果罪魁祸首是两个驱动器之间的连接缓慢/不可靠，设置速度限制可以减少延迟TCP连接停顿 - 当然是以较慢的传输为代价。 这是因为除非你以千位为单位指定最大数据速率，否则scp会抓取它可以获得的所有带宽，如下所示：
scp -l 8192 local/path/some_file usr@server.com:"/some/path/"
scp的-C选项可以speed up传输，减少传输停顿的概率。
如OP所述，here。
sudo sysctl -w net.ipv4.tcp_sack=0
再次MTU fix，但不一定具体转移：
ifconfig eth0 mtu 1492
ip link set dev eth0 mtu 1492
如果所有其他方法都失败了，this列出了此处未包含的另一些潜在解决方案。
更具异国情调的hpn bug也可能是错误的。
答案 1 :(得分：0)
您是否有机会在Cisco ASA防火墙后面？如果是这样，请关闭＆＃34;序列号随机化＆＃34;如果您使用服务器中的带有Broadcom网卡的Cisco ASA，那么这将有很多帮助 - 还可以禁用TCP卸载（ethtool -K $ INTERFACE关闭关闭）。
答案 2 :(得分：0)
尽管这个问题已经很久了，但除了已经提供的漂亮列表@BrechtDeMan之外，我仍然想分享另一个可能的解决方案。
在某些情况下，此问题可能是由所使用的链路的无效速度/双工配置（由自动协商设置）引起的。我的设备默认情况下以100 Mbps /全双工运行，但是不能在此配置下正常工作。
因此，您可以通过以下方式阅读当前配置和支持的模式：
ethtool eth0
，并尝试使用较低的设置，例如在我的情况下为100 Mbps /半双工：
ethtool -s eth0 speed 100 duplex half