尝试一个全面的解决方案，因为可能会有几个问题和限制取决于您的情况。
错误
我的首选选项：使用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/"

不过这doesn't always work。

压缩选项

scp的-C选项可以加快传输速度，降低传输停止的可能性。

正在禁用TCP SACK

正如OP中所提到的，还有here。

sudo sysctl -w net.ipv4.tcp_sack=0

（or similar）

LAN卡MTU

同样是MTU fix，但不一定是特定的传输：

ifconfig eth0 mtu 1492

或在newer (Linux) systems上：

ip link set dev eth0 mtu 1492

其他

如果所有其他方法都失败了，this列出了另外几个这里没有包括的潜在解决方案。
更奇特的hpn bug可能也有问题。

虽然这个问题已经很老了，但除了已经提供的不错的列表@BrechtDeMan之外，我仍然想分享另一个可能的解决方案。
在某些情况下，问题可能是由自动协商设置的所用链路的无效速度/双工配置引起的。例如，我的设备默认以100 Mbps/全双工运行，但在此配置下无法正常工作。
因此，您可以使用以下命令读取当前配置和支持的模式：
ethtool eth0
并给予使用较低的设置，例如，在我的情况下为100 Mbps/半双工：
ethtool -s eth0 speed 100 duplex half

当我使用git bash的scp将一个6 G的远程文件复制到Windows时，它在99%时反复停止/挂起，但当我在Windows的scp上使用Ubuntu时，它第一次就成功了。

你有没有可能在Cisco阿萨防火墙后面？如果是这样，关闭“序列号随机化”，这会有很大帮助--如果你在服务器上使用带有Broadcom NIC的Cisco ASA，也要禁用TCP卸载（ethtool -K $INTERFACE tso off gso off gro off）。