Vor ein paar Tagen habe ich meinen ISP geändert (auf T-Mobile, da dies derzeit die einzige Möglichkeit ist). Die stabilen Geschwindigkeiten sind: 150 MB / s Download, ~ 34 MB / s Upload.
Ich habe versucht, eine einzelne 2-GB-Datei (mit SFTP) auf meinen VPS hochzuladen, und ich habe ein seltsames Problem festgestellt, dass die Upload-Geschwindigkeit nach einigen Sekunden abnimmt. Das bedeutet: für etwa 20 MB wird mit voller Geschwindigkeit hochgeladen, danach nur noch ~ 5 MB / s.
Als erstes dachte ich, es ist ein Problem mit dem aktuellen VPS, aber dann habe ich das Hochladen auf andere Server mit dem gleichen Effekt getestet. Das Hochladen auf Dienste wie YouTube, GoogleDrive, OneDrive usw. funktioniert jedoch immer mit voller Geschwindigkeit (34 MBit / s) ohne Probleme.
Ich habe dieses Problem mehr getestet, indem ich PHP-Upload-Skripte (anstelle von SFTP) und VPNs verwendet habe, und es kam immer zu Geschwindigkeitsverlusten beim Upload (nach kurzer Zeit). Ich dachte, dieser ISP begrenzt die Upload-Geschwindigkeit auf "unbekannte" Adressen, aber dann bestellte ich einen Arubacloud-Server und die Upload-Geschwindigkeit von SFTP war in Ordnung.
Danach habe ich OpenVPN auf diesem VPS eingerichtet und mich von meinem Laptop aus damit verbunden. Die Upload-Geschwindigkeiten für diesen Aruba-Server waren noch in Ordnung, für andere jedoch nicht. Wann immer ich versuchte, eine Datei auf mein anderes VPS hochzuladen, führte dies zu einer Upload-Geschwindigkeit von max. 5Mb / s. Ich war sehr verwirrt und habe zweimal überprüft, ob das VPN tatsächlich verwendet wird.
Ich habe keine logische Erklärung dafür gefunden und mit dem Testen auf virtuellen Maschinen mit konfiguriertem "NAT-Netzwerkadapter" begonnen (daher wurde meine Host-IP-Adresse freigegeben). Ich war überrascht zu sehen, dass das Hochladen von Dateien auf alle VPS, die ich zuvor getestet habe, mit voller Geschwindigkeit ohne Geschwindigkeitsverluste und ohne Verwendung von VPN funktioniert ...
Ich dachte, es ist ein Problem mit einer Software / einem Dienst, der auf meinem Laptop ausgeführt wird. Ich habe Windows 10 im abgesicherten Modus mit Netzwerk gestartet. Gleiche Themen. Ich habe eine saubere Windows 10-Kopie auf einer anderen Festplatte installiert - Probleme mit der Upload-Geschwindigkeit ... Natürlich gibt es das gleiche Problem, wenn ich eine kabelgebundene Verbindung (Ethernet) verwende. Ich habe auch die Verbindung zu 2 verschiedenen Routern (meinem Hauptrouter und dem LTE-Router von Huawei) getestet.
Als ich eine virtuelle Windows XP-Maschine auf die Verwendung einer "Bridged" -Verbindung (anstelle von NAT) umstellte, traten dieselben Probleme auf, sodass es sich höchstwahrscheinlich nicht um ein Windows 10-Problem handelt.
Ich bin sehr verwirrt und weiß nicht, woher diese Probleme stammen. Für Tipps und Testempfehlungen wäre ich sehr dankbar.
Update 27.05.2018 17:10
Nur um mehr Details zu geben. Ich habe weitere Tests durchgeführt: Ich habe die SIM-Karte des LTE-Routers in meinem Smartphone verwendet und die Internetverbindung über den "mobilen Hotspot" geteilt. Das gleiche Problem tritt auf.
Ich habe es auch mit dem Laptop meiner Mutter getestet. Das gleiche Problem besteht weiterhin.
Es betrifft nicht nur Filezilla (SFTP) -Transfers, sondern auch normale Dateiuploads über HTTP / HTTPS, das Senden von Dateien über Riot Messenger (Matrix-Client) usw. Ich habe es auch mit einem VPN getestet, das für die Verwendung von Port 443 konfiguriert ist.
Das ist also eigentlich das ISP-Problem, aber etwas muss es auslösen. Nur zur Erinnerung: Wenn ich eine virtuelle Maschine mit "NAT" -Netzwerkadapter verwende, kann ich Dateien mit voller Geschwindigkeit ohne Abnahme hochladen.
Natürlich habe ich die kabelgebundene (Ethernet-) Verbindung mehr als einmal getestet. Es sollte eigentlich keine Rolle spielen, da ich mit Wi-Fi AC eine Upload-Geschwindigkeit von ca. 600 MB / s von meinem NAS erhalte.
Update 28.05.2018 00:15
Ich habe etwas Interessantes entdeckt:
netsh int tcp show global:
Receive Window Auto-Tuning Level : normal
Wenn ich die automatische Optimierung des Fensters über " netsh int tcp set global autotuninglevel = disabled " deaktiviere, sind die Upload-Geschwindigkeiten immer niedrig (ohne volle Geschwindigkeitssteigerung beim Start). Die Einstellung " Experimentell " hat die gleichen Auswirkungen wie die Standardeinstellung " Normal ". Dies ist: Es werden etwa 10-40 MB mit voller Geschwindigkeit hochgeladen, und die Geschwindigkeit sinkt dann drastisch auf 2-5 MB / s.
Weiß jemand, was es bedeuten könnte?
Update 28.05.2018 23:55
Gestern habe ich Windows 8.1 auf einer anderen Festplatte installiert. Scheint, als würde die Upload-Geschwindigkeit nicht abnehmen. Autotuning funktioniert einwandfrei.
Ich habe alle möglichen Windows 10-Versionen (auf demselben Laptop installiert) getestet und die folgenden Testergebnisse erhalten:
Die letzte Version, in der Autotuning funktioniert, ist: 1511 (10586).
Die Version, in der Probleme begannen, ist: 1607 (Jubiläums-Update).
Auf 1511 funktioniert es einwandfrei mit Standard-WLAN / Ethernet-Treibern und auch mit den neuesten möglichen Treibern.
Ich habe versucht, mit der Software "TCP Optimizer" die gleichen TCP-Einstellungen für die neueste Win10-Version festzulegen. Leider hilft es nicht.
Hier sind die TCP-Optimierungseinstellungen für bestimmte Windows-Versionen:
Win 8.1 (funktioniert einwandfrei): https://i.imgur.com/A8mLlrO.png und https://i.imgur.com/8KyNPam.png
Win 10 (funktioniert einwandfrei): https://i.imgur.com/XbMSxTF.png und https://i.imgur.com/9la5Ydy.png
Win 10 1511 (funktioniert einwandfrei): https://i.imgur.com/ta8sFlc.png und https://i.imgur.com/WuDm937.png
Win 10 1607 (Probleme): https://i.imgur.com/kVyaNfG.png und https://i.imgur.com/F4YLLEU.png
Win 10 1703 (Probleme): https://i.imgur.com/hO2iQF6.png und https://i.imgur.com/FNo0oyk.png
Win 10 1709 (Probleme) https://i.imgur.com/LAPcuAa.png und https://i.imgur.com/smy5v5R.png
Leider hilft es nicht, die gleichen Optionen (manuell, nicht über die Funktion "Importieren") festzulegen. Vielleicht weiß jemand, was sich im Jubiläums-Update geändert hat, das diese Probleme verursachen könnte?
Update 31.05.2018 16:05
Die einzige Lösung für dieses Problem, die ich gefunden habe, ist die Verwendung einer virtuellen Linux-Maschine, die den "NAT" -Netzwerkadapter (teilt die Host-IP) + Kitty unter Windows verwendet. Es gibt meine Notizen, hoffe es wird verständlich genug sein:
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
Wenn also eine auf meinem Laptop ausgeführte virtuelle Maschine den Datenverkehr zwischen meinem Laptop und ausgewählten Servern durchläuft, erhalte ich die volle Upload-Geschwindigkeit (34 MBit / s). Es funktioniert nicht mehr, wenn ich den Netzwerkadapter der virtuellen Maschine in "Bridge" ändere. Daher muss er auf "NAT" eingestellt sein.
quelle
Ich habe es geschafft, dieses Problem serverseitig zu beheben.
Scheint, als ob ein Upgrade von Ubuntu Server 16.04 auf 18.04 dieses Problem für alle meine VPS behoben hätte.
Grundsätzlich hat Windows 10 1607+ Probleme mit Ubuntu 16.04 / Debian 8 (und möglicherweise älter). Nach dem Upgrade des Server-Betriebssystems ist das Problem behoben. Es erklärt, warum selbst VPNs nicht zur Lösung dieses Problems beigetragen haben. Schade, dass ich es so spät gemerkt habe, hätte viel Zeit gespart.
quelle