Копирование по SSH через инструменты Putty медленнее, чем через WinSCP
Загрузка из моего Windows PC (1) к моей машине Ubuntu (2) в другом городе с помощью инструментов PuTTY является медленной.
Я протестировал это по туннелю OpenVPN и через перенаправление портов к (2). Оказывается, что использование rsync (Унисон) через SSH (plink.exe) или pscp.exe на 70% медленнее, чем копирование с WinSCP (SCP или SFTP) в (1)-> (2) направление. Загрузка имеет те же скорости для обоих.
Вот некоторые данные:
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
Унисон имеет почти точно те же скорости как pscp.
Я осмотрел свои пакеты через Wireshark, но там не кажусь ничем специальным. Просто тот WinSCP отправляет более двух раз количество пакетов в то же время.
Отправлять-стиль:
WinSCP: 2 или 3 SSH1 к серверу, 1 назад (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 к серверу, 2 назад (ACK) и один SSH2 назад
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
Машина Ubuntu не обеспечивает SSH1, WinSCP также выбрал SSH2 в, он - конфигурация.
Другим различием являются значения ACK и WIN
- ACK и WIN имеют влияние на скорости передачи?
- Что могло вызывать эту проблему?
Править: Я протестировал с Cygwin и OpenSSH: те же скорости как WinSCP. Я сделал два изображения, сравнивающие WinSCP и Шпаклевку информация о TCP, это различия:
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
- Флаг TCP Push мог быть причиной?
Обновление - 20-го апреля.
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 в моем домашнем Lan, cLAN=my Office Lan, (3)-> (4) =copy с офисного ноутбука на сервер центра обработки данных. Здесь pscp также имеет более низкую скорость, чем winscp!
Пакетный порядок на pscp слишком прост. После осмотра пакетов стиль больше похож
...
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
...
Это очень устойчиво. WinSCP вместо этого делает ACKs для пакетов значительно старше, таким образом генерируя больше пакетов в полете и более высокой пропускной способности, поскольку это, кажется, не ожидает ACK до отправки следующих пакетов.
Кажется, что это так или иначе вызывается Шпаклевкой, ожидающей ACK вместо того, чтобы просто отправить еще некоторые пакеты (что winscp делает).
Другие тесты:
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)
Я был бы рад протестировать больше, но не знаю, что протестировать, попытаться контролировать.
WinSCP внутренне использует код PuTTY. Таким образом, не должно быть никакой разницы в выбранном алгоритме шифрования.
Хотя WinSCP применяет некоторые оптимизации поверх кода PuTTY, особенно большие внутренние и сетевые буферы. В некоторых случаях это помогает повысить пропускную способность.
Некоторые ссылки:
https://winscp.net/tracker/615
https://winscp.net/tracker/690
https: //winscp.net/tracker/1273
https://winscp.net/tracker/1295[1250 impression Относительно флага «TCP Push»:
Вероятно, это связано с тем, что WinSCP отключает алгоритм Нэгла на розетке, в то время как инструменты передачи PuTTY этого не делают (сам PuTTY).
Я надеюсь, что в любой разумной сети это не должно иметь никакого значения, поскольку оба приложения отправляют данные в сокет как можно быстрее, поэтому сетевой уровень должен нет причин задерживать пакеты. И я точно не вижу разницы ни в одной сети при тестировании этой. Но у меня есть сообщения от некоторых пользователей, что это имеет значение.
Хотя вы можете переключать алгоритм Nagle в конфигурации терминала PuTTY, вы не можете переключать его в инструментах передачи PuTTY (psftp и pscp), он всегда включен.
https: //the.earth.li/~sgtatham/putty/latest/htmldoc/Chapter4.html#config-nodelay
Pscp не имеет переключателя -c для выбора шифра, такого как scp на * nix. Чтобы обойти это, вы можете сохранить целевой хост как сеанс шпатлевки,который позволяет вам изменить порядок выбора шифров. Blowfish, как правило, дает лучшую производительность, чем AES по умолчанию.
Сам WinSCP (если только они не исправлены в последней версии?) ужасно медленный по сравнению с другими, я бы порекомендовал Filezilla поверх WinSCP, MUCH быстрее для передачи ssh файлов по сравнению с winscp.
.Лучшие советы из FAQ - WINSCP SPEED , PLUS - обновите WINSCP до последней версии.
цитата:
При использовании SSH файлы передаются в WinSCP зашифрованы, и это процессор интенсивный. Blowfish обычно намного быстрее, чем AES (так что попробуйте РЕЗУЛЬТАТ). Также может помочь, если вы отключите сжатие, если у вас включал его раньше.
В случае, если скорость снижается из-за задержки подключения, может помочь, если вы используете протокол SCP вместо SFTP. На SCP меньше влияет задержка. В этом случае может помочь включение сжатия.