1. FTP传输限速问题初探最近在帮朋友排查一个奇怪的网络问题两台服务器之间用FTP传文件时速度特别慢但用其他方式传输却能达到满速。这让我想起去年自己遇到的类似情况当时折腾了好几天才找到问题根源。今天我就把这个排查过程完整分享出来希望能帮到遇到同样困扰的朋友。具体场景是这样的一台银河麒麟v10系统的服务器相当于Linux需要从Windows 7服务器上下载大文件。测试发现用mount挂载Windows共享目录直接拷贝时带宽利用率能达到99%5GB文件10秒搞定但用FileZilla客户端通过FTP传输时带宽只能用到30%同样的文件要30秒。更奇怪的是换用Java开发的FTP客户端后速度能提升到60%左右。2. 从FileZilla客户端入手排查2.1 软件设置检查首先我怀疑是FileZilla的配置问题。打开软件设置重点检查了这几个地方传输模式默认是被动模式(PASV)改为主动模式(PORT)后速度提升了5%并发连接数从默认的2增加到10效果不明显传输类型确保是二进制模式而非ASCII模式在Windows事件查看器里我还发现每次FTP传输时都会记录一条FTP服务限制了连接速率的警告。这提示可能是系统层面的限制。2.2 Windows的特殊限制搜索发现微软社区有个热门讨论Windows会对某些FTP客户端做速率限制。有人提到这是因为Windows的QoS策略会识别FileZilla的流量特征并限速。尝试了两种解决方案修改注册表禁用QoSreg add HKLM\SOFTWARE\Policies\Microsoft\Windows\Psched /v NonBestEffortLimit /t REG_DWORD /d 0 /f更改网络适配器设置netsh int tcp set global autotuninglevelrestricted netsh interface tcp set heuristics disabled实测发现第一种方法效果更明显能让速度提升到50%左右但距离理想状态还有差距。3. 系统级优化方案3.1 Windows TCP参数调优在Windows服务器上我进一步调整了TCP协议栈参数# 增大TCP窗口大小 netsh int tcp set global rssenabled netsh int tcp set global autotuninglevelrestricted # 禁用TCP自动调优 netsh interface tcp set global autotuningdisabled同时修改了注册表中的TCP缓冲区参数reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters /v TcpWindowSize /t REG_DWORD /d 64240 /f reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters /v GlobalMaxTcpWindowSize /t REG_DWORD /d 64240 /f这些调整让传输速度又提升了10%但依然无法突破70%的带宽利用率天花板。3.2 Linux客户端优化转战Linux客户端尝试修改TCP窗口参数# 临时生效设置 echo 1 /proc/sys/net/ipv4/tcp_window_scaling echo 1 /proc/sys/net/ipv4/tcp_moderate_rcvbuf # 永久生效需要修改/etc/sysctl.conf net.ipv4.tcp_window_scaling 1 net.ipv4.tcp_moderate_rcvbuf 1 net.core.rmem_max 16777216 net.core.wmem_max 16777216执行sysctl -p后测试速度有小幅提升但效果有限。看来单纯调整TCP参数并不能完全解决问题。4. 协议层面的深度分析4.1 FTP vs SMB协议对比当使用mount挂载时实际走的是SMB协议而FTP是另一种完全不同的协议。两者主要区别特性FTPSMB传输效率较低较高加密开销可选默认加密会话保持需要控制连接单一连接防火墙友好性需要多端口单端口4.2 实际测试数据我用iperf3做了组对照测试纯TCP测试# 服务端 iperf3 -s # 客户端 iperf3 -c 192.168.1.100 -t 60结果940Mbps千兆网卡的理论极限FTP传输测试lftp -u user,password ftp://192.168.1.100 -e get largefile.zip; quit结果平均320MbpsSMB传输测试time cp /mnt/winshare/largefile.zip .结果平均890Mbps这证实了协议选择对传输效率的重大影响。5. 终极解决方案探索5.1 更换传输工具既然FTP协议本身存在效率瓶颈我测试了几种替代方案rsync适合增量同步但首次传输速度与FTP相当rsync -avzP user192.168.1.100:/path/to/file .scp基于SSH加密速度比FTP快20%左右scp user192.168.1.100:/path/to/file .HTTP下载简单搭建nginx服务后用wget下载速度能达到800Mbpswget http://192.168.1.100/largefile.zip5.2 混合方案实践最终采用的解决方案是根据文件大小动态选择传输方式小于1GB的文件使用FTP管理方便1GB以上的文件使用临时HTTP服务性能优先定期同步任务使用rsync增量优势实现这个策略的shell脚本示例#!/bin/bash FILE$1 SIZE$(stat -c%s $FILE) if [ $SIZE -gt 1073741824 ]; then echo Using HTTP transfer for large file... # 启动临时HTTP服务 python3 -m http.server 8000 PID$! # 执行下载 wget http://localhost:8000/$FILE kill $PID else echo Using FTP transfer... lftp -u user,pass ftp://remotehost -e get $FILE; quit fi6. 经验总结与避坑指南经过两周的反复测试我整理出这份FTP传输优化的checklist必检项目确认物理链路正常网线、交换机端口检查网卡协商速率千兆/万兆关闭防火墙临时测试软件配置更新FileZilla到最新版尝试主动/被动模式切换调整并发连接数(2-10)系统调优Windows QoS策略调整TCP窗口大小优化禁用TCP自动调优协议选择大文件优先考虑SMB/HTTP跨平台考虑rsync/scp内网环境可尝试NFS在实际项目中我遇到最坑的情况是某品牌交换机的流量整形功能会误判FTP流量为P2P下载并限速。后来在交换机上添加这条ACL规则才解决access-list 100 permit tcp any any eq ftp access-list 100 permit tcp any eq ftp any如果所有方法都试过了还是不行建议用Wireshark抓包分析。有一次我就是通过抓包发现客户端在反复协商TLS版本导致延迟更新OpenSSL库后问题迎刃而解。