Типа самый быстрый способ копирования по сети

Больше в режиме памятки. И в основном ниже пойдёт сплошное капитанство.

Допустим нам надо скопировать до фига жЫрный файл с одной линукс-машины на другую. И сетка у нас не то чтобы прям сильно шустрая. Как бы по возможности ускорить этот процесс?

Первое, что приходит в голову, это, конечно, scp / smb / ftp / rsync. Только вот scp сразу скушает энное количество вычислительных ресурсов на шифрование, особенно если ему явно не указать AES-ный шифр. И только rsync хоть как-то попытается сжать передаваемые данные, но при этом тоже много затратит на разбивку файлов на chunk-и и высчитывание контрольных сумм. Поэтому только netcat, только хардкор. И желательно в udp-режиме.

Ещё вспомним про подставу, что netcat бывает трёх разных видов: Traditional, OpenBSD и NMap. Они все умеют плюс-минус одно и то же. Но с двух сторон хорошо бы иметь одинаковый netcat, и лучше если он будет OpenBSD-шный.

Далее, капитан просил передать, что мы можем упереться в одну из трёх максимальных скоростей: чтение с носителя на источнике, передача по сети, запись на носитель на приёмнике. С первым и последним мы обычно мало что можем поделать, а вот сеть реально чуть-чуть "типа ускорить" за счёт компрессии. Но чем сжимать? Однозначно zstd. Хотя бы потому, что он "из коробки" без танцев с бубном умеет в многопоточность.

Но просто сжать мало. Между архиватором и отправкой в сеть желательно ещё поставить буфер, который будет сглаживать "рваный" выхлоп упаковщика и не давать сети простаивать. Оный существует и называется "mbuffer".

Таким образом, на отправителе данных вырисовывается заклинание наподобие.

zstd -T24 -zc ./some_big_file | mbuffer -s 1M -m 2G | nc -4 172.16.1.1 5555

Отдаем по-доброму 24 потока на растерзание zstd (да, у меня толстый сервер), под буфер выделяем 2 гигабайта и всё скармливаем в netcat.

На получателе что-то типа того.

nc -4 -w 10 -l 5555 | zstd -dc | pv -s 101G > some_big_file

pv тут чисто для наглядности. Если ему заранее скормить приблизительный размер передаваемого файла, то он нарисует красивенький progress bar. И заодно сравнивая показания pv и mbuffer можно понять насколько эффективной оказалась отдача от самого процесса сжатия.

Со всеми этими параметрами наподобие количества потоков, степени сжатия zstd или размера буфера можно играться. До тех пор пока не упремся в то, на что уже не можем повлиять (смотри выше). Конкретно я в своих экспериментах достиг предела в скорости записи на диски на целевой машине.

И ещё у древних netcat-ов был баг. Если на машине двойной стек (IPv4 + IPv6), то надо явно указывать протокол (4 или 6). Иначе коннект рвется с неинформативным отлупом и иди ищи почему.

Всем быстрого копирования.