要分析ftp下载文件慢这样的问题，先了解下三年半前分享的ftp原理(浏览量近一万)。
ftp分客户端和服务端，客户端和服务端之间通过TCP建链，控制连接下发命令，数据连接用来传输数据。
下面是分析思路。
1) 首先简单检查是否是网络带宽问题
做个简单测试：在不同服务器上通过Linux ftp命令登录并下载该文件，查看下载时长。
# ftp user@192.168.55.66
lcd命令设定本地接受目录位置
# lcd /home/user/yourdirectoryname
如果你不指定下载目录，文件将会下载到你登录 FTP 时候的工作目录。
使用命令 get 来下载文件，查看下载速度。
在该问题发现的同一机器上下载，如果下载也同样慢，多试几次，观察下载慢是否稳定，详细原因，继续2)。
在该问题发现的不同机器上下载，如果下载也同样慢，多试几次，观察下载慢是否稳定，如果同样下载快，说明该问题发现的同一机器网络有问题。如果也下载慢，不能说明问题。
2) 然后检查网络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窗口解决。
3) 其次检查是否是FTP服务端的问题
其实第一步，如果有服务器可以下载快的话(文件大小处以时间可以得到传输速率，和实际网络中千兆网卡百兆网卡对比下就可以有答案)，也能排除ftp服务端的问题。如果下载都慢的话，检查FTP服务端主机负载和CPU，磁盘IO是否异常。
4) 检查是不是FTP客户端的问题
如果下载慢的话，检查FTP客户端主机负载和CPU，磁盘IO是否异常。
5) 最后检查FTP客户端程序的问题
以上如果都没问题，使用另外的ftp客户端尝试下载看是否也慢。
ftp客户端一般是采用第三方包进行开发的，有可能使用不当导致的。
比如Python的，JAVA的，go的都不一样。
