运维 java 网络协议 【网络】服务器间FTP传输文件被限速问题的排查（未达最优解）

服务器间FTP传输文件被限速问题的排查

问题描述具体问题软硬件环境文件传输方式的2种策略FTP相关信息问题表现问题解决结论

发散探讨——基于此问题进行发散研究相关知识从FileZilla软件入手从Windows入手从Linux入手从协议入手Windows和Linux的文件共享，分别是使用什么协议？

问题描述

具体问题

Linux使用FTP下载Windows上的文件，FTP传输被明显限速。

软硬件环境

两台服务器之间需要大文件传输（对比以往的业务，我们将5GB以上的文件称为大文件）。服务端为Windows 7操作系统，客户端为银河麒麟v10（视作Linux操作系统）。万兆网口和千兆网口。

文件传输方式的2种策略

FTP服务客户端连接传输。Windows开放一个共享路径由Linux挂载（mount命令）后直接拷贝。

FTP相关信息

在Windows服务器上，FTP服务使用FileZilla Server作为FTP服务。 在麒麟服务器上，用于FTP连接客户端有2个方案：FileZilla提供的图形化客户端、博主自己使用Java开发的客户端。

问题表现

在麒麟服务器上挂载了一个Windows服务器共享的远程位置，需要使用直接拷贝到指定位置，此时在Windows服务器的任务管理器测得的带宽利用率可达99.6%，5GB文件传输，10秒以内完成。麒麟服务器使用FileZilla客户端连接Windows服务器的FileZillaServer，传输文件，带宽利用率仅有30%，5GB文件传输多次测得时间，平均值为30秒。麒麟服务器使用Java自研的FTP客户端连接Windows服务器的FileZillaServer，传输文件，带宽利用率有所改善，最快可达60%，5GB文件传输多次测得时间，平均值为15秒。 下图为某一次测试的带宽占用率对比图：

问题解决

FileZilla客户端不满足性能指标，不使用此方案。Java自研的FTP客户端虽然没有达到挂载那么高的速度，但满足性能指标，在更换多台服务器测试、优化稳定后，最终采用此方案。

结论

可能是操作系统对于FileZilla软件进行了特殊限制，也可能是FileZilla客户端底层的某些操作导致了操作系统的这种限制存在。

发散探讨——基于此问题进行发散研究相关知识

这个问题虽然解决了，但仅是业务意义上的解决，而不是技术上的解决。若本着效率至上的“技术服务于业务”原则，确实不该继续深究，但站在个人兴趣角度，这个问题值得继续扩展探讨下去。

从FileZilla软件入手

基于软件问题入手排查，博主找到这篇文章：Ftp传输在win10下被系统限速的问题分析和解决。 文中提及，Windows可能对FileZilla软件做出特殊优化性质的限制，实验中使用先传输小文件，再传输大文件的方式，“骗”过了操作系统，进而得以不被限制。这种方法是不可取的，不具有普适性，文中也说到此方法的弊端，所以不采用此方法。而后，文中提到了将FileZilla客户端的连接模式改为主动模式，会有改变，博主多次测试后，发现FTP传输带宽利用率确实有5%的提高。但仍然是和挂载方式速度相去甚远。

从Windows入手

在网络中找到的相关文章——Win10 环境FileZilla client客户端出现兼容性限速问题的解决。 文中表示在FTP传输文件确实是被限速了，需要对Qos参数进行优化，即在Windows上运行以下命令： netsh int tcp set global autotuninglevel=restricted和netsh interface tcp set heuristics disabled。 即对接收窗口自动调节级别做出更改，但我在尝试后并未解决。（博主试过将FileZilla客户端设置为主动模式的同时，也执行这两个命令，再进行多次测试，结果仍然是没有提升） 在继续查询资料的时候，在微软社区发现如下提问：为什么win10/11会对smb和ftp的局域网分享传输速度限制？（这个提问和回答均值得一看，提问者是有水平的） 虽然我的问题来自于Windows 7，但考虑其他可能性，我还是阅读了这篇“提问者和回答者的交锋”。 此回答中，也尝试过我们上面的接收窗口自动调节级别命令的方式来优化问题，甚至重新安装了操作系统，但可惜最后问题未能解决。

从Linux入手

接下来博主准备从Linux系统的方向上寻求解决方案，便找到这篇文章：掌握Linux TCP 窗口设置，提高网络传输效率 (linux tcp 窗口设置)。文中提及的对TCP窗口大小进行修改，我新增了如下net.ipv4.tcp_window_scaling=1和net.ipv4.tcp_moderate_rcvbuf=1配置后，FTP传输带宽利用率有约5%的提升，但后续无论如何调试修改参数，均无法改变带宽利用率，甚至有所降低。

既然问题无法通过配置的方式解决，那么就需要考虑到协议层面的规则。

从协议入手

Windows和Linux的文件共享，分别是使用什么协议？

这个问题其实应该是“Windows的共享文件夹、Linux的挂载远程网络位置，分别使用的是什么协议？”

在Windows操作系统上，共享文件夹通常使用的是SMB (Server Message Block)协议。SMB是一种广泛应用的网络文件共享协议，尤其在Windows环境中，它允许网络上的客户端访问服务器提供的文件系统资源，如文件、目录、打印机等。现代版本的Windows系统默认使用的是SMBv2或更高版本。

在Linux操作系统上，挂载远程网络位置（尤其是来自其他Linux服务器或NAS设备）最常使用的协议是NFS(Network File System)。NFS是一种专门设计用于跨网络共享文件系统的标准协议，它允许一个系统通过网络像访问本地文件一样透明地访问远程服务器上的文件。NFS在Linux和其他类UNIX系统中广泛支持。

但我们的问题中，即使用了Windows，也使用了Linux。那么此时问题就变成了“如果Linux上挂载的网络位置是Windows上的共享文件夹，那么此时使用的什么协议？”

答案是：SMB协议。因为Linux虽然有自己的NFS协议进行文件共享，但若对方是来自Windows的共享，Linux需要借助SMB客户端软件来与Windows系统进行通信。

在Linux中，通常会使用名为“cifs-utils”的软件包来提供对SMB协议的支持。

至此，由于时间限制，未能达到最优的解决方案。不过发散的学习到了很多其他知识，希望本文的观点和搜索的资料，可以提供一些解决问题的思路，以便诸位在解决相似问题的时候可以得到启发。

文章链接