![Filezilla FTP 在 1 Gbits 光纤上上传速度很慢(350KBps)?](https://linux22.com/image/628970/Filezilla%20FTP%20%E5%9C%A8%201%20Gbits%20%E5%85%89%E7%BA%A4%E4%B8%8A%E4%B8%8A%E4%BC%A0%E9%80%9F%E5%BA%A6%E5%BE%88%E6%85%A2%EF%BC%88350KBps%EF%BC%89%EF%BC%9F.png)
我有 1 Gbits 的下行/上行光纤,并且运行 Filezilla FTP 服务器(我在瑞典),美国有人需要从我这里下载。他的互联网速度为 60/8,因此他应该能够下载大约 7.5MB 秒,但只能获得 350KB 秒。他可以向我上传 1MB 秒。
延迟约为 155 毫秒,我有:
CMD: netsh interface tcp set global congestionprovider=ctcp
...和 FileZilla xml 配置:
Socket recv buffer size 4194304 Socket send buffer size 1162500
使用 1162500 时 TCP 吞吐量应该约为 60Mbit,时间为 155ms,但它不起作用。
谁知道可能是什么问题?
答案1
让我们看看,可能是这样:
- 廉价硬件或执行不佳的驱动程序
- 在你们之间的对等点进行速率限制(我认为我不会希望单个主机通过我的网络推送 60Mb 的流量,除非我对他们的需求有充分的了解)
- 您的长管道上的 TCP 滑动窗口协商不佳。举三个简单的猜测。
RTT 通常主导窗口协商,因此我猜想 155ms 加上他的不对称性导致他要求您放慢速度。由于您是文件服务器,我会将其完全从 TCP 中移除,您真的不需要保证顺序交付,对吗?
或者发布一个转储,我相信我们中的一个会很开心地为你看一下。
@Michael Hampton 是实际上是的,您可以增加您的发送缓冲区(我想大约是 2^26 的数量级)并忽略他的窗口更改请求,但这有点令人讨厌,而且不能保证不会给您在跨大西洋运输中带来更多麻烦...我们可能不得不让史蒂文斯起死回生来画一些画。
使用 UDP,或者至少使用过去十年或二十年里积极开发的东西(想到了 SPDY)。