要分析ftp下载文件慢这样的问题，先了解下三年半前分享的ftp原理(浏览量近一万)。

ftp分客户端和服务端，客户端和服务端之间通过TCP建链，控制连接下发命令，数据连接用来传输数据。

下面是分析思路。

做个简单测试：在不同服务器上通过Linux ftp命令登录并下载该文件，查看下载时长。

# ftp [email protected]

lcd命令设定本地接受目录位置

# lcd /home/user/yourdirectoryname

如果你不指定下载目录，文件将会下载到你登录 FTP 时候的工作目录。

使用命令 get 来下载文件，查看下载速度。

在该问题发现的同一机器上下载，如果下载也同样慢，多试几次，观察下载慢是否稳定，详细原因，继续2)。

在该问题发现的不同机器上下载，如果下载也同样慢，多试几次，观察下载慢是否稳定，如果同样下载快，说明该问题发现的同一机器网络有问题。如果也下载慢，不能说明问题。

参考：FTP传输速率慢和TCP窗口、网络时延的因果案例

FTP传输是TCP协议。对于TCP协议来说，通信双方一次只能传输TCP窗口大小的数据，然后等待接收方确认，等到确认完毕后才能传输下一段窗口大小的数据。因此TCP协议的传输速率，取决于TCP传输窗口的大小和网络转发性能（带宽和时延）。

通过以下手段排查

1) 对服务器FTP传输进行抓包分析，发现FTP传输速率下降的服务器发送的TCP报文中没有TCP扩展窗口字段（又称作Window scale窗口尺度选项），所以这些服务器无法扩大TCP窗口，只能用初始值65535字节。

而FTP传输速率维持正常的服务器发送的TCP报文中有TCP扩展窗口字段，这些服务器可以扩大TCP窗口。

以下是我们抓取的报文中，可以协商TCP窗口大小的服务器发送的报文，可以看到TCP数据段的头的可选字段（option）中有window scale字段，也就是TCP扩展窗口字段：

以下是不能协商TCP窗口大小的服务器发送的报文，可以看到它没有TCP扩展窗口字段：

2) 选择不同的网络接入点，通过ping的手段观察网络反映时间，我们发现网络中的时延会随着跳数的增加而增加，每增加一跳大约会增加0.1ms左右的时延。

如果服务器之间的跳数增加了2跳，引入了一定的时延（0.2ms左右），这对于只能使用65535字节大小的TCP窗口的服务器来说，FTP下载速率的降低是很明显的。

通过计算得出，此时TCP窗口大小和网络时延的改变对服务器FTP传输速率会造成很大的影响：

a) 如果通信双方的TCP窗口维持初始的65535字节，而网络中存在0.65ms的传输时延，那么FTP传输速率就是100.8MB/s.

b) 如果网络传输时延增大，比如加大到0.85ms左右（增加0.2ms时延）, 而TCP窗口大小仍旧是65535字节，则FTP传输速率会降到77.1MB/s.

c) 如果TCP窗口大小支持扩展，比如可以扩展到原有的2倍，也就是131070字节，则即使传输时延增大到1ms, FTP传输速率理论上也可以达到1Gbps的端口线速125MB/s.

在网络时延较大的情况下，要保证链路传输速率维持在较高水平，就需要两端服务器能够协商TCP窗口大小，也就是两端服务器的TCP协议栈中要有TCP扩展窗口字段，这样TCP窗口就可以协商成一个较大值。

两端服务器中只要一端的服务器不支持TCP扩展窗口，那么就无法协商TCP窗口，两端设备的TCP连接只能采用初始值65535字节。

解决方法：

1）重新规划网络，改变网络拓扑，减小服务器之间连接的跳数。

2）修改服务器注册表项或者升级服务器版本，使服务器能够支持TCP扩展窗口字段，协商TCP窗口大小。或者在服务器上直接通过命令，调大服务器TCP窗口解决。

其实第一步，如果有服务器可以下载快的话(文件大小处以时间可以得到传输速率，和实际网络中千兆网卡百兆网卡对比下就可以有答案)，也能排除ftp服务端的问题。如果下载都慢的话，检查FTP服务端主机负载和CPU，磁盘IO是否异常。

如果下载慢的话，检查FTP客户端主机负载和CPU，磁盘IO是否异常。

以上如果都没问题，使用另外的ftp客户端尝试下载看是否也慢。

ftp客户端一般是采用第三方包进行开发的，有可能使用不当导致的。

比如Python的，JAVA的，go的都不一样。