Два компьютера можно соединить напрямую Ethernet-кабелем и настроить простую IP-адресацию: 

# На отправителе...

ip address add dev eth0 fd42:dead:beef::1/48
ip link set dev eth0 up

# На получателе...

ip address add dev eth0 fd42:dead:beef::2/48
ip link set dev eth0 up

Через несколько секунд должен заработать пинг: 

# На получателе...

/ # ping fd42:dead:beef::1
64 bytes from fd42:dead:beef::1: icmp_seq=1 ttl=64 time=0.649 ms
64 bytes from fd42:dead:beef::1: icmp_seq=2 ttl=64 time=0.376 ms
64 bytes from fd42:dead:beef::1: icmp_seq=3 ttl=64 time=0.414 ms
64 bytes from fd42:dead:beef::1: icmp_seq=4 ttl=64 time=0.340 ms

...и вот это тоже: 

# На получателе...

socat - TCP6-LISTEN:1234 | dd status=progress > big_file.tar.gz

# На отправителе...

socat - 'TCP6-CONNECT:[fd42:dead:beef::2]:1234' < big_file.tar.gz
Эти команды рассчитаны на Linux, но сам приём работает где угодно.

Обычный, ничем не примечательный патч-корд и Ethernet-разъём без проблем выдают порядка 900 Мбит/с — это 6,7 ГБ в минуту. Продвинутые сетевые карты позволят получить скорость на порядки выше, но уже и такой результат заметно превосходит USB-флешку или облачное хранилище.

Другие варианты

...для передачи файла размером от 10 ГБ между двумя машинами, находящимися в паре метров друг от друга.

Облачное хранилище: загрузить файл на сервер и скачать его на другой машине.

В большинстве случаев это будет мучительно медленно — и из-за скорости интернет-соединения, и из-за ограничения трафика облачными провайдерами. Хуже того, файл приходится передавать по сети дважды, что удваивает время передачи.

К тому же это может обойтись недёшево, если подходящего сервера ещё нет.

Прямое TCP-соединение по локальной сети — вариант лучше, но Wi-Fi всё ещё довольно медленный и склонен к случайным обрывам связи: заявленные мультигигабитные скорости выглядят сомнительно и уж точно недостижимы в типичной домашней сети (стены, помехи, большие расстояния и так далее).

Впрочем, если в доме проложена гигабитная Ethernet-проводка, этот вариант отлично работает.

Съёмные накопители довольно медленные, если только не готов вложиться в дорогое оборудование.

Но даже в этом случае всё часто упирается в кабель: USB теоретически поддерживает высокие скорости... при (почти мифическом) идеальном кабеле и безупречных разъёмах. Из личного опыта — только одна пара кабель-периферия действительно достигает гигабитной скорости, и то лишь при подключении в нужный порт под нужным углом.

Кроме того, тут та же проблема, что и с облаком: копирование данных на накопитель и обратно фактически вдвое снижает эффективную скорость. В отличие от Ethernet, напрямую соединить два компьютера через USB не получится, потому что USB построен на разделении хост/устройство.

Обновление: похоже, в Linux только что добавили поддержку прямого соединения через USB-C. Теперь можно соединить два устройства с поддержкой USB-C (точнее, Thunderbolt или USB 4) под Linux и использовать /dev/tbstreamX.

...хотя проверить это пока не получилось — под рукой есть только один компьютер с полноценной поддержкой USB-C.

На самом деле Ethernet — единственный распространённый тип соединения, способный надёжно давать гигабитные скорости между двумя произвольными устройствами при использовании недорогих кабелей. К тому же это по-настоящему дифференциальный сигнал (с трансформаторами!), что делает его устойчивым к радиопомехам и сдвигам потенциала земли.

Ethernet незаслуженно недооценивают для задач, не связанных с интернетом, — и локальная сеть для этого даже не нужна: подключение "точка-точка" работает прекрасно.

Не нужен и стек TCP/IP: сырые кадры канального уровня прекрасно работают даже в коммутируемой локальной сети. Это делает Ethernet очень простым способом обмена данными с микроконтроллером.

Смотрите также:

  • ethtransfer.sh: простой shell-скрипт для копирования файлов