几天前我更换了 ISP(换成了 T-mobile,因为目前这是唯一的选择)。稳定的速度是:下载速度 150Mb/s,上传速度 ~34Mb/s。
我尝试将一个 2GB 的文件上传到我的 VPS(使用 SFTP),然后我注意到一个奇怪的问题,即上传速度在几秒钟后下降。这意味着:大约 20MB 时,它以全速上传,之后只有 ~5Mb/s。
一开始我以为是当前 VPS 的问题,但后来我测试上传到其他服务器时也出现了同样的情况。但是,上传到 YouTube、GoogleDrive、OneDrive 等服务时始终以全速(34Mb/s)进行,没有任何问题。
我使用 php 上传脚本(而不是 SFTP)和 VPN 对此问题进行了更多测试,结果总是导致上传速度下降(很短的一段时间后)。我以为这家 ISP 将上传速度限制为“未知”地址,但后来我订购了 Arubacloud 服务器,SFTP 的上传速度很好。
之后,我在该 VPS 上设置了 OpenVPN,并从我的笔记本电脑连接到它。上传到这台 Aruba 服务器的速度仍然很好,但上传到其他服务器的速度却不好。每当我尝试将文件上传到我的其他 VPS 时,上传速度最高为 5Mb/s。我非常困惑,并仔细检查了 VPN 是否真的被使用了。
我没有找到任何逻辑解释为什么会发生这种情况,于是我开始在配置了“NAT 网络适配器”的虚拟机上进行测试(因此我的主机 IP 地址是共享的)。我很惊讶地发现,我之前测试过的所有 VPS 的文件上传速度都很快,没有任何速度下降,也没有使用任何 VPN……
我以为是笔记本电脑上运行的某些软件/服务出了问题。我使用网络以安全模式启动了 Windows 10。同样的问题。我在另一个硬盘上安装了一个干净的 Windows 10 副本 - 同样的上传速度问题...当然,当我使用有线连接(以太网)时也会出现同样的问题。我还测试了连接到 2 个不同的路由器(我的主路由器和华为的 LTE 路由器)。
当我将 Windows XP 虚拟机更改为使用“桥接”连接(而不是 NAT)时,同样的问题也发生了,所以这很可能不是 Windows 10 的问题。
我很困惑,不知道如何检测导致这些问题的原因。如果能提供任何提示和测试建议,我将不胜感激。
更新 27.05.2018 17:10
只是为了提供更多细节。我做了更多测试:我在智能手机中使用了 LTE 路由器的 SIM 卡,并通过“移动热点”共享互联网连接。出现了同样的问题。
我也在我妈妈的笔记本电脑上测试了。同样的问题仍然存在。
它不仅影响 Filezilla(SFTP)传输,还影响通过 HTTP/HTTPS 的正常文件上传、通过 Riot Messenger(Matrix 客户端)发送文件等。我还使用配置为使用端口 443 的 VPN 进行了测试。
所以这实际上是 ISP 的问题,但一定有什么东西触发了它。提醒一下:当我使用带有“NAT”网络适配器的虚拟机时 - 我可以全速上传文件,不会降低速度。
当然,我测试了有线(以太网)连接不止一次。实际上这应该没什么问题,因为我通过 Wi-Fi AC 从 NAS 获得 ~600Mb/s 的上传速度。
更新 28.05.2018 00:15
我发现了一些有趣的事情:
netsh int tcp show global:
Receive Window Auto-Tuning Level : normal
当我通过“netsh int tcp 设置全局自动调整级别 = 已禁用“- 上传速度一直很低(启动时没有全速提升)。将其设置为“实验“与默认效果相同”普通的“,情况是这样的:全速上传大约 10-40MiB,然后急剧下降到 2-5Mb/s。
有人知道这意味着什么吗?
更新 28.05.2018 23:55
昨天我在另一块硬盘上安装了 Windows 8.1。看来上传速度并没有降低。自动调节功能运行良好。
我测试了所有可能的 Windows 10 版本(安装在同一台笔记本电脑上),得到了以下测试结果:
自动调节功能正常运行的最后一个版本是:1511(10586)。
出现问题的第一个版本是:1607(周年更新)。
在 1511 上,它可以与默认的 Wi-Fi/以太网驱动程序以及最新的驱动程序配合良好。
我尝试使用名为“TCP Optimizer”的软件在最新的 Win10 版本上设置相同的 TCP 设置。不幸的是,它没有帮助。
以下是针对指定 Windows 版本的 TCP 优化器设置:
Win 8.1(运行良好):https://i.stack.imgur.com/TSEqD.png和https://i.stack.imgur.com/aFy7M.png
Win 10(运行良好):https://i.stack.imgur.com/CtQUQ.png和https://i.stack.imgur.com/JkACd.png
Win 10 1511(运行良好):https://i.stack.imgur.com/4wyv7.png和https://i.stack.imgur.com/B81K0.png
Win 10 1607(问题):https://i.stack.imgur.com/R7AGl.png和https://i.stack.imgur.com/g5CDJ.png
Win 10 1703(问题):https://i.stack.imgur.com/NeWlj.png和https://i.stack.imgur.com/nVQSm.png
Win 10 1709(问题)https://i.stack.imgur.com/Micu8.png和https://i.stack.imgur.com/x17Il.png
不幸的是,设置相同的选项(手动设置,而不是通过“导入”功能)没有帮助。也许有人知道周年更新中的哪些变化可能导致这些问题?
更新 31.05.2018 16:05
我发现解决此问题的唯一方法是使用 Linux 虚拟机,该虚拟机使用“NAT”网络适配器(共享主机 IP)+ Windows 上的 Kitty。这是我的注释,希望它足够容易理解:
Virtual Machine Local IP: 192.168.32.132
apt-get install sshpass autossh screen
nano /etc/ssh/sshd_config:
Port 777
service ssh restart
Kitty settings:
Name - > LinuxVM-Tunnel-SpeedFix (port 777 if 22 doesn't work)
Connection -> keepalives -> 30
Connection -> Data -> Autologin username/password
SSH -> Tunnels:
- Source port: 7771 Destination: localhost:8881 | Server1
- Source port: 7772 Destination: localhost:8882 | Server2
- Source port: 7773 Destination: localhost:8883 | Unused
- Source port: 7774 Destination: localhost:8884 | Unused
Connection -> Data login/pass
Connection -> Data -> Command:
screen -X -S VMTunnel1 quit; screen -X -S VMTunnel2 quit; screen -X -S VMTunnel3 quit; screen -X -S VMTunnel4 quit; screen -S VMTunnel1 -dm sshpass -p 'MyPassword' autossh -oStrictHostKeyChecking=no -L 8881:127.0.0.1:22 [email protected]; screen -S VMTunnel2 -dm sshpass -p 'MyPassword' autossh -oStrictHostKeyChecking=no -L 8882:127.0.0.1:22 [email protected];
Filezilla:
Profile: LinuxVM-server1.example.com | 127.0.0.1 | 7771
Profile: LinuxVM-server2.example.com | 127.0.0.1 | 7772
因此,基本上,当在我的笔记本电脑上运行的虚拟机在我的笔记本电脑和选定的服务器之间建立隧道流量时,我会获得全速上传速度 (34Mb/s)。当我将虚拟机网络适配器更改为“桥接”时,它停止工作,因此它必须处于“NAT”状态。
答案1
请记住,ISP 的速率以 Mb/s [每秒兆比特] 为单位,而大多数应用程序 [包括 FTP] 的速率以 MiB/s [每秒兆字节] 为单位,并且由于 1 MiB = 8Mb,您的“5MiB/s”实际上是“40Mb/s”。
初始峰值可能被解释为本地缓冲区已填满。
就“时间”而言,您应该能够在大约 7 分钟内上传 2 GiB,如果时间相当,则说明您的连接良好。
答案2
我设法在服务器端修复了这个问题。
将 Ubuntu Server 16.04 升级到 18.04 似乎解决了我所有 VPS 的这个问题。
因此,基本上,Windows 10 1607+ 与 Ubuntu 16.04 / Debian 8(甚至更早版本)存在问题。升级服务器操作系统后,问题消失。这解释了为什么 VPN 也无法解决这个问题。可惜我这么晚才注意到,否则可以节省很多时间。