Как максимально быстро скачать файл с одного linux хоста на другой

Канал может быть какой угодно, скорость зависит от того что находится между серверами

Самы быстрый способ это передача без шифрования

Насщет rsync не скажу, а scp для передачи больших файлов не подойдет. Там блочный протокол и скорость зависит от задержек (ping time).

Простой HTTP/FTP даст минимальный оверхед и высокую потоковую скорость на больших файлах.

rsync -hrtplu --progress user@host:/path/to/big/file

Так оно у тебя копируется овер ssh, т.е. затраты на шифрование.

Проще всего скопировать при помощи netcat: cat file | netcat host port на одном конце и netcat -l -p port > file на другом

Netcat

Ты бы хоть примерно описал в каких локациях хосты находятся. Возможно есть проблемы с NAT или просто очень далеко друг от друга находятся, или же там проблемы с интернетом на одном из хостов и он вообще не всегда включен.
Если, а приватности информации речь не идет, то можешь вообще затарить, и слить потом с веб-сервера aria во много потоков, такой вот костыльный способ например, как скачать действительно очень быстро. Если же хосты реально очень далеко друг от друга, и соединение нестабильно, то можешь скачать через промежуточный или смотри с сторону syncthing, например. (который стал очень приятным открытием для меня, за последнее время). Да самое прикольное в syncthing, это то, что чем больше у тебя хостов и копий данных, тем быстрее все будет.

-W к rsync добавь попробуй. На слабых тачках с хорошей сетью решает

А еще вот тут https://gist.github.com/KartikTalwar/4393116 обрати внимание на -c arcfour

arcfour

В новых версиях openssh его, вроде, выкинули по умолчанию. Я использовал на старых системах совместно с каким то дешевым nas, типа qnap. Благодаря arcfour и -W удалось избавиться от узкого горлышка процессора.

Пишут «For newer hardware (both sides have CPU with AES-NI), I recommend „aes128-gcm@openssh.com“ as an alternative.»

Да тачки тоже вроде не кислые, по крайней мере не настолько.

Вообщем щас я уже опоздал со скачкой поэтому сижу и уже из вредности играюсь со split и socat :)

Хосты друг с другом через одно место. Через vpn и ещё одну локальную сеть. Пинги по сотке. Т.е. как раз с конфиденциальностью всё улёт.

Путь: подмосковье -> минск -> москва -> подмосковье. Т.е. не сказать что далеко далеко, не Австралия.

Через тот же vpn и с теми же пингами со всяких веб сервачков качает влёт. Примерно в тех же локациях.

ибо скорость получается на пару порядков ниже скоростей выходного и входного каналов.

Т.е. вместо 10 Мбайт/с где-то всего лишь 100 Кбайт/с?

Вместо ~8mbps - ~85Kbps, да.

Единстенное, может где то в этой распрекрасной цепочке, кто то жлобит выходную скорость. Но куда у меня есть доступ я проверил (спид тестами всякими, по нубски конечно, ну а что делать), а куда нету, там очень вряд ли будут на таких спичках экономить.

Вообщем лучшее что удалось сделать это посплитать на 10 частей и в эти 10 потоков послать и принять socat'om. Скорость ~1mbs против изначальных ~80kbs. Уж не знаю с чем это связано, но где то я и до этого слышал что так гораздо быстрее выходит.

Попробуй через nc, можешь также параллельно запаковывать. А вообще есть хочется чего-то нового и интересного то можешь попробовать ssfcp (судя по всему в том числе и over udp).

Щас пока качается через socat, уже и так пожатое.

За наводку на тулятину спасибо, звучит интересно.

Странно, но rsync очень быстро отработал когда переносил данные с России в Нидерланды. Но там немного, ~50gb где-то было.

и в эти 10 потоков послать и принять socat'om. Скорость ~1mbs против изначальных ~80kbs.

Раньше (а может где-то и всё ещё?) были популярны «ускорители» закачек: загрузка в несколько потоков (соединений). Причина? Сервера искусственно ограничивали скорость для соединения (одного), но тем не менее позволяли себя легко обмануть. Думаю, и тут дело не в rsync, а в чём-то похожем.

Ну, у меня тоже немного, 2.5 gb :)

Вот я и спросил может я не так готовлю rsync. Пока отвечали, запилили многопоточную качалку из соката. Как докачается, стёба ради попробую ещё с rsync.

bash /dev/tcp

Все забыли, что у rsync есть собственный протокол без шифрования (читаем про rsync daemon в мануале), как раз для задач, когда надо быстро и помногу?

Не то что забыл :)

Не знал. Спасибо.