☰

FTP 带宽使用是否会导致 SSH 连接断开？

tag-icon • tag-icon linux bandwidth ftp
FTP 带宽使用是否会导致 SSH 连接断开？

在我看来，这似乎非常难以置信，甚至荒谬。

我通过 SSH 登录到 CentOS 服务器。我通过 FTP 连接到另一台服务器并开始传输大文件（上传到其他服务器）。

过了一段时间（通常大约 3 - 30 秒），我被踢出了 SSH。

我在其他服务器上从来没有遇到过由于 FTP 带宽而被踢出 SSH 的问题。

root@my_server [/home/my_folder/public_html]# ftp xx.xxx.xx.xx
Connected to xx.xxx.xx.xx.
220 (vsFTPd 2.3.5)
530 Please login with USER and PASS.
530 Please login with USER and PASS.
KERBEROS_V4 rejected as an authentication type
Name (xx.xxx.xx.xx:root): buttle_butkus
331 Please specify the password.
Password:
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> cd speedtest
250 Directory successfully changed.
ftp> 2gb_file.tar.gz
local: 2gb_file.tar.gz remote: 2gb_file.tar.gz
227 Entering Passive Mode (xx,xxx,xx,xx,xxx,xxx).

Connection closed by host

Disconnected

服务器托管公司说这是因为“所有带宽都被 FTP 使用”。我从来没有听说过这样的事情，但在告诉他们他们疯了之前，我想问问这里的专家。

他们还建议我将UserBandwidthpure-ftpd.conf 中的选项更改为 15。即在 100mbps 连接上以 15 千字节/秒的速度传输。我想我需要为 SSH 留出大约 99.9mbps 的速度？？

我确实更改了它，但它并没有影响上传速度（仍然非常快）。也许该设置只影响通过 FTP 登录服务器的外部用户。我通过 SSH 登录，然后通过 FTP 退出。

谢谢。

编辑：添加部分 tshark 捕获的流量（IP 地址部分隐藏）：

544 111.343171 xx.xx.195.90 -> xx.xx.230.39 SSH [TCP Retransmission] Encrypted
response packet len=60
545 117.486826 xx.xx.195.90 -> xx.xx.230.39 SSH [TCP Retransmission] Encrypted
response packet len=60
546 125.464960  xx.xx.94.90 -> xx.xx.195.90 TCP [TCP Previous segment lost] ssh
> csd-monitor [SYN, ACK] Seq=498204672 Ack=2219931860 Win=8192 [TCP CHECKSUM INC
ORRECT] Len=0
547 129.774351 xx.xx.195.90 -> xx.xx.230.39 SSH [TCP Retransmission] Encrypted
response packet len=60
548 154.348760 xx.xx.195.90 -> xx.xx.230.39 SSH [TCP Retransmission] Encrypted
response packet len=60
549 203.497887 xx.xx.195.90 -> xx.xx.230.39 SSH [TCP Retransmission] Encrypted
response packet len=60
550 279.243718 xx.xx.195.90 -> xx.xx.230.39 SSH Encrypted response packet len=9
52

答案1

解决方案似乎已经找到，但我不确定。服务器主机的客户服务非常糟糕。但目前，问题不再发生。我能够传输大文件，并且在 20-30 秒后不会从 SSH 终端启动。

他们将网络双工模式从 HALF 改为 FULL。

查看有关双工不匹配的维基百科文章：http://en.wikipedia.org/wiki/Duplex_mismatch

根据文章，双工不匹配导致网络严重拥堵。服务器主机客户服务部门之前将问题归咎于带宽，称 SSH 连接被中断是因为我通过 FTP 传输的文件太大。他们说我应该支付更多带宽来解决这个问题。这显然无济于事。无论带宽有多大，双工不匹配都会使带宽不堪重负。我仍然不完全清楚为什么这会终止终端会话，但可能是由于 FTP 传输导致的拥堵阻碍了保持会话活动的 SSH 数据包。但它通常会在 20-30 秒内中断，这似乎有点太快了。

我向客服反映，他们在 12 月安装 100 mbps 端口时搞砸了一些设置（之前是 10 mbps）。我不确定之前是否发生过这种情况，因为我们很少需要通过 FTP 将文件传输出去。以下是他们的回复：

根据您的要求，我们已于 2012 年 12 月 29 日手动将此服务器端口升级到 100 mbps。它已正确安装。可以使用命令“mii-tool”随时更改网络模式。您是否对网络设置进行了任何更改，或者您是否强制重启了服务器？我看到服务器在 9 天前重启过。那是一次安全的重启尝试吗？可能是最近的重启尝试改变了设置。

您的其他服务器是否也面临同样的问题？那么只需运行以下命令并确保您的服务器正在运行全双工模式

***** ethtool eth0 | grep -i duplex

相关内容