Das Hochladen von meinem Windows-PC (1) auf meinen Ubuntu-Computer (2) in einer anderen Stadt mit PuTTY-Tools ist langsam.
Ich habe dies über den OpenVPN-Tunnel und über die Portweiterleitung an (2) getestet. Es stellt sich heraus, dass die Verwendung von rsync (Unison) über SSH (plink.exe) oder pscp.exe 70% langsamer ist als das Kopieren mit WinSCP (SCP oder SFTP) in (1) -> (2) Richtung. Das Herunterladen hat für beide die gleiche Geschwindigkeit.
Hier sind einige Daten:
link protocol software source target max speed (kb/s)
theoretical speed 4.5mbits 1 2 560
theoretical speed 6.0mbits 2 1 750
VPN SFTP pscp.exe 1 2 180 <- not ok
VPN SFTP pscp.exe 2 1 640
VPN SFTP winscp 1 2 570 <- ok
VPN SFTP winscp 2 1 670
PF SFTP pscp.exe 1 2 185 <- not ok
PF SFTP pscp.exe 2 1 700
PF SFTP winscp 1 2 600 <- ok
PF SFTP winscp 2 1 680
Unison hat fast genau die gleichen Geschwindigkeiten wie pscp.
Ich habe meine Pakete über Wireshark überprüft, aber es scheint nichts Besonderes zu geben. Nur dass WinSCP mehr als doppelt so viele Pakete gleichzeitig sendet.
Sendestil:
WinSCP: 2 oder 3 SSH1 an Server, 1 zurück (ACK)
No. Time Source Destination Protocol Length Info
797 1.003187000 10.8.0.6 10.8.0.10 TCP 54 22?51739 [ACK] Seq=5089 Ack=496673 Win=7079 Len=0
798 1.003208000 10.8.0.10 10.8.0.6 SSH 1241 Client: Encrypted packet (len=1187)
799 1.003211000 10.8.0.10 10.8.0.6 SSH 1241 Client: Encrypted packet (len=1187)
800 1.008147000 10.8.0.6 10.8.0.10 TCP 54 22?51739 [ACK] Seq=5089 Ack=499047 Win=7079 Len=0
801 1.008166000 10.8.0.10 10.8.0.6 SSH 1241 Client: Encrypted packet (len=1187)
802 1.008180000 10.8.0.10 10.8.0.6 SSH 1241 Client: Encrypted packet (len=1187)
803 1.008357000 10.8.0.6 10.8.0.10 TCP 54 22?51739 [ACK] Seq=5089 Ack=501421 Win=7079 Len=0
pscp: 4 SSH2 zum Server, 2 zurück (ACK) und ein SSH2 zurück
No. Time Source Destination Protocol Length Info
210 11.000452000 10.8.0.6 10.8.0.10 TCP 54 22?51744 [ACK] Seq=6178 Ack=97187 Win=185856 Len=0
211 11.005520000 10.8.0.6 10.8.0.10 TCP 54 22?51744 [ACK] Seq=6178 Ack=98989 Win=185856 Len=0
212 11.005585000 10.8.0.10 10.8.0.6 SSHv2 1241 Client: Encrypted packet (len=1187)
213 11.005589000 10.8.0.10 10.8.0.6 SSHv2 1241 Client: Encrypted packet (len=1187)
214 11.005591000 10.8.0.10 10.8.0.6 SSHv2 1241 Client: Encrypted packet (len=1187)
215 11.005592000 10.8.0.10 10.8.0.6 SSHv2 669 Client: Encrypted packet (len=615)
216 11.006578000 10.8.0.6 10.8.0.10 SSHv2 134 Server: Encrypted packet (len=80)
217 11.032385000 10.8.0.6 10.8.0.10 TCP 54 22?51744 [ACK] Seq=6258 Ack=101363 Win=185856 Len=0
218 11.037768000 10.8.0.6 10.8.0.10 TCP 54 22?51744 [ACK] Seq=6258 Ack=103165 Win=185856 Len=0
Der Ubuntu-Computer stellt kein SSH1 bereit. WinSCP hat in seiner Konfiguration auch SSH2 ausgewählt.
Ein weiterer Unterschied sind die WIN- und ACK-Werte
- Haben ACK und WIN Einfluss auf die Übertragungsgeschwindigkeit?
- Was könnte dieses Problem verursachen?
Bearbeiten: Ich habe mit Cygwin und OpenSSH getestet: gleiche Geschwindigkeiten wie WinSCP. Ich habe zwei Bilder gemacht, in denen WinSCP- und Putty TCP-Informationen verglichen wurden. Dies sind die Unterschiede:
Putty WinSCP
TCP Segment Len: 615 1187
TCP Push: Set Not set
Window size value 4014 4118
calc. Window size 16056 16472
[Bytes in flight:] 8352 91399
- Könnte das TCP-Push-Flag der Grund sein?
Update - 20. April.
link protocol software source target max speed (kb/s)
cVPN SFTP pscp.exe 3 4 250 <- not ok
cVPN SFTP winscp 3 4 580 <- ok
cLAN SFTP pscp.exe 3 4 10200 <- maybe not ok
cLAN SFTP winscp 3 4 11500 <- as expected
cVPN = CommercialVPN bei mir zu Hause Lan, cLAN = mein Office Lan, (3) -> (4) = Kopie vom Office-Laptop zum Rechenzentrums-Server. Hier hat pscp auch eine niedrigere Geschwindigkeit als woncp!
Die Paketreihenfolge für pscp ist zu einfach. Nach dem Überprüfen von Paketen ähnelt der Stil eher
...
8 client data (100% fill)
9 client data (100%)
10 client data (60%)
11 server data?
12 server ACK to packet #1
13 server ACK to packet #3
14 client ACK to packet #11
...
Das ist sehr stabil. WinSCP führt stattdessen ACKs für viel ältere Pakete durch, wodurch mehr Pakete im Flug und ein höherer Durchsatz generiert werden, da es nicht auf eine ACK zu warten scheint, bis die nächsten Pakete gesendet werden.
Es scheint, dass dies irgendwie dadurch verursacht wird, dass Putty auf die ACK wartet, anstatt nur noch ein paar Pakete zu senden (was Winscp macht).
Andere Tests:
ctcp (de)activated - no change
rtt to ack winscp = 100ms
irtt winscp no info
rtt to ack pscp = 50ms
irtt pscp = 40ms
winscp: window scaling status: unknown (-1)
pscp: window scaling status: disabled(-2)
Ich würde gerne mehr testen, weiß aber nicht, was ich testen, versuchen und überwachen soll.
plink
(ca. 1 MiB / s) undwinscp
(ca. 6-9 MiB / s) komme ich zu ähnlichen Ergebnissen . Sie könnenplink
Windows durch einen offiziellen OpenSSH-Port ersetzen , siehe Win32-OpenSSH . Es gibt eine ähnliche Leistung wiewinscp
(solide 8 MiB / s).Antworten:
WinSCP verwendet intern PuTTY-Code. Es sollte also keinen Unterschied bei einem ausgewählten Verschlüsselungsalgorithmus geben.
WinSCP verwendet jedoch einige Optimierungen zusätzlich zum PuTTY-Code, insbesondere größere interne und Netzwerkpuffer. Dies hilft in bestimmten Fällen, einen besseren Durchsatz zu erzielen.
Einige Referenzen:
https://winscp.net/tracker/615
https://winscp.net/tracker/690
https://winscp.net/tracker/1273
https://winscp.net/tracker/1295
Zum "TCP Push" -Flag:
Dies liegt wahrscheinlich daran, dass WinSCP den Nagle-Algorithmus für den Socket deaktiviert , PuTTY-Übertragungstools jedoch nicht (PuTTY selbst).
Ich hoffe, dass dies in einem vernünftigen Netzwerk keinen Unterschied macht, da beide Anwendungen Daten so schnell wie möglich an den Socket senden, sodass die Netzwerkschicht keinen Grund haben sollte, Pakete zu verzögern. Und ich sehe definitiv keinen Unterschied in einem Netzwerk, das dies getestet hat. Aber ich habe Berichte von einigen Benutzern, dass es einen Unterschied macht.
Während Sie den Nagle-Algorithmus in der PuTTY-Terminalkonfiguration umschalten können, können Sie ihn in den PuTTY-Übertragungstools (psftp und pscp) nicht umschalten, er ist jedoch immer aktiviert.
https://the.earth.li/~sgtatham/putty/latest/htmldoc/Chapter4.html#config-nodelay
quelle
Die besten Ratschläge in den FAQ - WINSCP SPEED , PLUS - aktualisieren Sie das WINSCP auf die neueste Version.
Zitat:
quelle
Pscp hat keinen -c-Schalter, um eine Verschlüsselung wie scp auf * nix auszuwählen. Um dies zu umgehen, können Sie Ihren Zielhost als Kitt-Sitzung speichern, wodurch Sie die Reihenfolge der Chiffrierauswahl ändern können. Blowfish bietet tendenziell eine bessere Leistung als das Standard-AES.
quelle
WinSCP selbst (es sei denn, sie wurden in der letzten Version behoben?) Ist im Vergleich zu anderen furchtbar langsam. Ich würde Filezilla gegenüber WinSCP empfehlen, VIEL schneller für SSH-Dateiübertragungen im Vergleich zu Winscp.
quelle