我正在尝试将文件从本地计算机之一复制到远程计算机。复制大小不超过 1405 字节的文件效果很好。当我尝试 scp 较大的文件时，文件会被复制，但 scp 进程会挂起并且不会退出。我必须按 Ctrl-C 才能返回 shell。
我在 FTP 上也观察到了同样的行为。关于可能导致这种情况的原因有什么想法吗？
答案1
这听起来绝对像 MTU 问题（就像@Konerak 指出的那样），这就是我测试的方法：
ip link set eth0 mtu 1400
这会暂时将网络接口上允许的网络数据包大小设置为 1400 eth0（您可能需要调整名称）。然后，您的系统将分割所有超过此大小的数据包，然后再将其发送到网络。如果这修复了 scp 命令，您需要在网络中找到问题或使这个丑陋的修复永久存在；）
答案2
考虑到 MTU 通常为 1500 B（由于以太网的限制）。在这 1500 B 中，并非所有都用于“数据”。所谓的协议开销在这 1500 个开销中占据了很大一部分。
- SCP（未压缩）需要 65 B 标头。
- TCP 需要 20-60 B 标头。
- IP 需要 20-60 B 标头。
鉴于此，您的有效负载被限制为 1405 B 也就不足为奇了。
Ps 尝试一下wireshark 并检查IP 标头。他们允许数据包碎片吗？
答案3
对我来说听起来硬件很糟糕。如果 LAN 上只有一台机器，则可能是以太网卡损坏；如果是局域网上的所有机器，我会检查集线器或路由器。
答案4
在所涉及的源机器和目标机器之间存在某种隧道。 TCP 将在打开连接时传输 MSS（将用于 ssh/scp），并且沿途的隧道（添加封装，从而减少最大可用 MTU）应通过透明地将所述 MSS 途中修改为目的地（反之亦然）。
某些隧道（VPN？）没有发挥其作用。或者您机器上的 MSS 配置错误。
我猜如果您 ssh 到要从中复制的计算机，然后在空目录中执行 ls 操作，您会看到相同的行为。那应该可以正常工作。但如果你“cd / ; ls -lR”（从而获得大数据包），这也会挂起。